Dlaczego squit git zatwierdza żądania ściągania?

199

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”.

git github branching pull-requests etiquette hamstar
źródło
1
W przypadku dużego repozytorium oszczędza dużo czasu i miejsca, gdy ludzie chcą zrobić z nim repozytorium.
raptortech97,
8
„ Wydaje się to również sprzeczne z mantrą„ wcześnie popełniasz i często popełniasz ” . A recenzent nie chce ich przeglądać, to na pewno.
JensG
7
W pytaniu nie trzeba umieszczać edycji, aby podsumować, na czym polega odbierana odpowiedź. To miejsce akceptowanych odpowiedzi i entuzjastów. Ludzie mogą wyciągać własne wnioski z czytania odpowiedzi.
5
Nadal nie rozumiem, dlaczego istnieje chęć zgniatania spraw. Myślę, że jest o wiele za dużo wad do zgniatania bez prawie żadnych plusów. Jest to problem prezentacji podszywający się pod problem danych.
mkobit
3
Wszelkie przydatne analizy w dzienniku są tracone przez squash. Wygląda więc na to, że programista stworzył funkcję z jednym zatwierdzeniem. Trudno też zrozumieć, dlaczego istnieje nieparzysty fragment kodu. Historia funkcji może być ważna i może znacznie przyczynić się do wyjaśnienia, dlaczego kod jest taki, jaki jest. Zwięzły widok dziennika jest przydatny, ale czy nie można go osiągnąć w inny sposób?
Tjaart

Odpowiedzi:

158

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ń.

Michael Durrant
źródło
30
Całkowicie nie zgadzam się z tą filozofią. Małe regularne zatwierdzenia dzielą zadanie na mniejsze i często dostarczają użytecznych informacji o tym, nad czym dokładnie pracowano przy zmianie linii. Jeśli masz małe zatwierdzenia „WIP”, powinieneś użyć interaktywnej bazy, aby to wyczyścić przed ich wypchnięciem. Zgniatanie PR wydaje się całkowicie pokonać punkt zwykłych małych zatwierdzeń IMHO. To prawie brak szacunku dla autora, który podjął wysiłek, aby przekazać wiadomości dziennika z konkretnymi informacjami o zatwierdzeniu, a ty po prostu je wyrzucisz.
Jez
6
Ciekawy. Pod koniec dnia opieram swoją „filozofię” na tym, co widziałem. Żeby było jasne - podział pracy na małe części i zaangażowanie każdego z nich jest świetny podczas pracy nad zmianą. Z mojego doświadczenia wynika, że po scaleniu tej pracy z mistrzem, główną rzeczą, która ma tendencję do badania, jest „co, w całości, to jest to zatwierdzenie scalania, które (zwykle) powodowało problemy x ...
Michael Durrant
6
Jestem także przeciwnikiem squasha. Nie powinieneś pisać głupich komunikatów zatwierdzania. I w przykładzie (85493g2458 ... Naprawiono problem z wyświetlaniem pokazu slajdów w np.) Byłoby to o wiele bardziej pomocne, gdybym miał debugować kod z nim związany.
Thomas Davis
5
Szkoda, że ​​taki nieostrożny i źle postawiony dogmat pojawił się w praktyce SCM. Narzędzia do filtrowania powinny być wykorzystywane do zarządzania czytelnością historii, a nie do zachowania.
ctpenrose,
4
niepokojące trendy i dogmaty. yow. Wolałbym bardziej oparty na faktach argument przedstawiony w bardziej przyjemny sposób. Zapraszamy do publikowania / głosowania w innej opinii. Taki jest sens głosowania w społeczności
Michael Durrant
26

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.

Andrew Hill
źródło
4
Ale kiedy zgniatasz zobowiązania, również tracisz tę historię na swoim widelcu, prawda? Dlaczego chcesz wyrzucić tę historię?
hamstar
4
a) jeśli chcesz zachować historię w swoim oddziale, łatwo jest mieć oddział „for merge” i oddział „dev” (które i tak mogą być potrzebne, ponieważ możesz dodawać nowe zmiany do głównego dewelopera gałąź po zaproponowaniu PR) b) nadal zachowujesz efekt netto tych zatwierdzeń, tylko w przypadkach, w których chcesz cofnąć lub wybrać podskładnik PR, potrzebne będą indywidualne zatwierdzenia . W takim przypadku prawdopodobnie robisz wiele rzeczy (np .: poprawka X, dodaj funkcję Y) w jednym PR i może być potrzebnych wiele PR.
Andrew Hill
@AndrewHill, co za świetna koncepcja! Chcę przedstawić ten obieg pracy mojemu zespołowi. Jak to działa dla Ciebie? Napisałem o nim post na blogu i natknąłem się na ten komentarz podczas jego badania.
Droogans,
19

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 ...

