Git push odrzucony po zmianie gałęzi funkcji

OK, myślałem, że to prosty scenariusz git, czego mi brakuje?

Mam masteroddział i featureoddział. Trochę pracuję master, trochę dalej feature, a potem jeszcze trochę dalej master. Kończę z czymś takim (kolejność leksykograficzna oznacza kolejność zatwierdzeń):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

Nie mam problemu z aktualizowaniem git push origin masterpilota masterani z git push origin feature(gdy jest on feature) utrzymywaniem zdalnej kopii zapasowej dla mojej featurepracy. Do tej pory jesteśmy dobrzy.

Ale teraz chcę bazować featurena F--Gzatwierdzeniach na master, więc ja git checkout featurei git rebase master. Nadal dobrze. Teraz mamy:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Problem: w momencie, gdy chcę wykonać kopię zapasową nowego, opartego na featurerozgałęzieniu git push origin feature, push jest odrzucany, ponieważ drzewo zmieniło się z powodu zmiany. Można to rozwiązać tylko za pomocą git push --force origin feature.

Nienawidzę używania, --forcenie będąc pewnym, że go potrzebuję. Więc potrzebuję tego? Czy ponowne bazowanie niekoniecznie oznacza, że ​​następne pushpowinno być --forcepełne?

Ta gałąź funkcji nie jest dzielona z innymi programistami, więc nie mam problemu de facto z siłą nacisku, nie zamierzam stracić żadnych danych, pytanie jest bardziej koncepcyjne.

Problem polega na tym, że git pushzakłada się, że gałąź zdalna może być szybko przekazywana do gałęzi lokalnej, to znaczy, że cała różnica między gałęziami lokalnymi i zdalnymi polega na tym, że na lokalnych lokalach znajdują się nowe zatwierdzenia:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

Podczas wykonywania git rebasezatwierdzeń D i E są stosowane do nowej bazy i tworzone są nowe zatwierdzenia. Oznacza to, że po rebase masz coś takiego:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

W takiej sytuacji zdalnej gałęzi nie można szybko przekazać do lokalnego. Chociaż teoretycznie gałąź lokalna może zostać scalona w zdalną (oczywiście nie jest to potrzebne w tym przypadku), ale ponieważ git pushwykonuje tylko scalanie z przewijaniem do przodu, generuje błąd.

A --forceopcja polega na ignorowaniu stanu zdalnej gałęzi i ustawianiu zatwierdzenia, które do niej wpychasz. Więc git push --force origin feature-branchpo prostu zastępuje origin/feature-branchlokalny feature-branch.

Moim zdaniem ponowne włączanie gałęzi funkcji masteri wypychanie ich z powrotem do zdalnego repozytorium jest OK, o ile tylko ty pracujesz w tej gałęzi.

Zamiast używać -f lub --force programiści powinni używać

--force-with-lease

Dlaczego? Ponieważ sprawdza zdalną gałąź pod kątem zmian, co jest absolutnie dobrym pomysłem. Wyobraźmy sobie, że James i Lisa pracują nad tym samym działem funkcji, a Lisa wprowadziła zatwierdzenie. James zmienia teraz swój oddział lokalny i jest odrzucany, gdy próbuje pchać. Oczywiście James uważa, że ​​dzieje się tak z powodu zmiany bazy i użycia - force i przepisałby wszystkie zmiany Lisy. Gdyby James użył opcji - force-with-leasing, otrzymałby ostrzeżenie, że ktoś dopuścił się popełnienia przestępstwa. Nie rozumiem, dlaczego ktokolwiek używałby --force zamiast --force-with-lease podczas wypychania po rebase.

Zamiast tego użyłbym „checkout -b” i łatwiej to zrozumieć.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

po usunięciu uniemożliwisz wypchnięcie zamykającej gałęzi, która zawiera inny identyfikator SHA. W tym przypadku usuwam tylko gałąź zdalną.

Jednym z rozwiązań jest zrobienie tego, co robi skrypt scalania rebasingu msysGit - po rebase połącz się ze starą głową featurez -s ours. Skończysz z wykresem zatwierdzenia:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... a twoje pchnięcie featurebędzie szybkie.

Innymi słowy, możesz wykonać:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Nie testowano, ale myślę, że to prawda ...)

