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ć?
Odpowiedzi:
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.
git checkout our-team git pull git checkout featurex git merge our-team
our-teamlokalnego, musisz git fetch && git rebase origin/our-teamzamiast tego uruchomić . Twoje polecenia zakładają, że repozytorium zostało wcześniej zaktualizowane.
przejdź do gałęzi głównej our-team
pobierz wszystkie nowe zmiany z our-teamgałęzi
idź do swojego oddziału featurex
featurexpołącz zmiany our-teamoddziału w featurexoddział
our-team{commit-hash} jeśli chcesz scalić określone zatwierdzeniawprowadzaj zmiany wraz ze zmianami our-teamgałęzi
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.