Rozwidlanie vs. Rozgałęzianie w GitHub

278

Chciałbym dowiedzieć się więcej o zaletach i wadach tworzenia projektu github w porównaniu do tworzenia gałęzi projektu github.

Forking sprawia, że moja wersja projektu jest bardziej odizolowana od oryginalnej, ponieważ nie muszę być na liście współpracowników oryginalnego projektu. Ponieważ opracowujemy projekt we własnym zakresie, nie ma problemu z dodawaniem osób jako współpracowników. Chcielibyśmy jednak zrozumieć, czy rozwidlenie projektu utrudniłoby scalenie zmian w głównym projekcie. Zastanawiam się, czy rozgałęzienie ułatwia synchronizację dwóch projektów. Innymi słowy, czy łatwiej jest scalać i wypychać zmiany między moją wersją projektu głównego a projektem głównym, kiedy mam gałąź?

git branch github

— przeprogramowanie
źródło

279

Nie zawsze możesz utworzyć gałąź lub wyciągnąć istniejącą gałąź i odepchnąć do niej, ponieważ nie jesteś zarejestrowany jako współpracownik dla tego konkretnego projektu.

Forking to tylko klon po stronie serwera GitHub :

bez możliwości bezpośredniego odepchnięcia
z dodaną funkcją kolejki rozwidlenia do zarządzania żądaniem scalenia

Widelec jest zsynchronizowany z oryginalnym projektem poprzez:

dodanie oryginalnego projektu jako pilota
pobieranie regularnie z tego oryginalnego projektu
oprzyj swój obecny rozwój na gałęzi zainteresowań, którą zaktualizowałeś z tego pobrania.

Rebase pozwala upewnić się, że zmiany są proste (bez konfliktu scalania do obsługi), dzięki czemu prośba o wyciągnięcie jest łatwiejsza, gdy chcesz, aby opiekun oryginalnego projektu uwzględnił Twoje łaty w swoim projekcie.

Celem jest naprawdę umożliwienie współpracy, nawet jeśli bezpośredni udział nie zawsze jest możliwy.

Fakt, że klonujesz po stronie GitHub oznacza, że masz teraz dwa „centralne” repozytorium („centralne” jako „widoczne dla kilku współpracowników).
Jeśli możesz dodać je bezpośrednio jako współpracownika dla jednego projektu, nie musisz zarządzać innym jeden z widelcem.

rozwidlenie na GitHub

Proces scalania byłby mniej więcej taki sam, ale z dodatkowym poziomem pośrednictwa (naciśnij najpierw na widelec, a następnie poproś o pociągnięcie, z ryzykiem ewolucji oryginalnego repozytorium, co spowoduje, że twoje połączenia do przodu nie będą już przewijać do przodu) .
Oznacza to, że prawidłowym obiegiem pracy jest git pull --rebase upstream(bazowanie na pracy nad nowymi zatwierdzeniami od początku), a następnie git push --force origin, w celu przepisania historii w taki sposób, że własne zatwierdzenia są zawsze na początku zatwierdzeń z oryginalnego (wcześniejszego) repozytorium .

Zobacz też:

— VonC
źródło

3

Opracowujemy projekt we własnym zakresie i nie ma problemu z dodawaniem osób jako współpracowników. Chcielibyśmy jednak zrozumieć, czy rozwidlenie projektu utrudniłoby scalenie zmian w projekcie głównym.

— przeprogramowanie

7

@ reprogrammer: jeśli możesz dodać współpracowników, rozwidlenie nie jest potrzebne. mogą bazować lokalnie, a następnie łączyć się z gałęzią docelową, a następnie przesyłać bezpośrednio do jednego centralnego repozytorium, zamiast musieć zarządzać dwoma centralnymi repozytoriami (pierwotnym i widełkowym). Rebase byłby mniej więcej taki sam, ale z dodatkową pośrednią reakcją, gdy w grę wchodzi widelec. Ponownie: tutaj nie potrzebne. Zaktualizowałem swoją odpowiedź.

— VonC

14

Szczerze mówiąc, nawet jeśli nie musisz, zawsze warto mieć święte repozytorium, które można zapisać tylko dla starszych programistów, kierowników zespołów lub innych „zaufanych” osób . Wszyscy pozostali członkowie zespołu powinni pracować w swoich widłach (~ piaskownicach) i wnosić swoje zmiany w formie żądania ściągnięcia. Ponieważ umożliwia to DVCS, zaadaptowaliśmy ją jako „najlepszą praktykę” i z powodzeniem wykorzystujemy ją nawet w najmniejszych projektach ...

— środę,

1

@intland, więc jesteś bardziej zwolennikiem „przepływu pracy menedżera integracji”, zgodnie z opisem w stackoverflow.com/users/6309/vonc?tab=response ? Po wprowadzeniu Gita w dużej korporacji, najpierw mam tendencję do przyjmowania scentralizowanego przepływu pracy (bardziej znanego wszystkim), a następnie przejścia na „menedżera integracji”.

— VCC

15

Powinniśmy nazywać widelce „gałązkami”, ponieważ są one zrywane z gałęzi i służą do założenia zupełnie nowego drzewa. Tylko moje dwa centy - lubię nadrzewny idiom.

— Eric

66

Oto różnice wysokiego poziomu:

Forking

Plusy

Udziela oddziałów oddzielonych przez użytkownika
Zmniejsza bałagan w głównym repozytorium
Proces Twojego zespołu odzwierciedla proces zewnętrznego współpracownika

Cons

