Administrace komentářů

Přechod ze svn na git znamená víceméně zapomenout na svn a naučit se to znovu. Na jednu stranu to je podobné, na druhou to funguje dosti odlišně.

K tomu vývoji:

Udělej každému vývojáři repositář gitu, který bude jediný, kam smí zapisovat. Pak vyber jednoho rozumného vývojáře, který bude udržovat hlavní větev, začleňovat do ní změny od ostatních a bude jediný, kdo smí vyrábět tagy (tj. vydávat stabilní verze; viz git describe). Větev master tohohle člověka je výsledný produkt a všichni ostatní se synchronizují s ní.

Vlastní vývoj pak probíhá na lokálních instalacích, kde se to jakš takš odladí, aby to vůbec fungovalo. Commity si každý dělá podle toho, jak přidává funkce či dělá změny – přiměřeně malé commity, které nemusí být sami o sobě funkční, ale do hlavní větve se začlení až když to funguje. Tedy každá změna vzniká ve své větvi a jakmile je s ní vývojář spokojen, řekne si o její začlenění. U malých změn použije rebase, ty dlouhodobé se třeba i několikrát mergují klasickým způsobem. Vypadá to jako zbytečná administrativa navíc, ale je to celkem efektivní způsob, jak udržet pořádek a také si správce hlavní větve může lehce vynutit kvalitu začleňovaných věcí.

Pro testování by se mohlo zdát, že je dobrý nápad automaticky synchronizovat obsah repositáře s webem, ale není tomu tak. Je teba rozlišovat dva scénáře:

1. Probíhá vývoj, web se aktualizuje častěji než se commituje. Jakákoliv provázanost s repositářem obtěžuje. Ideální je mít skript, který lokální instalace přenese na testovací instalaci na serveru. Osvědčená metoda: jeden rsync pro náhled, druhý pro vlastní přenos, to celé zabalené v hezkém skriptu.
2. Testování, diskutování, předvádění klientům. Vývoj víceméně neprobíhá, spíš se jen aktualizuje instalovaná verze. Tady je dobré mít aktualizaci webu automatickou po nahrání změn do repositáře. Existuje jedno pěkné řešení využívající dvojici repositářů, kdy web má svůj non-bare repositář a po nahrání změn na server si sám dělá fetch+checkout (post-update hook vypadá přibližně takto: cd document_root; git fetch origin; git checkout origin/master). Těchto instalací není třeba mít moc, jednu určitě pro hlavní větev, druhou pro stabilní (tj. poslední tag) a případné další pro některé dlohodobě existující větve. Vývojáři tohle víceméně nepotřebují, ti používají předchozí scénář.

Rozhodně je dobré, aby vývojáři pochopili rebase a commit --amend. Díky tomu lze lehce vytvářet hezkou historii, která je pak užitečná.