Dlaczego każde poważne repozytorium Github, które ściągam, każe mi zmiażdżyć moje zobowiązania w jednym zatwierdzeniu?

Myślałem, że dziennik git jest tam, abyś mógł sprawdzić całą swoją historię i zobaczyć dokładnie, jakie zmiany się tam zdarzyły, ale zgniatanie go wyciąga go z historii i łączy w jedno zatwierdzenie. O co chodzi?

Wydaje się to również sprzeczne z mantrą „popełnij wcześnie i popełnij często”.

Abyś miał jasną i zwięzłą historię gitów, która jasno i łatwo dokumentuje dokonane zmiany i powody.

Na przykład typowy dla mnie „niezaprzeczalny” dziennik git może wyglądać następująco:

7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Co za bałagan!

Podczas gdy bardziej starannie zarządzany i scalony dziennik git z dodatkowym naciskiem na wiadomości może wyglądać następująco:

7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language

Myślę, że ogólnie widzisz sens zgniatania zatwierdzeń i ta sama zasada dotyczy żądań ściągania - Czytelność historii. Możesz także dodawać do dziennika zmian, który ma już setki, a nawet tysiące zatwierdzeń, co pomoże utrzymać krótką i zwięzłą historię.

Chcesz popełniać wcześnie i często. Jest to najlepsza praktyka z wielu powodów. Uważam, że prowadzi mnie to często do zatwierdzania „wip” (praca w toku) lub „część A zrobiona” lub „literówka, drobna poprawka”, gdzie używam git, aby pomóc mi w pracy i dać mi punkty pracy, które Mogę wrócić do tego, jeśli poniższy kod nie działa w miarę postępu pracy. Jednak nie potrzebuję ani nie chcę tej historii jako części ostatecznej historii gita, więc mogę zmiażdżyć swoje commity - ale zobacz uwagi poniżej, co to znaczy w gałęzi programistycznej vs. master.

Jeśli istnieją główne kamienie milowe, które reprezentują odrębne etapy robocze, nadal może być więcej niż jeden zatwierdzenie na funkcję / zadanie / błąd. Może to jednak często uwypuklać fakt, że opracowywany bilet jest „zbyt duży” i należy go podzielić na mniejsze części, które mogą być niezależne, na przykład:

8754390gf87... Implement feature switches

wygląda jak „1 praca”. Albo istnieją, albo nie! Wydaje się, że nie ma sensu go rozwodzić. Jednak doświadczenie pokazało mi, że (w zależności od wielkości i złożoności organizacji) bardziej szczegółową ścieżką może być:

fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI

Małe kawałki oznaczają łatwiejsze przeglądy kodu, łatwiejsze testowanie jednostek, lepszą możliwość qa, lepsze dostosowanie do zasady pojedynczej odpowiedzialności itp.

Praktyczne momenty, w których faktycznie należy wykonywać takie squashy, są w zasadzie dwoma odrębnymi etapami, które mają swój własny przebieg pracy

• twój rozwój, np. żądania ściągania
• twoja praca dodana do głównej gałęzi, np. master

Podczas rozwoju popełniasz „wcześnie i często” oraz za pomocą szybkich komunikatów „jednorazowych”. Czasami możesz chcieć zgnieść tutaj, np. Zgnieść w celu wyczyszczenia i zatwierdzenia wiadomości do zrobienia. W oddziale można zachować wiele zatwierdzeń, które reprezentują różne kroki, które wykonałeś w fazie rozwoju. Większość squashów, które wybierzesz, powinna znajdować się w tych gałęziach funkcji, podczas gdy są one rozwijane, a przed scaleniem do opanowania.
Podczas dodawania do gałęzi głównej chcesz, aby zatwierdzenia były zwięzłe i poprawnie sformatowane zgodnie z istniejącą historią głównej. Może to obejmować identyfikator systemu śledzenia biletów, np. JIRA, jak pokazano w przykładach. Squashing tak naprawdę nie ma tu zastosowania, chyba że chcesz „zrolować” kilka różnych zatwierdzeń na master. Zwykle nie.

Użycie --no-ffpodczas scalania z master spowoduje użycie jednego zatwierdzenia do scalenia, a także zachowanie historii (w oddziale). Niektóre organizacje uważają to za najlepszą praktykę. Zobacz więcej na https://stackoverflow.com/q/9069061/631619 Zobaczysz również praktyczny efekt, w git logktórym --no-ffzatwierdzenie będzie ostatnim zatwierdzeniem, na górze HEAD (gdy właśnie zrobione), podczas gdy bez --no-ffniego może być w dalszej części historii, w zależności od dat i innych zobowiązań.

Ponieważ często osobie zajmującej się PR-em zależy na efekcie netto zatwierdzeń „dodana funkcja X”, a nie o „szablony podstawowe, funkcja poprawki błędów X, dodawanie funkcji Y, poprawione literówki w komentarzach, skorygowane parametry skalowania danych, mapa skrótów działa lepiej niż lista „... poziom szczegółowości

