W jaki sposób te zatwierdzenia git zostały zduplikowane do niewłaściwej gałęzi?

Question

Próbuję pomóc współpracownikowi dowiedzieć się, o co chodziło w ostrzeżeniu o "pustym zatwierdzeniu" w ostatnim scaleniu. Otworzyłem gitk i zobaczył coś takiego:

_o (Z) Merge branch 'new-branch'        (yesterday) 
o | (Y) Fix bad merge           (person 1) 
o_| (X) Merge branch 'master' into new-branch     (recent) 
o | (W) Last legitimate commit that belongs on new-branch  (person 1) 
| |  ... work on master ... 
o | (F) Legitimate commit that actually belongs on new-branch (person 2) 
| |  ... work on master ... 
o | (E) Legitimate commit that should have been on master  (person 2) 
o | (D') Even more work etc...        (committed by person 2) 
o | (C') More work in master         (committed by person 2) 
o | (A') Normal work in master        (committed by person 2) 
| o (D) Even more work etc...         (authored by random person) 
| o (C) More work in master         (authored by random person) 
o | (B) Starting to work on new-branch      (person 1) 
|_o (A) Normal work in master         (authored by random person) 
o Common Ancestor            (weeks ago) 

Tak oczywiście dwie osoby pracujące w tej branży powinny połączyły się z mistrzem w swojej branży coraz częściej, a następnie te stosy ostrzeżeń scalania byłaby bardziej oczywista . Członek zespołu, którego nazwisko znajdowało się w polu "committer" zduplikowanych commitów, mówi, że prawdopodobnie wykonał pull -rebase, aby je wywołać, ale nie mogę zawinąć głowy, jak to działa. Czy ktoś może wyjaśnić, co mogło się stać?

Nie szukam sposobu naprawienia ostrzeżeń o scalaniu, ponieważ wydawały się łagodne. Chcę tylko zrozumieć, co się stało, więc mogę zapobiec temu w przyszłości. Mój zespół jest stosunkowo nowy w git, więc staram się pomóc im zrozumieć go o krok po kroku, wykorzystując próbę i błąd w większości.

Dzięki!

Answer 1

Po wykonaniu ponownej operacji w oddziale, przepisuje się historię tej gałęzi. Wszystkie zatwierdzone zatwierdzenia będą miały przynajmniej zmienione identyfikatory (nawet jeśli nie nastąpiła zmiana treści w ramach zatwierdzenia). Z tego powodu może się wydawać, że masz zduplikowane zatwierdzenia, których w rzeczywistości nie masz. Masz dwa różne zatwierdzenia z tą samą zawartością.

Sposób na odtworzenie tego zachowania "duplikatów zatwierdzeń" polega zwykle na dokonaniu przejęcia gałęzi, która została już przekazana do zdalnego repozytorium, a następnie scaleniu z powrotem do tej samej gałęzi zdalnej. Baza danych zmieni identyfikatory Twoich zatwierdzeń, a scalenie zachowa obie pary "duplikatów", nawet jeśli ich zmiany spowodują tę samą treść.

1. W istniejącego repozytorium, należy utworzyć nowy oddział „fabularny” z „master” oddział : git checkout -b feature
2. Dodaj nowy plik „file-feature.txt” i zobowiązać go na „funkcji” oddział : git add . ; git commit -m "added new file on master branch"
3. Przełączenie na „master” gałęzi i dodać inny nowy plik tam i zobowiązać się, że zbyt: git checkout master ; git add . ; git commit -m "added new file on master branch"
4. push oddział funkcja na zdalnym repozytorium: git checkout feature ; git push --set-upstream origin feature
5. teraz wykonaj rebase gałęzi "feature" na gałąź "master": git rebase master
6. Jeśli teraz spróbujesz przesunąć gałąź "cech" do zdalnego repozytorium, pojawi się błąd, który musisz wykonać "git pull" pierwszy. To jest punkt, w którym faktycznie dostajesz "duplikaty" zatwierdzenia, ponieważ scalenie (git pull jest skrótem dla git fetch ; git merge), pamiętaj też, że zawartość commitów jest taka sama, ale z powodu zmiany nazwy gałęzi, identyfikatory commitów są teraz inne i dlatego są uważane za coś innego, więc: git pull
7. Sprawdź swoją gałąź teraz w GUI, z "git gui" (przejdź do menu głównego - Repozytorium - Wizualizuj historię funkcji), a będziesz zobaczyć coś takiego:
8. Albo po prostu użyć git log go zobaczyć bezpośrednio w linii poleceń: