Jak (a proč!) Udržovat čistou historii Git commit

Commity jsou jednou z klíčových částí úložiště Git, a ještě více, zpráva o potvrzení je logem života pro úložiště. Jak se projekt / úložiště vyvíjí v průběhu času (přidávání nových funkcí, opravování chyb, refaktorování architektury), jsou zprávy potvrzení místem, kde můžete vidět, co a jak bylo změněno. Je tedy důležité, aby tyto zprávy stručným a přesným způsobem odrážely základní změnu.

Proč je důležitá smysluplná historie potvrzení Git

Co dělá příkaz Git? Zprávy potvrzení Git jsou otisky prstů, které zanecháte v kódu, kterého se dotknete. Jakýkoli kód, který spácháte dnes, za rok, když se podíváte na stejnou změnu; byli byste vděční za jasnou a smysluplnou zprávu o spáchání, kterou jste napsali, a bude také ulehčete život svým kolegům vývojářům. Když jsou komitace izolovány na základě kontextu, chyba, která byla zavedena určitým potvrzením, bude rychlejší k nalezení a tím snadnější je vrátit zpět potvrzení, které chybu způsobilo. / p>

Při práci na velkém projektu často pracujeme s mnoha pohyblivými částmi, které jsou aktualizovány, přidávány nebo odebírány. Zajistit, aby se zprávy o potvrzeních v takových případech udržovaly, by mohlo být složité, zvláště když vývoj trvá několik dní, týdny nebo dokonce měsíce. Abychom zjednodušili úsilí o udržení stručnosti V historii revizí bude tento článek používat některé z běžných situací, kterým může vývojář čelit při práci na úložišti Git.

• Situace 1: Potřebuji změnit nejnovější potvrzení
• Situace 2: Potřebuji změnit konkrétní potvrzení
• Situace 3: Potřebuji přidat, odebrat nebo kombinovat potvrzení
• Situace 4: Moje historie potvrzení se nedělá smysl, potřebuji nový začátek!

Ale než se ponoříme, pojďme rychle projít tím, jak vypadá typický vývojový pracovní postup v naší hypotetické aplikaci Ruby.

Poznámka: Tento článek předpokládá, že jste si vědomi základů Gitu, jak fungují větve, jak přidat nepotvrzené změny větve na scénu a jak tyto změny potvrdit. Pokud si nejste jisti těmito toky, naše dokumentace je skvělým výchozím bodem.

Den v životě

Zde pracujeme na malém projektu Ruby on Rails, kde jsme na domovskou stránku je třeba přidat navigační pohled, což zahrnuje aktualizaci a přidání několika souborů. Následuje podrobný rozpis celého toku:

• Začnete pracovat na funkci s aktualizací souboru ; nechme to nazvat application_controller.rb
• Tato funkce vyžaduje také aktualizaci zobrazení: index.html.haml
• Přidali jste část, která se používá na indexové stránce: _navigation.html.haml
• Styly pro stránku je také třeba aktualizovat, aby odrážely část, kterou jsme přidali: styles.css.scss
• Funkce je nyní připravena s požadovanými změnami, čas také na aktualizaci testů; soubory, které mají být aktualizovány, jsou následující:
  • application_controller_spec.rb
  • navigation_spec.rb
• Testy se aktualizují a předávají podle očekávání, nyní je čas provést změny!

Protože všechny soubory patří do různých teritorií architektury, zavazujeme se změny navzájem izolované, aby bylo zajištěno, že každé potvrzení představuje určitý kontext a je provedeno v určitém pořadí. Obvykle dávám přednost backendu – > pořadí frontendu, kde je nejdříve potvrzena většina změn zaměřených na backend, poté střední vrstva a poté změny zaměřené na frontend v seznamu Git. >

