gitworkflows(7)を図解したスライドをアップしました

前回に引き続き、こちらも会社の読書会でGit関連本の番外編として実施したgitworkflows(7)の解説資料（の加筆修正版）です。

マニュアルからすると講義用にかなりつまみ食い的な内容になってます。
副読本的な位置づけでマニュアルを読むのも良いかなと思います。

Gitの布教などにお使いください。

図解gitworkflows(7) from ktateish

講義した感触だと、やはり少しややこしいワークフローだと感じるようです。
確かにGitの動きにある程度慣れてないと理解しづらいですし、スライドでは最終的な機能リリース直後だけ見るとシンプルなコミットグラフなんですが、途中のnextが混じった図は結構カオスです。
ただ、「ステージング環境は便利そう」という感想もありました。

Q and Aに出てきていますが、プロジェクトの状態や開発スピードによっては master と pu (使い捨て統合ブランチ)だけ、とか、 master, master-pu, maint, maint-pu のような、開発版と安定版のような使い方もあります。

少なくとも、「絶対にpush -fできないブランチ」に対してpuがひとつあるといろいろ便利です。
みなさんも、masterをpushした直後(1日以内)にその中にバグやtypo, 凡ミスを見つけてしまうことって、経験あると思うのですが、
そのような場合は光の早さでこっそりpush -fしたり、歯ぎしりしながらrevertしたりしてないでしょうか？

そんなときは「完成したトピックは1日だけまずpuにマージして置いておき、翌日masterにマージする」というフローにするだけで、そのような嫌な事態から解放されます。

規模が大きいプロジェクトだとpushされたトピックをマージしてコンフリクト有無やスタイルチェック、ユニットテストまで行うような自動化された使い捨て統合ブランチを用意するのも良いでしょう。
テストを頑張っていれば、evil mergeが必要な場合などもある程度統合前に検出できます(もちろん万能ではありませんが)。


ちなみに、あまり詳しく調べてないのですが、 Linux の開発では linux-next という pu 相当の使い捨て統合ブランチを定期的に作成することで、次期リリース用のブランチ間のコンフリクトなどを事前に検出して統合マネージャの仕事を楽にしようという取り組みが行われているそうです。
ここではサブシステムの重要度からマージ順序を決めるなど、いろいろと興味深いプラクティスが開発されているようで、そのうち調べてみたいと想っています。
ただ、Linuxほどの規模になるとやはりAPI変更は非常に厄介らしく、現在も良い方法を模索中のようです。(結局は開発者間の連携が重要みたいです)