Git je super nástroj, ale každý kdo na něj přechází z centralizovaného systému je naprosto ztracen v otázkách "správného" vývoje - workflow. Jak a kdy používat větve, používat merge nebo rebase, kdo, kdy a odkud dělá release atd. Tento článek se zabývá otázkou vývoje projektu, který je veřejný, ale nechcete nutně ukazovat veškeré mezikroky.

...

Při vývoji projektu Bivouac (PDF generátoru Basecamp kalendáře) jsem měl mraky commitů do svého privátního Git repositáře a přišlo mi hloupé všechny tyto commity nahrávat na GitHub, protože byly rozpracované a nefunkční. Hledal jsem způsob jak je sloučit do jednoho, který pushnu na GitHub a nejlépe jak zařídit abych to mohl dělat opakovaně.

Kupodivu na internetu není mnoho informací o tomto stylu vývoje, kromě článku od Braintree .

Pokud jste si vesele commitovali a nyní chcete zveřejnit vaší práci na GitHubu v jednom prvotním komitu, tak nejprve vycheckoutujte první commit a vytvořte z něj novou větev:

git checkout -b github_release sha_hash_of_first_commit

Pak stačí zmergovat s vaší větví (master). Pomocí parametru squash získáme jeden jedinný commit:

git merge --squash master

Nyní jsou změny připraveny ke commitu, takže si můžete zvolit novou souhrnnou zprávu:

git commit -m"release notes"

Pak větev můžete vklidu pushnout na GitHub pokud si GitHub repositář přilinkujete jako "github":

git push github HEAD:master

To ale není vše, protože musíme aktualizovat vaší větev, ze které jste mergovali. Musí se tento nový splácnutý commit dostat zpět do vaší větve (master):

git checkout master
git merge github_release

Tohoto mergování se nemusíme bát, protože Git je chytrý a ví, že se defakto nic nezměnilo, takže provede rekurzivní spojení větví.

Osvědčilo se mi udělat si shellový skript, kterému zadám název větve a text pro release a veškeré příkazy vykoná automaticky.