Nyní, když máme naše změny potvrzené, vytvoříme s pobočkou požadavek na sloučení. Jakmile máte otevřenou žádost o sloučení, obvykle ji zkontroluje váš partner, než budou změny sloučeny do repo „s master větve. Nyní se naučme, v jakých různých situacích můžeme skončit během kontroly kódu.

Situace 1: Musím změnit nejnovější potvrzení

Představte si případ, kdy se recenzent podíval na styles.css.scss a navrhl změnu. V takovém případě je velmi jednoduché provést změnu, protože změny šablony stylů jsou součástí posledního potvrzení ve vaší větvi. Takto to můžeme zařídit;

• Provedete přímo nezbytné změny styles.css.scss ve vaší pobočce.
• Jednou jste se změnami hotovi, přidejte tyto změny do fáze; spustit git add styles.css.scss.
• Jakmile jsou změny provedeny, musíme tyto změny přidat do našeho posledního potvrzení; spustit git commit --amend.
  • Rozdělení příkazů: Zde žádáme příkaz git commit o změnu všech změn, které jsou v fáze k nejnovějšímu potvrzení.
• Tím se otevře poslední potvrzení ve vašem textovém editoru definovaném Gitem, který obsahuje zprávu potvrzení Přidat styly pro navigaci.
• Protože jsme aktualizovali pouze deklaraci CSS, nemusíme měnit zprávu o potvrzení.V tomto okamžiku stačí uložit a ukončit textový editor, který pro vás Git otevřel, a vaše změny se projeví v potvrzení.

Protože jste upravili existující potvrzení, jsou tyto změny povinné být vynuceně tlačen do vzdáleného repo pomocí git push --force-with-lease <remote_name> <branch_name>. Tento příkaz přepíše potvrzení Add styles for navigation na vzdáleném repo s aktualizovaným potvrzením, které jsme právě vytvořili v našem místním repo.

Je třeba mít na paměti jednu věc a zároveň tlačit větve je to, že pokud pracujete na stejné větvi s více lidmi, vynucení vynucení může způsobit potíže ostatním uživatelům, když se pokusí normálně poslat své změny na vzdálené větvi, která má nové vynucené vynucené vynucení. Proto tuto funkci používejte moudře. Zde se můžete dozvědět více o možnostech tlačení síly Git zde.

Situace 2: Potřebuji změnit konkrétní potvrzení

V předchozí situaci byla oprava poměrně jednoduchá, protože jsme ji museli upravit pouze náš poslední příkaz Git, ale představte si, že recenzent navrhl něco změnit v _navigation.html.haml. V tomto případě jde o druhé potvrzení shora, takže jeho změna nebude tak přímá jako v první situaci. Podívejme se, jak to zvládneme:

Kdykoli je potvrzení vyrobený ve větvi, je identifikován jedinečným hashovacím řetězcem SHA1. Představte si to jako jedinečné ID, které odděluje jeden potvrzení od druhého. Všechny revize a jejich hash SHA1 ve větvi můžete zobrazit spuštěním git log. S tímto byste viděli výstup, který vypadá poněkud takto, kde jsou nejnovější revize nahoře;

Zde vstupuje do hry příkaz git rebase. Kdykoli si přejeme upravit konkrétní potvrzení pomocí git rebase, musíme nejprve rebázovat naši větev přesunutím zpět HEAD do bodu těsně před potvrzením, které chceme upravit. V našem případě musíme změnit potvrzení, které čte Page Navigation View.

Zde si všimněte hodnoty hash potvrzení, která je těsně před potvrzením, které chceme upravit; zkopírujte hash a proveďte následující kroky:

• Přemístěte větev tak, aby se přesunula na potvrzení před naším cílovým potvrzením; spustit git rebase -i 8d74af102941aa0b51e1a35b8ad731284e4b5a20
  • Rozdělení příkazů: Zde spouštíme příkaz Git „rebase s interaktivním režimem s poskytovaným hashem SHA1 jako potvrzení rebase na.
