Zaktualizuj gałęzie Git z poziomu głównego

Jestem nowy w Git i teraz jestem w takiej sytuacji:

• Mam cztery gałęzie (master, b1, b2 i b3).
• Po tym, jak pracowałem nad b1-b3, zdałem sobie sprawę, że muszę coś zmienić w głównym oddziale, co powinno być we wszystkich innych gałęziach.
• Zmieniłem to, czego potrzebowałem masteri ... oto mój problem:

Jak zaktualizować wszystkie inne oddziały za pomocą masterkodu oddziału?

Masz dwie opcje:

Pierwszy to scalanie, ale tworzy to dodatkowe zatwierdzenie dla scalania.

Kasa dla każdego oddziału:

git checkout b1

Następnie scal:

git merge origin/master

Następnie wciśnij:

git push origin b1

Alternatywnie możesz zrobić rebase:

git fetch
git rebase origin/master

Masz w zasadzie dwie opcje:

1. Łączysz się. To jest właściwie dość proste i idealnie lokalne działanie:

   git checkout b1
   git merge master
   # repeat for b2 and b3
   

   To pozostawia historię dokładnie tak, jak to się stało: rozwidliłeś się z mastera, dokonałeś zmian we wszystkich gałęziach, a na końcu wprowadziłeś zmiany z mastera do wszystkich trzech gałęzi.

   gitpotrafi poradzić sobie z tą sytuacją naprawdę dobrze, jest przeznaczony do łączenia zachodzącego we wszystkich kierunkach jednocześnie. Możesz ufać, że będzie w stanie poprawnie zebrać wszystkie wątki. Po prostu nie ma znaczenia, czy gałąź się b1połączy master, czy masterpołączy b1, zatwierdzenie scalania wygląda tak samo dla git. Jedyną różnicą jest to, która gałąź ostatecznie wskazuje na to zatwierdzenie scalania.

2. Ty bazujesz. Osoby z SVN lub podobnym doświadczeniem uważają to za bardziej intuicyjne. Polecenia są analogiczne do przypadku scalenia:

   git checkout b1
   git rebase master
   # repeat for b2 and b3
   

   Ludziom podoba się to podejście, ponieważ zachowuje ono liniową historię we wszystkich gałęziach. Jednak ta liniowa historia jest kłamstwem i powinieneś być tego świadomy. Rozważ ten wykres zatwierdzania:

   A --- B --- C --- D <-- master
    \
     \-- E --- F --- G <-- b1
   

   Efektem scalenia jest prawdziwa historia:

   A --- B --- C --- D <-- master
    \                 \
     \-- E --- F --- G +-- H <-- b1
   

   Jednak rebase daje ci tę historię:

   A --- B --- C --- D <-- master
                      \
                       \-- E' --- F' --- G' <-- b1
   

   Chodzi o to, że rewizje E', F'i G'nigdy tak naprawdę nie istniał, i prawdopodobnie nigdy nie były testowane. Mogą nawet się nie kompilować. W rzeczywistości dość łatwe jest tworzenie bezsensownych zatwierdzeń poprzez rebase, szczególnie gdy zmiany mastersą ważne dla rozwoju w b1.

   Konsekwencją tego może być, że nie można odróżnić, który z trzech zatwierdzeń E, Fi Gfaktycznie wprowadził regresji, zmniejszając wartość git bisect.

   Nie mówię, że nie powinieneś używać git rebase. Ma swoje zastosowania. Ale za każdym razem, gdy go używasz, musisz zdawać sobie sprawę z faktu, że kłamiesz na temat historii. I powinieneś przynajmniej skompilować test nowych zatwierdzeń.

git rebase masterjest właściwym sposobem na zrobienie tego. Scalenie oznaczałoby zatwierdzenie do scalenia, a ponowne bazowanie nie.

Jeśli pracowałeś nad gałęzią bez przerwy lub wiele innych wydarzyło się podczas pracy nad czymś, najlepiej przenieść swoją gałąź na master. Utrzymuje to porządek w historii i znacznie ułatwia śledzenie.

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Uwagi:

• Nie bazuj na oddziałach, nad którymi współpracowałeś z innymi.
• Powinieneś bazować na gałęzi, do której chcesz się połączyć, co nie zawsze może być master.

Rozdział na temat zmiany bazy znajduje się na stronie http://git-scm.com/book/ch3-6.html i mnóstwo innych zasobów w Internecie.

@cmaster udzielił najlepiej opracowanej odpowiedzi. W skrócie:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

Nie należy ponownie zapisywać historii oddziału, a zamiast tego utrzymywać ją w aktualnym stanie do przyszłych odniesień. Łącząc się z master, tworzy jedno dodatkowe zatwierdzenie, ale jest tanie. Zobowiązania nie kosztują.

Aby zaktualizować inne gałęzie, takie jak (kopia zapasowa), za pomocą kopii oddziału głównego. Możesz wykonać dowolną drogę (rebase lub merge) ...

1. Wykonaj zmianę bazy (nie będzie żadnych dodatkowych zmian dokonanych w oddziale kopii zapasowej).

2. Scal gałęzie (nastąpi dodatkowe zatwierdzenie automatycznie w gałęzi kopii zapasowej).

   Uwaga: Rebase to nic innego jak ustanowienie nowej bazy (nowa kopia)

git checkout backup
git merge master
git push

(Powtórz dla innych oddziałów, jeśli takie jak backup2 i etc ..,)

git checkout backup
git rebase master
git push

(Powtórz dla innych oddziałów, jeśli takie jak backup2 i etc ..,)

Możesz połączyć lub zastosować indywidualne zatwierdzenia między oddziałami, używając git cherry-pick .

Istnieją dwie opcje tego problemu.

1) git rebase

2) Git Merge

Tylko różnią się z powyższymi w przypadku scalenia, będą miały dodatkowe zatwierdzenie w historii

1) Git Checkout Branch (b1, b2, b3)

2) git rebase origin / master (w przypadku konfliktów rozwiąż je lokalnie wykonując git rebase - kontynuuj)

3) git push

Alternatywnie opcja scalania git jest podobna

1) Git Checkout „Your_branch” (b1, b2, b3)

2) Git Merge Master

3) git push

aby zaktualizować swój oddział z poziomu głównego:

  git checkout master
  git pull
  git checkout your_branch
  git merge master