Prowadzenie oddziału na bieżąco z mistrzem

Question

Mam zdalne repozytorium, które wyciągnąłem i rozgałęziam się. Chcę, aby nowy oddział był na bieżąco ze zmianami wprowadzonymi w celu opanowania. Zastanawiam się nad przebiegiem pracy, czy ma to jakiś sens, czy są na to lepsze sposoby?

1. Początkowa rozgałęzienie i kasa:

   git checkout master 
   
   git pull 
   
   git checkout -b my_branch 
   

2. popracować w my_branch, a następnie okresowo:

   git checkout master 
   
   git pull 
   
   git checkout my_branch 
   
   git merge master --no-ff 
   

Powtórz krok 2 w miarę potrzeb, z okresowymi popycha do zdalny my_branch.

Potem, gdy gotowy do seryjnej odwrotnej:

git checkout master 

git merge my_branch --no-ff 

Dźwięk ok?

Answer 1

Można uprościć swoje polecenia:

1.

git fetch 
git checkout -b my_branch origin/master 

2.

git fetch 
git merge origin/master 

git fetch aktualizuje zdalnych oddziałów, tam zazwyczaj nie ma potrzeby, aby mieć lokalna kopia oddziału, gdy nie jest planowanie pracy w tej branży.

Możesz pominąć --no-ff po ustawieniu git config --global merge.ff false.

git help config mówi:

merge.ff 
     By default, Git does not create an extra merge commit when merging 
     a commit that is a descendant of the current commit. Instead, the 
     tip of the current branch is fast-forwarded. When set to false, 
     this variable tells Git to create an extra merge commit in such a 
     case (equivalent to giving the --no-ff option from the command 
     line). When set to only, only such fast-forward merges are allowed 
     (equivalent to giving the --ff-only option from the command line). 

Należy pamiętać, że git pull jest po prostu połączeniem git fetch i git merge.

Zwykle po prostu potrzebujesz git pull --rebase, który jest w istocie git fetch plus git rebase i tworzy znacznie czystszą historię.

Czy istnieje jakiś powód "okresowego popychania"? Jeśli nikt nie pracuje w tej samej branży, byłoby idealnie, po prostu popychać po skończeniu wszystkiego.

Answer 2

Zaleca się stosowanie przepływu pracy opartego na rebase. Dlatego zamiast używać git pull powinieneś użyć git pull --rebase.

Zrobiłbym to samo z gałęzią funkcji. Więc zamiast robić git merge master --no-ff użyłbym git rebase master. Jednakże, jeśli gałąź funkcji ma być współdzielona ze współpracownikami podczas tworzenia, lepiej jest okresowo scalać gałąź główną w gałęzi elementów.

Jednak, szczerze mówiąc, pracuję w małym zespole i jeśli potrzebujemy pracować razem nad gałęzią fabularną i musimy ją uaktualnić z mistrzem, po prostu zawieszamy naszą pracę na krótką chwilę (i komunikujemy się proces wyraźnie), przejęcie na master i force popchnij gałąź funkcji. Ale tak, to nie skaluje się dla większych zespołów. Uważam jednak, że wygodniej jest pracować z gałęzią operacji, która jest rebased na master, zamiast zajmować się połączeniami z master.

Pamiętaj, aby przeczytać to.

Git workflow and rebase vs merge questions