• Tím se spustí příkaz rebase pro Git v interaktivním režimu a otevře se textový editor zobrazující všechny vaše závazky, které přišly po potvrzení, na které jste rebasovali . Bude to vypadat nějak takto:

Všimněte si, jak má každé potvrzení slovo pick před ním a v obsahu níže jsou všechna možná klíčová slova, která můžeme použít. Protože chceme upravit potvrzení, musíme změnit pick 4155df1cdc7 Page Navigation View na edit 4155df1cdc7 Page Navigation View. Uložte změny a ukončete editor.

Nyní je vaše větev rebasována do bodu v čase těsně před provedením potvrzení, které zahrnovalo _navigation.html.haml. Otevřete soubor a proveďte požadované změny podle zpětné vazby ke kontrole. Jakmile jste se změnami hotovi, připravte je spuštěním git add _navigation.html.haml.

Jelikož jsme provedli změny, je čas přesunout větev HEAD zpět do potvrzení, které jsme původně měli (a to včetně nových změn, které jsme přidali), spuštění git rebase --continue, tím se v terminálu otevře váš výchozí editor a zobrazí se vám zpráva o potvrzení, kterou jsme upravili během rebase; Page Navigation View. Tuto zprávu můžete změnit, pokud si přejete, ale necháme ji tak, jak je prozatím, uložte a ukončete editor. V tomto okamžiku Git přehraje všechny závazky který následoval po právě provedeném potvrzení a nyní větev HEAD je zpět k nejvyššímu potvrzení, které jsme původně měli, a zahrnuje také nové změny, které jste provedli v jednom ze závazků.

Jelikož jsme znovu upravili revizi, která již existuje ve vzdáleném repo, potřebujeme vynutit tuto větev znovu pomocí git push --force-with-lease <remote_name> <branch_name>.

Situace 3 : Potřebuji přidat, odebrat nebo kombinovat potvrzení

Běžná situace je, když jste udělali několik závazků, jen abyste opravili něco, co bylo dříve spácháno. Nyní je pojďme omezit, jak to jen půjde, a zkombinujeme je s původními revizemi.

Vše, co musíte udělat, je spustit interaktivní rebase, jako byste to udělali v ostatních scénářích.

Představte si, že chcete všechny tyto opravy zkombinovat do c22a3fa0c5c Render navigation partial. Stačí:

1. Přesuňte opravy nahoru tak, aby byly přímo pod potvrzením, které chcete na konci ponechat.
2. Změňte pick na squash nebo fixup pro každou z oprav.

Poznámka: squash ponechá zprávy o potvrzení v popisu. fixup zapomene zprávy o potvrzení oprav a ponechá původní.

Skončíte s něčím takovým:

Uložte změny a ukončete editor „a jste hotovi! Toto je výsledná historie:

Stejně jako dříve, vše, co musíte udělat, je nyní git push --force-with-lease <remote_name> <branch_name> a změny jsou nahoře.

Pokud chcete úplně odstranit potvrzení z větve, místo squash nebo fixup, stačí napsat drop nebo tento řádek jednoduše smazat.

Vyhněte se konfliktům

Abyste se vyhnuli konfliktům, ujistěte se, že vás zaváže „pohybuji se po časové ose nahoru“, nedotýká se stejných souborů, kterých se dotkly závazky, které po nich zůstaly.

: Rychlé opravy

Pokud přesně víte, které potvrzení chcete opravit, při provádění nemusíte plýtvat mozkovými cykly přemýšlením o dobrých dočasných jménech pro „opravu 1“, „opravu 2“,…, „Fix 42“.

Krok 1: Seznamte se --fixup

Poté, co provedete změny, které opravují vše, co je třeba opravit, stačí Git provést všechny tyto změny takto:

(Všimněte si, že toto je hash pro potvrzení c22a3fa0c5c Render navigation partial)

Tím se vygeneruje tato zpráva potvrzení: fixup! Render navigation partial.

Krok 2: A pomocník --autosquash

