Archiv pro rubriku: GIT

Jak rozdělit GIT repozitář na více menších a zachovat/promazat historii

Semtam se stane, že se aplikace rozroste, moduly přibývají a jejich doménový model se začně čím dál více lišit. Nastal čas aplikaci rozdělit. Prvním krokem, ještě před úpravami kódu by mělo být rozdělení GIT repozitáře. Můžeme na to jít více způsoby:

1. Zkopírovat repozitář a vymazat z něj nepotřebné soubory

Je to rychlé a vcelku bezpečné. V repozitáři nám ale zůstane kompletní historie souborů ostatních aplikací a klonování každého repozitáře bude kvůli tomu trvat zbytečně dlouho.

2. Založit nový, čistý repozitář a commitnout do něj jen potřebné soubory

Je to opět rychlé a vcelku bezpečné. V repozitáři nám ale nezůstane ani historie souboru oddělované aplikace. Budeme sice mít zálohu v podobě originálního repozitáře před rozdělením, nebude se s tím ale moc pohodlně pracovat.

3. Použít git filter-branch a upravit historii zkopírovaného repozitáře

Moje oblíbená varianta. Je sice náročnější na čas a snadno se při ní udělá nějaká chyba. Odměnou je ale čistý repozitář, který obsahuje jen soubory oddělované části aplikace včetně jejich historie. Nyní si ukážeme jak na to.

Naklonujeme si originální repozitář

Přepneme se do složky repozitáře a projistotu odstraníme jeho remote.

Získáme seznam všech souborů v historii včetně smazaných

Tento krok není nutný, pokud nejste puntičkáři jako já 🙂 Můžeme snadno odstranit jen soubory, které aktuálně v repozitáře nechceme. Nebo si můžeme dát trochu více práce a odstranit i soubory, které jsme už dávno smazali nebo přejmenovali. K tomu ale potřebujeme zjistit, které to byly. Pro začátek si tedy vypíšeme všechny soubory, které kdy byly do repozitáře přidány. Výstup nasměrujeme do nějakého souboru, aby se nám s ním lépe pracovalo.

Nyní přišel čas otevřít si výstupní soubor v editoru a nechat v něm jen souboru, které chceme smazat. Musíme dát pozor, abychom si nesmazali soubory, které už sice v repozitáři nejsou, ale jejich přejmenované verze chceme. V případě odstraňování celých složek můžeme ponechat jen složku místo kompletního výpisu jejich souborů.

Jakmile budeme hotovi, použijeme připravený soubor v příkazu git filter-branch k promazání historie.

Nyní je načase aplikaci otestovat (v nejlepším případě spustit testy), zda jsme neodmazali něco důležitého. Nejspíše bude nutné kvůli odmazaným souborům trochu kódu upravit. Poté si můžeme přidat nový remote a udělat první push.

V této fázi jsou ještě stále staré revize zálohovány pod refs/original. Pokud je chcete z repozitáře úplně odstranit, musíme to udělat ručně.

Eventuelně můžeme místo toho udělat čerstvý clone našeho již vyfiltrovaného remotu.

Jak bezpečně distribuovat hesla v gitu

Pokud už jste někdy rozcházeli deployment aplikace pomocí gitu, asi jste narazili na problém, jak na produkční server bezpečně dostat hesla. Mít je v plaintextu v GITu moc bezpečné není 🙂 Přesto ale je způsob, jak je v gitu mít bezpečně – zašifrovat je. Jak to udělat a jak je při deploymentu do produkce rozšifrovat?

Pokud nemáte, nainstalujte si na produkčním server GPG. Na Unbuntu/Debian se to dělá takto:

Pro generování klíčů budeme potřebovat hodně entropy, doporučuji tedy nainstalovat i Haveged, viz. můj minulý článek.

Nyní se potřebujeme přepnout pod uživatele, pod kterým probíhá deployment. V mém případě je to uživatel web. Pod tímto uživatelem vygenerujeme základní keypair. Důležité: nezadávejte při generování klíčů žádné heslo, jen volbu potvrďte entrem.

Teď když máme vygenerovaný keypair, vyexportujeme veřejný klíč, nejlépe do souboru:

To by bylo pro produkční server zatím vše. Nyní si na našem vývojovém stroji vygenerujeme keypair stejně jako na produkčním serveru. Tentokrát ale doporučuji zadat heslo, na které se se vás GPG při šifrování a dalších operacích bude ptát. Poté importujeme veřejný klíč produkčního serveru.

Importovaný klíč podepíšeme, tím řekneme GPG, že důvěřujeme jeho původu:

Teď přijde ta hlavní část. Zašifrujeme veřejným klíčem produkčního serveru konfigurační soubor s hesly:

Zašifrovaný soubor .gpg pak můžeme bez problémů commitnout do gitu. Bez privátního klíče produkčního serveru jeho obsah nikdo nepřečte. Na produkčním serveru pak v deployment procesu nastavíme rozšifrování tohoto souboru pomocí privátního klíče, který už na serveru máme.

Sloučení commitů do jednoho pomocí git rebase

Slučování commitů v GITu se nazývá squashing.

Sloučení commitů se pak provede příkazem rebase kde 4 je počet commitů včetně posledního:

Slovo pick se pak krom jednoho commitu zamění za squash:

Takto rebasenutý repozitář je pak u pushnutých commitů potřeba do remotu odeslat pomocí: