Jak utrzymać synchronizację gałęzi git z master

W chwili, gdy git wkracza, nie mogę znaleźć najlepszego rozwiązania dla poniższych.

Istnieją dwie gałęzie, jedna o nazwie master, a druga o nazwie mobiledevices support . Chcę zachować wsparcie mobiledevices jako ciągłą gałąź, która zostanie połączona / zsynchronizowana z gałęzią master, gdy wsparcie mobiledevices będzie stabilne. Spowodowałoby to scalenie zmian z obsługi urządzeń mobilnych w pomoc główną, ale także przeniesienie wszystkich zmian z obsługi urządzeń mobilnych do obsługi urządzeń mobilnych, tak aby gałąź mogła być dalej rozwijana, a funkcje ulepszone lub poprawione. To musi współpracować z centralnym repozytorium i wieloma programistami.

Proszę podać przykład podobnych przepływów pracy, z których korzystają inni ludzie, lub po prostu powiedz mi, czy ten pomysł jest głupi, i powinienem rozważyć inne opcje. W tej chwili przepływ pracy wydaje się być poprawny, ale po prostu nie wiem, jak mogę sprawić, aby git działał w ten sposób.

Dzięki, cała pomoc bardzo doceniona.

Aktualizacja 1: Jeśli miałbym scalić wzorzec z obsługą urządzeń mobilnych i obsługę urządzeń mobilnych w urządzeniach głównych, czy otrzymuję replikowane zatwierdzenia w obu oddziałach. Lub jest wystarczająco inteligentny, aby zorientować się, że wyciągnąłem najnowsze zmiany z gałęzi A do gałęzi B i dodałem scalenie zatwierdzenia C do gałęzi B. I wyciągnąłem najnowsze zmiany z gałęzi B do gałęzi A i dodałem scalenie zatwierdzenia D do gałęzi ZA?

Zamierzałem opublikować zdjęcie, ale nie mam dla niego wystarczającej reputacji, więc sądzę, że poniższa ilustracja będzie wystarczająca. Dwie gałęzie pracują nieprzerwanie, często łączą się w obie strony. Kluczową rzeczą, której nie jestem pewien, jest to, w jaki sposób git będzie odtwarzał zatwierdzenia i czy wypełni oba gałęzie zatwierdzeniami z drugiego oddziału po scaleniu, czy też pozostanie czysty. Używałem wcześniej bazy, ale wydaje się, że kończy gałąź i wstawia wszystkie zatwierdzenia do mastera, albo zrobiłem to źle. Dzięki za pomoc do tej pory.

master
A--B--C-----H--I--J--M--N
       \   /    \
mobile  \ /      \
D--E--F--G--------K--L

tak, po prostu zrób

git checkout master
git pull
git checkout mobiledevicesupport
git merge master

aby utrzymać mobiledevices support w synchronizacji z master

wtedy, gdy jesteś gotowy, aby wesprzeć urządzenia mobilne w master, najpierw połącz w master jak wyżej, a następnie ...

git checkout master
git merge mobiledevicesupport
git push origin master

i to wszystko.

zakłada się tutaj, że mobilexxx to gałąź tematyczna z pracą, która nie jest jeszcze gotowa do przejścia do głównej gałęzi. Tak więc łączymy się w mistrza tylko wtedy, gdy wsparcie mobilne jest w dobrym miejscu

Ilekroć chcesz przenieść zmiany z mistrza do swojej gałęzi pracy, wykonaj git rebase <remote>/master. Jeśli są jakieś konflikty. rozwiązać je.

Kiedy twoja gałąź pracy jest gotowa, ponownie uruchom bazę, a następnie zrób git push <remote> HEAD:master. Spowoduje to zaktualizowanie gałęzi master na zdalnym (centralne repo).

Podejście concept47 jest właściwym sposobem na zrobienie tego, ale radzę połączyć się z opcją --no-ff, aby oczyścić historię zatwierdzeń.

git checkout develop
git pull --rebase
git checkout NewFeatureBranch
git merge --no-ff master

Tak, zgadzam się z twoim podejściem. Aby scalić obsługę urządzeń mobilnych w master, możesz użyć

git checkout master
git pull origin master //Get all latest commits of master branch
git merge mobiledevicesupport

Podobnie możesz także połączyć master w mobiledevices support.

P: Jeśli łączenie krzyżowe stanowi problem, czy nie.

A. Cóż, zależy to od zatwierdzeń dokonanych w gałęzi mobile * i master od czasu ich ostatniej synchronizacji. Weźmy przykład: po ostatniej synchronizacji następujące zatwierdzenia zdarzają się w tych gałęziach

Master branch: A -> B -> C [where A,B,C are commits]
Mobile branch: D -> E

Załóżmy teraz, że zatwierdzenie B dokonało pewnych zmian w pliku a.txt, a zatwierdzenie D również wprowadziło pewne zmiany w pliku a.txt. Przyjrzyjmy się teraz wpływowi każdej operacji łączenia,

git checkout master //Switches to master branch
git pull // Get the commits you don't have. May be your fellow workers have made them.
git merge mobiledevicesupport // It will try to add D and E in master branch.

Teraz możliwe są dwa rodzaje łączenia

1. Scalanie do przodu
2. Prawdziwe scalenie (wymaga ręcznego wysiłku)

Git najpierw spróbuje połączyć FF, a jeśli stwierdzi, że konflikty nie zostaną rozwiązane przez git. Nie udaje się połączyć i prosi o połączenie. W takim przypadku nastąpi nowe zatwierdzenie, które jest odpowiedzialne za rozwiązywanie konfliktów w pliku a.txt.

Podsumowując, łączenie krzyżowe nie jest problemem i ostatecznie musisz to zrobić i to właśnie oznacza synchronizacja. Upewnij się, że zabrudzisz ręce podczas łączenia oddziałów, zanim zaczniesz cokolwiek produkować.

Zaakceptowana odpowiedź za pomocą git merge wykona zadanie, ale pozostawi niechlujne zatwierdzenie hisotry, poprawnym sposobem powinno być „rebase”, wykonując następujące kroki (zakładając, że chcesz utrzymać gałąź funkcji w sycn z rozwijaniem, zanim wykonasz ostatni push przed PR ).

1 git fetchz gałęzi funkcji (upewnij się, że gałąź funkcji, nad którą pracujesz, jest aktualna)

2) git rebase origin/develop

3. jeżeli powstanie jakikolwiek konflikt, rozwiąż je jeden po drugim

4 użyj, git rebase --continuegdy wszystkie konflikty zostaną rozwiązane

5 git push --force

Myślisz we właściwym kierunku. Ciągłe łączenie urządzenia głównego z obsługą urządzeń mobilnych i łączenie urządzenia głównego z urządzeniami mobilnymi, gdy wsparcie urządzeń mobilnych jest stabilne. Każdy programista będzie miał swój oddział i może łączyć się z urządzeniem głównym lub mobilnym w zależności od jego roli.