Snadné interaktivní rebase. git Můžete fixup umístit automaticky na správné místo.

git rebase -i 4155df1cdc7 --autosquash

Historie bude zobrazena takto:

Jste připraveni pouze zkontrolujte a pokračujte.

Pokud se cítíte dobrodružně, můžete provést neinteraktivní rebase git rebase --autosquash, ale pouze pokud rádi žijete nebezpečně, jako vy nemám příležitost zkontrolovat, zda se tykve vyrábějí dříve, než se znovu použijí.

Situace 4: Moje historie spáchání Gitu nemá smysl, potřebuji nový začátek!

Pokud bychom „Pracujeme na velké funkci, je běžné mít několik oprav a změn zpětné vazby, které jsou prováděny často. Místo neustálého rebasingu pobočky můžeme ponechat vyčištění závazků až do konce vývoje.

Tady je vytváření souborů oprav velmi užitečné. Soubory oprav byly ve skutečnosti primárním způsobem sdílení kódu prostřednictvím e-mailu při spolupráci na velkých projektech s otevřeným zdrojovým kódem, než byly vývojářům k dispozici služby založené na Git, jako je GitLab. Představte si, že máte jednu takovou větev (např. add-page-navigation), kde existuje spousta závazků, které jasně neprojevují základní změny. Zde můžete vytvořit soubor opravy pro všechny změny, které jste provedli v této větvi:

• Prvním krokem k vytvoření souboru opravy je ujistit se, že vaše pobočka obsahuje všechny změny z master větev a nemá s ní žádné konflikty.
• Během kontroly můžete spustit git rebase master nebo git merge master v add-page-navigation větvi, abyste získali všechny změny z master ve vaší pobočce.
• Nyní vytvořte soubor opravy ; run git diff master add-page-navigation > ~/add_page_navigation.patch.
  • Rozdělení příkazů: Zde používáme funkci rozdílu Git a žádáme o rozdíl mezi master větev a add-page-navigation větev a přesměrování výstupu (přes > symbol) do souboru s názvem add_page_navigation.patch v nás domovský adresář (obvykle ~/ v operačních systémech * nix).
• Můžete zadat libovolnou cestu, kterou si chcete tento soubor ponechat. a název souboru a přípona může být cokoli chcete.
• Jakmile je příkaz spuštěn a nevidíte žádné chyby, vygeneruje se soubor opravy.
• Nyní pokladna master větev; spustit git checkout master.
• Odstranit větev add-page-navigation z místního úložiště; spustit git branch -D add-page-navigation. Pamatujte, že změny ve této větvi již máme ve vytvořeném souboru opravy.
• Nyní vytvořte novou větev se stejným názvem (zatímco master je zaškrtnuto); spustit git checkout -b add-page-navigation.
• V tomto okamžiku se jedná o novou větev a nemá žádné z vašich změn.
• Nakonec použijte vaše změny ze souboru opravy; git apply ~/add_page_navigation.patch.
• Zde jsou všechny vaše změny použity ve větvi a budou vypadat jako nezávazné, jako by všechny vaše úpravy kde hotovo, ale žádná z úprav nebyla ve větvi skutečně potvrzena.
• Nyní můžete pokračovat a odevzdat jednotlivé soubory nebo soubory seskupené podle oblasti dopadu v požadovaném pořadí pomocí stručných zpráv o potvrzení.

Stejně jako v předchozích situacích jsme v podstatě upravili celou větev, takže je čas vynutit tlačit!

Závěr

Zatímco jsme se zabývali nejběžnějšími a nejzákladnějšími situacemi, které vznikají v každodenním pracovním postupu s Git, přepisování historie Git je rozsáhlé téma a jak se seznámíte s výše uvedené tipy, můžete se dozvědět pokročilejší koncepty týkající se daného tématu v oficiální dokumentaci Git. Šťastné gitování!

Foto: pan xiaozhen na Unsplash