Może się zdarzyć, że w tej gałęzi jest tylko jeden programista, który teraz (po zmianie bazy) nie jest zgodny z początkiem / funkcją.

Jako taki sugerowałbym użycie następującej sekwencji:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Tak, nowy oddział, to powinno rozwiązać ten problem bez użycia siły, co, jak sądzę, ogólnie jest poważną wadą git.

Moim sposobem na uniknięcie wymuszenia siły jest utworzenie nowej gałęzi i kontynuowanie pracy nad tą nową gałęzią, a po pewnej stabilności usunąć starą gałąź, która została ponownie bazowana:

• Lokalne ponowne uruchomienie pobranej gałęzi
• Rozgałęzienie z oddziału opartego na nowej strukturze do nowego oddziału
• Przekazywanie tej gałęzi jako nowej gałęzi do zdalnego. i usuwanie starego oddziału na pilocie

Inni odpowiedzieli na twoje pytanie. Jeśli zmienisz gałąź, będziesz musiał zmusić ją do popchnięcia.

Rebase i wspólne repozytorium na ogół się nie dogadują. To jest przepisywanie historii. Jeśli inni używają tej gałęzi lub rozgałęziają się z tej gałęzi, zmiana bazy będzie dość nieprzyjemna.

Ogólnie rzecz biorąc, rebase działa dobrze w przypadku zarządzania oddziałami lokalnymi. Zdalne zarządzanie oddziałami działa najlepiej w przypadku jawnych połączeń (--no-ff).

Unikamy również scalania wzorca w gałąź funkcji. Zamiast tego bazujemy na master, ale z nową nazwą oddziału (np. Dodając sufiks wersji). Pozwala to uniknąć problemu zmiany bazy w repozytorium współdzielonym.

Co jest złego git merge masterw featuregałęzi? Pozwoli to zachować pracę, którą wykonałeś, jednocześnie oddzielając ją od gałęzi głównej.

A--B--C------F--G
       \         \
        D--E------H

Edycja: Przepraszam, nie przeczytałem zgłoszenia problemu. Będziesz potrzebował siły podczas wykonywania rebase. Wszystkie polecenia modyfikujące historię będą wymagały --forceargumentu. Jest to bezpieczne, aby zapobiec utracie pracy (stare Di Ezostałyby utracone).

Więc wykonałeś polecenie, git rebasektóre sprawiło, że drzewo wyglądało (chociaż częściowo ukryte jako Di Enie ma już w nazwanej gałęzi):

A--B--C------F--G
       \         \
        D--E      D'--E'

Tak więc, próbując wcisnąć nowy featureoddział (z nim D'i E'w nim), stracisz Di E.

Dla mnie działają następujące proste kroki:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

Po wykonaniu powyższych czynności możemy również usunąć gałąź myFeature, wykonując następujące polecenie:

git push origin --delete myFeature

Poniższe działa dla mnie:

git push -f origin branch_name

i nie usuwa żadnego mojego kodu.

Ale jeśli chcesz tego uniknąć, możesz wykonać następujące czynności:

git checkout master
git pull --rebase
git checkout -b new_branch_name

wtedy możesz wybrać wszystkie swoje zobowiązania do nowego oddziału. git cherry-pick COMMIT ID a następnie pchnij nowy oddział.

Ponieważ PO rozumie problem, po prostu szuka ładniejszego rozwiązania ...

Co powiesz na to jako praktykę?

• Posiadaj w branży rozwijającej funkcje (w której nigdy nie bazujesz na bazach i nie naciskasz na siłę, więc inni twórcy funkcji nie nienawidzą cię). Tutaj regularnie pobieraj te zmiany z głównego za pomocą scalenia. Messier history , tak, ale życie jest łatwe i nikt nie przeszkadza w jego pracy.

• Mają drugą gałąź opracowywania funkcji, w której jeden członek zespołu ds. Funkcji normalnie popycha wszystkie zmiany funkcji, a nawet przekształca je, a nawet wymusza. Więc prawie czysto w oparciu o dość niedawne zatwierdzenie główne. Po zakończeniu funkcji przesuń gałąź na master.

Może już istnieć nazwa wzorca dla tej metody.