Git pro mě/Psaní zdrojového kódu nové funkce

Jenom výjimečně se mi povede vytvořit novou sadu změn, kterou není potřeba upravovat. Sady změn měním proto, že chci, aby byly dokonalé. To ale znamená, že historii sady změn budu přepisovat. Hodněkrát.

Jako vývojář jsem zodpovědný za sadu změn. To je trochu něco jiného, než být zodpovědný za zdrojový kód. Nepřehledná sada změn může obsahovat dobrý zdrojový kód a naopak, hezká sada změn může obsahovat chyby. Důvod, proč je důležitější mít dokonalou sadu změn, než dokonalý zdrojový kód, je spolupráce. Nad dokonalou sadou změn se lépe diskutuje.

Když už vím jak na Psaní zdrojového kódu skriptu, tak hurá na přepisování.

Větev NOVA-FUNKCE

Chci přidat změny implementující novou funkci. (Předpokládám, že nová funkce vychází ze zdrojového kódu, který je ve větvi master.) Postup už znám:

git branch NOVA-FUNKCE
git checkout NOVA-FUNKCE

A potom přidávat změny:

git add -p JMENO-SOUBORU
git commit -m'52 znaků dokončujících větu'

Když už mám nějakou tu historii a chci ji změnit, je čas na rebase:

git rebase -i master

Objeví se textový editor se seznamem změn na jednotlivých řádcích ve formátu

pick IDENTIFIKATOR-ZMENY 52 znaků dokončujících větu

Dole v souboru jsou komentáře, co se může napsat místo "pick". Jednotlivé změny lze také přehazovat či mazat. Soubor se upraví, uloží a zavře, čímž se změny aplikují.

Rebase funguje tak, že vezme všechny změny, které jsou ve větvi NOVA-FUNKCE a zároveň nejsou ve větvi master, a tyhle všechny změny aplikuje na master.

Rebase můžu provést i na jinou větev, než master. Funguje to stejně, ale může to být záludnější. Při rebase se může změnit IDENTIFIKATOR-ZMENY, takže historie změn bude pak obsahovat různé změny (podle jejich identifikátoru) se stejným textem krátké zprávy.

Přidání dočasné změny

Často přidávám kód, který ve výsledku nechci. Typický příklad jsou ladící výpisy. Přidání dočasného kódu se dá vyhnout přes

git add -p

ale čím více dočasného kódu, tím je tento způsob nepřehlednější a tím pádem náchylnější k chybám.

Protože ale při rebase můžu změny smazat, čímž se nakonec neaplikují, dočasný kód přidávám do historie jako změny s textem krátké zprávy začínajícím "TMP". Při rebase pak všechny TMP změny smažu a je to.

Oprava změny

Když pracuji na dokonalé sadě změn, často se vracím k jednotlivým změnám a upravuji je. Můžu to provést tak, že:

git rebase -i master

potom u dané změny místo "pick" dám "e" jako edit:

e IDENTIFIKATOR-ZMENY 52 znaků dokončujících větu

uložím a zavřu. Tím se aplikace sady změn zastaví na změně, u které jsem místo "pick" dal "e". Potom upravím kód a opravím změnu:

git add -p
git commit --amend

a nakonec pokračuji v rebase:

git rebase --continue

Oprava více změn při psaní kódu

Při rebase můžu změnit "pick" na "e" u více změn. Když ale píšu kód, je neustálé provádění rebase nepohodlné. Řeším to přidáním opravné změny.

Text krátké zprávy opravné změny začíná "F", za kterým následuje identifikátor změny, kterou chci opravit. Takže po úpravě kódu přidám opravnou změnu:

git add -p
git commit -m'F IDENTIFIKATOR-ZMENY-K-OPRAVE'

Identifikátor změny k opravě najdu příkazem git logg, typicky v jiné příkazové řádce (ale ve stejném repozitáři). Jen pro připomenutí, git logg je zkratka pro:

git log --oneline --graph --decorate --all

Když přijde čas na rebase, najdu řádky, které odpovídají

pick IDENTIFIKATOR-ZMENY F IDENTIFIKATOR-ZMENY-K-OPRAVE

všechny takové přesunu pod řádek

pick IDENTIFIKATOR-ZMENY-K-OPRAVE 52 znaků dokončujících větu

a nakonec u opravných změn změním "pick" na "f", takže to bude vypadat:

pick IDENTIFIKATOR-ZMENY-K-OPRAVE 52 znaků dokončujících větu
f IDENTIFIKATOR-PRVNI-ZMENY F IDENTIFIKATOR-ZMENY-K-OPRAVE
f IDENTIFIKATOR-DRUHE-ZMENY F IDENTIFIKATOR-ZMENY-K-OPRAVE

Soubor uložím a zavřu. Tím se aplikuje sada změn, kde každá "f" změna bude součástí změny předchozí.

Rozdělení změny

Občas je změna v historii komplikovaná a já ji chci rozdělit na několik menších. Začnu rebase:

git rebase -i master

a změním "pick" na "e" u změny, kterou chci rozdělit. Další krok je zrušit změnu, ale nechat kód, který obsahuje, připravený k znovupřidání do historie změn:

git reset HEAD^

Pak zbývá jen přidat změny, které chci udělat z té jedné velké, takže několikrát:

git add -p
git commit -m'52 znaků dokončujících větu'

A nakonec:

git rebase --continue

Během procesu rozdělení změny to občas svádí k úpravě zdrojového kódu. Nemyslím si, že je to dobrý nápad -- vždy, když jsem to zkoušel, jsem musel začít znovu. Lepší je provést rebase vícekrát.

Když to dám dohromady

Přepisování historie změn:

git rebase -i JMENO-VETVE

Dočasné změny:

git commit -m'TMP'

Úprava změny ("pick" na "e"):

git add -p
git commit --amend
git rebase --continue

Git logg:

git log --oneline --graph --decorate --all

Opravné změny:

git add -p
git commit -m'F IDENTIFIKATOR-ZMENY-K-OPRAVE'

pick IDENTIFIKATOR-ZMENY-K-OPRAVE 52 znaků dokončujících větu
f IDENTIFIKATOR-PRVNI-ZMENY F IDENTIFIKATOR-ZMENY-K-OPRAVE
f IDENTIFIKATOR-DRUHE-ZMENY F IDENTIFIKATOR-ZMENY-K-OPRAVE

Rozdělení změny:

git reset HEAD^

• Prakticky: Git pro mě/Rebase je základ
• Prakticky: Git pro mě/Repozitář mluvících ptáků

◄ Git pro mě/Psaní zdrojového kódu skriptu

Psaní zdrojového kódu nové funkce

Git pro mě/Psaní zdrojového kódu v týmu ►