Jak uzyskać zmiany z innego oddziału

Obecnie pracuję w featurexbranży. Nasza główna gałąź nazywa się gałąź our-team. Odkąd zacząłem pracować featurex, więcej zmian zostało wprowadzonych w gałęzi our-team. Zanim zacznę naciskać featurexna scalanie, chciałbym lokalnie pobrać wszystkie zmiany z our-teamgałęzi do, featurexaby mieć pewność, że wszystko działa zgodnie z oczekiwaniami.

Zrobiłem to lokalnie, aby pobrać wszystkie najnowsze zmiany z our-team.

git checkout our-team
git pull

Jak mogę to zrobić?

Z rebase możesz korzystać na przykład git rebase our-teamw swoim oddzialefeaturex

Przeniesie punkt początkowy gałęzi na koniec our-teamgałęzi, scalając wszystkie zmiany w featurexgałęzi.

1. przejdź do gałęzi głównej our-team

   • git checkout nasz zespół

2. pobierz wszystkie nowe zmiany z our-teamgałęzi

   • git pull

3. idź do swojego oddziału featurex

   • git checkout featurex

4. połącz zmiany our-teamoddziału w featurexoddział

   • git merge our-team
   • lub git cherry-pick,{commit-hash} jeśli chcesz scalić określone zatwierdzenia

5. wprowadzaj zmiany wraz ze zmianami our-teamgałęzi

   • git push

Uwaga : prawdopodobnie będziesz musiał rozwiązać konflikty po scaleniu our-teamgałęzi w featurexgałąź przed wypchnięciem

git fetch origin our-team

lub

git pull origin our-team

ale najpierw upewnij się, że jesteś już w gałęzi, do której chcesz zaktualizować (featurex).

Już prawie jesteś :)

Pozostało tylko to

git checkout featurex
git merge our-team

To połączy nasz zespół w featurex.

Powyższe zakłada, że ​​już zatwierdziłeś / ukryłeś swoje zmiany w featurex, jeśli tak nie jest, musisz to zrobić najpierw.

Dla innych osób, które trafiają na ten post w Google. Istnieją dwie opcje: scalanie lub ponowne bazowanie gałęzi. Oba działają inaczej, ale mają podobne wyniki.

Odpowiedź akceptowana jest rebase . Spowoduje to pobranie wszystkich wykonanych zatwierdzeń, our-team a następnie zastosowanie wykonanych zatwierdzeń featurex, zachęcając do ich scalenia w razie potrzeby.

Jednym z ograniczeń związanych z ponownym bazowaniem jest to, że tracisz / przepisujesz historię gałęzi, mówiąc gitowi, że twoja gałąź nie zaczęła się od zatwierdzenia 123abc, ale 456cde. Spowoduje to problemy dla innych osób pracujących w gałęzi, a niektóre narzędzia zdalne będą na to narzekać. Jeśli jednak jesteś pewien tego, co robisz, do tego --forcesłuży flaga.

To, co sugerują inne plakaty, to połączenie . Spowoduje to pobranie featurexgałęzi z dowolnym stanem i spróbuje scalić ją z bieżącym stanem our-team, zachęcając do zrobienia jednego, dużego, zatwierdzenia scalenia i naprawienia wszystkich błędów łączenia przed naciśnięciem our-team. Różnica polega na tym, że starasz się swoimi featurexzobowiązuje zanim się our-teamnowych zatwierdzeń i następnie ustalenie różnic. Nie przepisujesz również historii, zamiast tego dodajesz do niej jeden commit, zamiast przepisać te, które były wcześniej.

Obie opcje są prawidłowe i mogą działać w tandemie. To, co jest zwykle (przez to mam na myśli, jeśli używasz szeroko rozpowszechnionych narzędzi i metod, takich jak git-flow ) jest wykonywane dla gałęzi funkcji, to scalanie jej z główną gałęzią, często przechodząc przez żądanie scalenia i rozwiązując wszystkie konflikty które powstają w jednym (lub wielu) zatwierdzeniach scalających.

Rebasing jest interesującą opcją, która może pomóc w naprawieniu gałęzi przed ostatecznym przejściem przez scalanie i złagodzić ból związany z koniecznością wykonania jednego dużego zatwierdzenia przez scalanie.