Utrudnia zobaczenie wszystkich gałęzi, które są aktywne (lub nieaktywne, jeśli o to chodzi)
Współpraca w oddziale jest trudniejsza (właściciel widelca musi dodać osobę jako współpracownika)
Musisz zrozumieć pojęcie wielu pilotów w Git
- Wymaga dodatkowej księgowości
- Utrudni to przepływ pracy osobom, które nie są zbyt wygodne w Git

Rozgałęzienie

Plusy

Utrzymuje wszystkie prace wokół projektu w jednym miejscu
Wszyscy współpracownicy mogą naciskać na ten sam oddział, aby współpracować nad nim
Jest tylko jeden zdalny pilot Git

Cons

Gałęzie, które zostaną porzucone, mogą łatwiej się gromadzić
Proces wkładu zespołu nie jest zgodny z procesem zewnętrznego współpracownika
Musisz dodać członków zespołu jako współpracowników, zanim będą mogli się rozgałęzić

— Aidan Feldman
źródło

Co należy rozumieć przez „proces zewnętrznego współpracownika”?

— Kars Barendrecht

1

@KarsBarendrecht Zaktualizowano, aby używać terminu „zewnętrzny współpracownik”. Ktoś, kto nie ma writeuprawnień do repozytorium.

— Aidan Feldman

45

Ma to związek z ogólnym przepływem pracy Git. Jest mało prawdopodobne, abyś mógł przepchnąć bezpośrednio do repozytorium głównego projektu. Nie jestem pewien, czy repozytorium projektu GitHub obsługuje kontrolę dostępu opartą na gałęzi, ponieważ nie chciałbyś na przykład udzielać nikomu pozwolenia na przekazywanie do gałęzi master.

Ogólny wzór jest następujący:

Rozwidlaj oryginalne repozytorium projektu, aby mieć własną kopię GitHub, do której następnie będziesz mógł wypychać zmiany.
Sklonuj swoje repozytorium GitHub na komputerze lokalnym
Opcjonalnie dodaj oryginalne repozytorium jako dodatkowe zdalne repozytorium w lokalnym repozytorium. Będziesz wtedy mógł bezpośrednio pobierać zmiany opublikowane w tym repozytorium.
Dokonuj modyfikacji i wprowadzaj własne zmiany lokalnie.
Przekaż zmiany do repozytorium GitHub (ponieważ zazwyczaj nie będziesz mieć uprawnień do zapisu bezpośrednio w repozytorium projektu).
Skontaktuj się z opiekunami projektu i poproś ich o pobranie twoich zmian oraz przejrzenie / scalenie i pozwól im wrócić do repozytorium projektu (jeśli ty i oni zechcecie).

Bez tego dość często zdarza się, że w projektach publicznych ktoś może bezpośrednio popchnąć własne zobowiązania.

— Bruno
źródło

@RecoJohnson, cóż ... Nie użyłem słowa „pull” w mojej odpowiedzi (ale „pull” to po prostu „fetch” + „merge” w kategoriach Git). Które użycie „push” uważasz za niewłaściwe?

— Bruno,

2

@RecoJohnson Ty jako dostawca wsparcia dla swojego widelca GitHub; opiekunowie projektu wyciągają twój wkład z widelca.

— mljrg

1

Myślę, że założenie, że nie zostaniesz przydzielony do współpracownika, jest bardziej prawdziwe w świecie open source niż w wielu organizacjach, w których zespoły programistów używają obecnie git, gdzie zespół programistów jest dobrze zdefiniowany. Myślę, że jest to ważne rozróżnienie, które nie jest wystarczające, prawdopodobnie dlatego firmy takie jak gitlab dobrze się rozwijają, ponieważ rozumieją potrzeby przedsiębiorstwa i potrzebują kontroli.

— code4cause

8

Forking tworzy całkowicie nowe repozytorium z istniejącego repozytorium (po prostu wykonując klon git na gitHub / bitbucket)

Widelce najlepiej stosować: gdy celem „podziału” jest stworzenie logicznie niezależnego projektu, który nigdy nie połączy się z rodzicem.

Strategia rozgałęzienia tworzy nowy oddział w istniejącym / działającym repozytorium

Gałęzie są najlepiej stosowane: gdy są tworzone jako tymczasowe miejsca do pracy przez obiekt, z zamiarem scalenia gałęzi z początkiem.

Bardziej szczegółowo: - W projektach typu open source to właściciel repozytorium decyduje, kto może przekazywać dane do repozytorium. Jednak idea open source polega na tym, że każdy może wnieść swój wkład w projekt.

Ten problem rozwiązują rozwidlenia: za każdym razem, gdy programista chce zmienić coś w projekcie open source, nie klonuje bezpośrednio oficjalnego repozytorium. Zamiast tego rozwidlają go, aby utworzyć kopię. Po zakończeniu pracy wysyłają żądanie ściągnięcia, aby właściciel repozytorium mógł przejrzeć zmiany i zdecydować, czy połączyć je ze swoim projektem.

U podstaw rozwidlenie jest podobne do rozgałęziania funkcji, ale zamiast tworzenia rozgałęzień wykonuje się rozwidlenie repozytorium, a zamiast wykonywania żądania scalenia tworzysz żądanie ściągnięcia.

Poniższe linki przedstawiają różnicę w dobrze wyjaśniony sposób:

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html

— kim jestem
źródło

„Najczęściej używane” stwierdzenia w tej odpowiedzi wydają się ignorować wiele problemów, które uniemożliwiają rozgałęzianiu działanie w takich projektach jak open source, a także rzeczywistość używania widelców w prawdziwym świecie. Niezwykle często widuje się używanie widelców w połączeniu z żądaniami ściągania, aby umożliwić ludziom współpracę przy projekcie, który nie wszyscy mają uprawnienia do bezpośredniej modyfikacji danego repozytorium.

— StriplingWarrior