Interaktivní rebaze se někdy nazývá „švýcarský armádní nůž“ systému Git – protože obsahuje tolik různých nástrojů pro tolik různých případů použití! Existuje však jeden hlavní, zastřešující případ použití: úklid lokální historie revizí.

Zapomeňte na slovo „lokální“: měl by se používat pouze k úklidu vlastní, lokální historie revizí, například před začleněním jedné z vašich větví funkcí do týmové větve. Naopak by se NEMĚLA používat na historii revizí, která již byla odeslána a sdílena ve vzdáleném úložišti. Interaktivní rebase je jedním z nástrojů, které „přepisují“ historii systému Git – a to byste neměli dělat na revizích, které již byly sdíleny s ostatními.

Když máme toto malé varování za sebou, pojďme se podívat na několik praktických příkladů!

Poznámka: pro snazší vizualizaci scénářů a pracovních postupů v tomto příspěvku jsem na některých snímcích obrazovky používal grafické uživatelské rozhraní Git „Tower“.

Oprava staré zprávy o revizi

Někdy si všimnete překlepu ve staré zprávě o revizi – nebo jste v popisu zapomněli uvést něco, co stojí za zmínku. Pokud by se jednalo o úplně poslední revizi, mohli bychom jednoduše použít volbu --amend příkazu git commit. Ale u starších revizí budete muset použít interaktivní rebase, abyste je dodatečně změnili.

Tady je příklad zprávy o revizi, která se strašně nepovedla a kterou chceme opravit:

Špatná zpráva o revizi, kterou je třeba opravit

Prvním krokem v každé relaci interaktivní rebase je určit, s jakou částí historie revizí chcete manipulovat. Vezměme si opět výše uvedený příklad: abychom mohli tuto špatnou revizi změnit, musíme relaci zahájit u její nadřazené revize.

Zahájení naší interaktivní relace rebase

Nyní můžeme příkazu interaktivní rebase předat hash této počáteční revize:

$ git rebase -i 0023cddd

Nyní se otevře okno editoru obsahující seznam revizí, které jste právě vybrali k manipulaci. A nedivte se, protože jsou v opačném pořadí: v relaci interaktivního rebase bude systém Git znovu aplikovat staré revize, položku po položce – což znamená, že obrácené pořadí je z pohledu systému Git správné.

Okno editoru s vybranými revizemi

Ještě jedna důležitá věc, kterou je třeba u tohoto okna editoru zmínit: neprovádíte zde skutečné manipulace! Respektive v tomto konkrétním příkladu zde NEPOKRAČUJETE a neměníte zprávu o revizi. Místo toho pouze označíte revizi, kterou chcete změnit, klíčovým slovem action. V našem případě, protože chceme změnit zprávu revize, označíme řádek slovem „reword“. Pokud pak toto okno editoru uložíte a zavřete, otevře se nové okno obsahující starou zprávu revize. Nyní je čas konečně provést změny:

Konečně můžeme provést naše změny

Po uložení a opětovném zavření je relace interaktivní rebaze dokončena a naše stará zpráva o revizi byla opravena!

Sloučení více revizí do jedné

Dalším případem použití interaktivní rebaze je, když chcete sloučit více starých komentářů do jednoho. I když samozřejmě platí zlaté pravidlo správy verzí: ve většině situací je výhodnější vytvořit více menších revizí než několik velkých. Jako u všeho však můžeme zjistit, že jsme to přehnali a nyní chceme dvě nebo více starých revizí sloučit do jedné.

Pro konkrétní příklad řekněme, že chceme sloučit následující vybrané revize do jedné:

Sloučíme více revizí do jedné

Stejně jako v našem prvním případě začneme interaktivní relaci rebase alespoň u rodičovské revize té, se kterou chceme manipulovat.

$ git rebase -i 2b504bee

Znovu se otevře okno editoru se seznamem té části historie našich revizí, se kterou chceme manipulovat:

Označení řádků pomocí „squash“

Klíčové slovo akce, které zde použijeme, se nazývá „squash“. A je jen jedna důležitá informace, kterou o squashi potřebujete vědět, abyste ji mohli použít: řádek, který označíme klíčovým slovem „squash“, bude spojen s řádkem přímo nad ním. Proto jsem, jak vidíte na mém snímku obrazovky výše, označil řádek č. 2 slovem „squash“, aby se spojil s řádkem č. 1.

Můžeme nyní uložit a zavřít okno editoru a opět sledovat a objeví se nové okno: nyní jsme požádáni o zadání zprávy o revizi pro novou revizi, která vznikne spojením těchto dvou starých.

Zadání nové zprávy pro novou, zmačkanou revizi

Po uložení a zavření tohoto okna editoru uvidíte, že byla vytvořena nová revize, která obsahuje soubory změn obou starých revizí. Voila!