Jeśli uważasz, że twoje 16 zatwierdzeń najlepiej reprezentują 2 zatwierdzenia zamiast 1 „Dodano funkcję X, zmieniono fakt, że Z używa X”, to prawdopodobnie dobrze jest zaproponować pr z 2 zatwierdzeniami, ale wtedy najlepiej byłoby zaproponować 2 oddzielne pr w tym przypadku (jeśli repo nadal nalega na pojedyncze zatwierdzenia pr)

Nie jest to sprzeczne z mantrą „wcześnie i często popełniaj”, tak jak w repozytorium, podczas gdy wciąż się rozwijasz, nadal masz szczegółowe informacje, więc masz minimalną szansę na utratę pracy, a inni ludzie mogą przeglądać / wyciągać / proponować pr jest przeciw twojej pracy podczas opracowywania nowego pr.

Główny powód tego, co widzę, jest następujący:

• Interfejs GitHub do łączenia żądań ściągania obecnie (październik 2015 r.) Nie pozwala na edycję pierwszego wiersza komunikatu zatwierdzenia, zmuszając go do Merge pull request #123 from joebloggs/fix-snafoo
• Interfejs GitHub do przeglądania historii zatwierdzeń obecnie nie pozwala na przeglądanie historii oddziału z --first-parentpunktu widzenia
• Interfejs GitHub do przeglądania winy za plik obecnie nie pozwala na przeglądanie winy pliku za pomocą --first-parentpunktu widzenia (zauważ, że zostało to naprawione tylko w Git 2.6.2, więc możemy wybaczyć GitHub za to, że go nie ma dostępny)

Kiedy więc połączysz wszystkie trzy powyższe sytuacje, otrzymasz sytuację, w której łączenie niesprawdzonych zatwierdzeń wygląda brzydko z interfejsu użytkownika GitHub.

Twoja historia ze zgniecionymi zobowiązaniami będzie wyglądać jak

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... Hotfix for android display issue
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... Implemented pop-up to select language

Podczas gdy bez zgniecionych zobowiązań historia będzie wyglądać jak

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... hotfix for #5849564648
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Gdy masz dużo zatwierdzeń w śledzeniu PR, w którym nastąpiła zmiana, może to być koszmar, jeśli ograniczysz się do korzystania z interfejsu GitHub .

Na przykład, gdzieś w pliku znajduje się odwołanie do wskaźnika zerowego, więc mówisz „kto to zrobił i kiedy? Na jakie wersje wydania ma to wpływ?”. Następnie wędrujesz do widoku winy w interfejsie GitHub i widzisz, że linia została zmieniona789fdfffdf... „och, ale poczekaj sekundę, linia właśnie zmieniała swoje wcięcie, aby pasowała do reszty kodu”, więc teraz musisz przejść do stanu drzewa dla tego pliku w zatwierdzeniu nadrzędnym i ponownie odwiedzić strona z winami ... w końcu znajdziesz zatwierdzenie ... to zatwierdzenie sprzed 6 miesięcy ... "och **** to może mieć wpływ na użytkowników przez 6 miesięcy" mówisz ... ach, ale poczekaj, to zatwierdzenie był w rzeczywistości w żądaniu ściągnięcia i został połączony dopiero wczoraj i nikt jeszcze nie wydał nowego wydania ... „Cholera, ludzie, że łączysz zobowiązania bez marnowania historii” to krzyk, który zwykle można usłyszeć po około 2 lub 3 wyprawach z archeologii za pośrednictwem Interfejs GitHub

Zastanówmy się teraz, jak to działa, jeśli używasz wiersza polecenia Git (i super-niesamowite 2.6.2, które ma poprawkę git blame --first-parent)

• Jeśli korzystasz z wiersza polecenia Git, będziesz w stanie całkowicie kontrolować komunikat zatwierdzenia scalania, a zatem zatwierdzenie scalania może mieć ładną linię podsumowania.

Tak wyglądałaby nasza historia zmian

$ git log
1256556316... #423 Added new slideshow feature
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... #324 Hotfix for android display issue
787g8fgf78... hotfix for #5849564648
f56556316e... #28 Implemented pop-up to select language
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Ale możemy też

$ git log --first-parent
1256556316... #423 Added new slideshow feature
56556316ad... #324 Hotfix for android display issue
f56556316e... #28 Implemented pop-up to select language

(Innymi słowy: Git CLI pozwala ci zjeść ciasto i zjeść je)

Teraz, gdy natrafimy na problem ze wskaźnikiem zerowym ... cóż, po prostu używamy git blame --first-parent -w dodgy-file.ci natychmiast dostajemy dokładne zatwierdzenie, w którym odwołanie do wskaźnika zerowego zostało wprowadzone do gałęzi głównej, ignorując proste zmiany białych znaków.

Oczywiście, jeśli wykonujesz scalenia za pomocą interfejsu GitHub, to git log --first-parentjest naprawdę kiepski dzięki GitHub wymuszającemu pierwszy wiersz komunikatu zatwierdzenia scalania:

1256556316... Merge pull request #423 from jrandom/add-slideshows
56556316ad... Merge pull request #324 from ahacker/fix-android-display
f56556316e... Merge pull request #28 from somwhere/select-lang-popup

