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
[editovat | editovat zdroj]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
[editovat | editovat zdroj]Č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
[editovat | editovat zdroj]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
[editovat | editovat zdroj]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
[editovat | editovat zdroj]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
[editovat | editovat zdroj]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 ► |