Oprava chyby

Dalším případem použití interaktivní revize je situace, kdy jste v některé z dřívějších revizí našli chybu. A nezáleží na tom, co přesně jste pokazili: mohli jste zapomenout přidat určitou změnu, měli jste smazat soubor nebo jste prostě zavedli překlep…

Přirozenou tendencí je v takové situaci jednoduše vytvořit novou revizi, která chybu opraví. Ale na druhou stranu nám to zaneřádí historii revizí: vytvořit původní revizi a pak přidat revizi „náplast“ jen proto, abychom opravili nějaké chyby… to je nepřehledný způsob práce. Vaše historie revizí se brzy stane nepřehlednou, protože bude zaneřáděna všemi těmi malými „rychloopravnými revizemi“!“

Tady se velmi hodí „fixup“, jeden z nástrojů dodávaných s interaktivní rebase. Fixup vezme tuto „rychloopravnou“ revizi, aplikuje její změny na původní revizi (čímž ji opraví) a pak se náplastí zbaví:

Jak funguje „fixup“

Po dokončení to vypadá, jako by s naší původní revizí nikdy nebyl problém! Projděme si to tedy na praktickém příkladu.

Prvním krokem je udělat vše, co je nutné k opravě problému: může to znamenat přidání nového souboru, provedení změn v existujících souborech, odstranění zastaralých souborů… musíte „jen“ vytvořit změny, které chybu opraví.

Dalším krokem je odevzdání těchto změn do úložiště – ovšem s malým přídavkem: při odevzdávání použijeme příznak --fixup a sdělíme systému Git hash naší špatné revize:

$ git add corrections.txt$ git commit --fixup 2b504bee

Když se nyní podíváte do historie revizí, uvidíte, že byla vytvořena docela obyčejně vypadající revize – pravděpodobně ne taková kouzla a ohňostroj, jak byste čekali. Pokud se však podíváte blíže, zjistíte, že se něco děje: nová revize byla automaticky doplněna o „fixup !“ a předmět naší špatné revize.

Původní revize a opravná revize

Třetím krokem je nyní spuštění interaktivní relace rebase. Jako výchozí bod opět zvolíme nadřazenou revizi naší špatné revize…

$ git rebase -i 0023cddd --autosquash

… a jako druhou část tajné omáčky použijeme příznak --autosquash. Tato volba zajišťuje, že nemusíme nic dělat v okně editoru, které je nyní otevřené. Podívejte se pozorně na situaci:

Naše opravná revize je označena jako „fixup“ a seřazena na správné místo

Uvidíte, že systém Git za nás automaticky udělal dvě věci:

1. Označil naši opravnou revizi jako „fixup.“
2. Změnil pořadí řádků tak, aby se naše opravná revize objevila přímo pod naší špatnou revizí. Je to proto, že fixup funguje přesně jako squash v tom smyslu, že se spojí s řádkem nad ním.

Jinými slovy: nezbývá nám nic jiného než uložit a zavřít okno editoru.

Podívejme se ještě jednou na historii revizí:

Šťastný konec!

Nejenže naše původně špatná revize nyní obsahuje změny z naší revize band-aid. Ale navíc ošklivá revize s náplastí zmizela z historie revizí! Vše je pěkné a čisté, jako by nikdy žádný problém nebyl!

Objevte sílu interaktivní rebaze

Případů použití interaktivní rebaze je mnoho – a většina z nich spadá do oddělení „opravování chyb“. Pro přehled dalších užitečných věcí, které můžete dělat, doporučuji bezplatnou „Sadu první pomoci pro Git“: je to sbírka krátkých videí (2-3 minuty na epizodu), která vám pomohou naučit se napravovat chyby pomocí interaktivní rebase a dalších nástrojů Gitu.

Poznámka redakce: Při recenzování právě tohoto příspěvku jsem musel použít interaktivní rebase! Jedna z mých revizí obsahovala obrázek větší než 1 MB, což je v rozporu s pravidly pro webový projekt GitLab. Musel jsem se vrátit a opravit tuto revizi tak, aby místo ní obsahovala obrázek správné velikosti. Díky za poučení, vesmíre! 😁

Další tipy a triky pro systém Git

• 15 tipů pro systém Git, které zlepší váš pracovní postup
• Jak vám částečné klonování systému Git umožní načíst pouze velký soubor, který potřebujete
• Systém Git se stává! 6 nejčastějších chyb systému Git a jak je napravit

O hostujícím autorovi

Tobias Günther je generálním ředitelem společnosti Tower, populárního desktopového klienta systému Git, který pomáhá více než 100 000 vývojářů po celém světě být s Gitem produktivnější

Obrázek na obálce: David Taljat na Pexels

.