Krótko mówiąc:

Interfejs GitHub (październik 2015 r.) Ma szereg niedociągnięć w sposobie łączenia żądań ściągania, prezentacji historii zatwierdzeń i przypisywania informacji o winie. Obecnie najlepszym sposobem na włamanie się do tych usterek w interfejsie GitHub jest poproszenie ludzi o zmiażdżenie swoich zobowiązań przed połączeniem.

Interfejs Git CLI nie ma tych problemów i możesz łatwo wybrać widok, który chcesz zobaczyć, dzięki czemu możesz zarówno odkryć powód, dla którego dokonano konkretnej zmiany w ten sposób (patrząc na historię niezakwestionowanych zmian), a także zobacz skutecznie zgniecione zatwierdzenia.

Post Script

Ostatnim powodem często cytowanym przy zatwierdzaniu zgniatania jest ułatwienie backportowania ... jeśli masz tylko jedno zatwierdzenie do tylnego portu (tj. Zgniecione zatwierdzenie), łatwo jest wybrać cherry ...

Cóż, jeśli patrzysz na historię gitów git log --first-parent, możesz po prostu wybrać zatwierdzenia scalania. Większość ludzi ma mylące zatwierdzenia scalania podczas pobierania, ponieważ musisz określić -m Nopcję, ale jeśli dostałeś zatwierdzenie git log --first-parent, wiesz, że jest to pierwszy rodzic, którego chcesz śledzić, więc będziegit cherry-pick -m 1 ...

Zgadzam się z opiniami wyrażonymi w innych odpowiedziach w tym wątku na temat pokazywania jasnej i zwięzłej historii dodanych funkcji i naprawionych błędów. Chciałem jednak odnieść się do innego aspektu, do którego pańskie pytanie umknęło, ale nie zostało wyraźnie stwierdzone. Częścią zawieszania się niektórych metod pracy gita jest to, że git pozwala przepisać historię, która wydaje się dziwna, gdy wprowadza się go do gita po użyciu innych form kontroli źródła, w których takie działania są niemożliwe. Co więcej, jest to również sprzeczne z ogólnie przyjętą zasadą kontroli źródła, że ​​gdy coś zostanie zatwierdzone / wpisane do kontroli źródła, powinieneś być w stanie powrócić do tego stanu bez względu na zmiany, które wprowadzisz po tym zatwierdzeniu. Jak sugerujesz w swoim pytaniu, jest to jedna z takich sytuacji. Myślę, że git to świetny system kontroli wersji; jednak, aby to zrozumieć, musisz zrozumieć niektóre szczegóły implementacji i decyzje projektowe, w wyniku czego ma on bardziej stromą krzywą uczenia się. Pamiętaj, że git miał być rozproszonym systemem kontroli wersji, który pomoże wyjaśnić, dlaczego projektanci zezwalają na przepisywanie historii git, a zatwierdzenia squasha są tego przykładem.

Ze względu na perspektywę ... Najlepszą praktyką jest posiadanie jednego zatwierdzenia na jeden <<issue-management-system>>problem, jeśli to możliwe.

Możesz mieć tyle zatwierdzeń, ile chcesz we własnym oddziale / repozytorium funkcji, ale twoja historia jest istotna dla tego, co robisz teraz dla twojej perspektywy ... to nie jest HISTORIA dla całego ZESPOŁU / PROJEKTU lub aplikacji z ich perspektywa do zachowania za kilka miesięcy ...

Tak więc za każdym razem, gdy chcesz zatwierdzić naprawę błędu lub funkcję do wspólnego repozytorium (ten przykład dotyczy gałęzi developerskiej), możesz to zrobić w następujący sposób:

jak zmienić bazę gałęzi funkcji, aby szybko się rozwijać

    # set your current branch , make a backup of it , caveat minute precision
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # squash all your changes at once 
    git reset $(git merge-base develop $curr_branch)

    # check the modified files to add 
    git status

    # add the modified files dir by dir, or file by file or all as shown
    git add --all 

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # add the single message of your commit for the stuff you did 
    git commit -m "<<MY-ISSUE-ID>>: add my very important feature"

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # make a backup once again , use seconds precision if you were too fast ... 
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # compare the old backup with the new backup , should not have any differences 
    git diff <<old-backup>>..<<new-backup-branch>>


    # you would have to git push force to your feature branch 
    git push --force 

Chciałbym sprawdzić, czy kod zostanie opublikowany, czy nie.

Gdy projekty pozostają prywatne:

Polecam nie zgniatać i nie zobaczyć, jak powstaje kiełbasa. Jeśli używasz dobrych i małych zatwierdzeń, narzędzia takie jak git bisect są bardzo przydatne i ludzie mogą szybko wskazać zatwierdzenia regresji i zobaczyć, dlaczego to zrobiłeś (z powodu komunikatu zatwierdzenia).

Kiedy projekty stają się publiczne:

Zmiażdż wszystko, ponieważ niektóre zmiany mogą zawierać przecieki bezpieczeństwa. Na przykład hasło, które zostało ponownie zatwierdzone i usunięte.