Stephen Connolly
źródło
1
Niezła odpowiedź! Ale wybór zakresu jest dość łatwy, nie jestem pewien, czy kupiłem go jako powód.
Stiggler
1
@stiggler Osobiście nie kupuję tego jako powodu, ale widziałem to jako powód cytowany przez innych. IMHO narzędzie git jest tym, czego chcesz, a zgniatanie spraw jest złe ... ale powiedziałbym, że poprowadziłem naprawę --first-parentsiebie, aby wygrać spór o zgniatanie spraw ;-)
Stephen Connolly
1
To powinna być zaakceptowana odpowiedź. O wiele mniej dogmatów, co pokazuje, że filtrowanie historii można wykorzystać do „jedzenia ciasta i jedzenia go”. Nie musisz anihilować historii, aby zapewnić jasność eksploracjom historii.
ctpenrose,
Wybór nie będzie tak łatwy, jeśli przez zmiażdżenie twoich zobowiązań ostatecznie zgrupujesz wiele zmian w różnych plikach w jednym zatwierdzeniu. Wydaje mi się, że jest to bardzo różne w zależności od podstawy kodu, wprowadzonych zmian, liczby osób współpracujących itd. Nie sądzę, abyśmy mogli wymyślić jedną ogólną zasadę, która obowiązywałaby we wszystkich przypadkach.
Amy Pellegrini,
2

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.

Fred Thomsen
źródło
Ściśle mówiąc, Git nie pozwala ci zmieniać historii. Obiekty zatwierdzania są niezmienne. Tylko wskaźniki gałęzi są modyfikowalne, i tylko z „wymuszoną aktualizacją”, która jest ogólnie uważana za coś, co robisz tylko w celach programistycznych, a nie w gałęzi master. Zawsze możesz wrócić do poprzedniego stanu, korzystając z dziennika, chyba git gcże uruchomiono go w celu odrzucenia niepowiązanych obiektów.
Jon Purdy
Masz rację i być może powinienem był o tym wspomnieć powyżej. Jednak opowiadałbym się za czymś takim jak wymuszanie wypychania lub zmiany zatwierdzeń, które już zostały wypchnięte do zdalnego repo, kwalifikowałoby się jako przepisywanie historii, ponieważ kolejność i układ zatwierdzeń są tak samo ważne jak same zatwierdzenia.
Fred Thomsen
Dotyczy to danego zatwierdzenia. Na większym obrazie myślę o interaktywnym rebasingu i odgałęzieniu filtra jako o efektywnym przepisywaniu historii poprzez zmianę jej składu.
Michael Durrant
1
Aby być uczciwym, SVN utrzymuje podejście „każde zatwierdzenie jest święte”, ale podczas łączenia tworzy pojedyncze zatwierdzenie z tym połączeniem i ukrywa poprawki, które się do tego przyczyniły, więc wygląda na to, że wszystkie połączenia SVN są „bazowane”. Nie są, wystarczy, że powiesz komendzie historii, aby pokazać scalone komponenty. Najbardziej podoba mi się to podejście.
gbjbaanb
1

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
Yordan Georgiev
źródło
to nawet nie próbuje odpowiedzieć na zadane pytanie, dlaczego squash git popełnia żądania ściągania? Zobacz, jak odpowiedzieć
komara
po próbie wyjaśnienia powinien to zrobić ...
Yordan Georgiev
Jakoś nie rozumiem, w jaki sposób dodane objaśnienie oferuje coś istotnego w stosunku do poczynionych i wyjaśnionych w głosowanych odpowiedziach, które zostały opublikowane kilka lat temu (choć doceniamy wysiłki w celu poprawy pierwszej wersji)
gnat
słowo kluczowe to „perspektywa”, koncepcja perspektywy znacznie ułatwia wyjaśnianie tego typu problemów w IT, na przykład - twoja perspektywa odpowiedzi na to pytanie jest już podana, moja perspektywa używa słowa kluczowego „perspektywa” i stanowi praktyczny przykład tego, jak wdrożyć tę samą najlepszą praktykę objaśnioną z różnych perspektyw ...
Yordan Georgiev
1

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.

Vince V.
źródło