gitworkflowsの補足(1) - gitworkiflowsを採用する目的

gitworkflows(7)についての補足記事です。

gitworkflowsを採用する目的、あるいはgitworkflowsを採用する利点は何よ？というところですが、これは一言でいえば「masterに綺麗な歴史を残す(残せる)」というものです。


これはgitworkflowsを採用しているリポジトリで

% git log --first-parent v3.13..master

とかやってみると実感できます。タグは前回リリースのもので、ここでは例としてv3.13を使っています。
--first-parentはgitのコミットオブジェクトに記録されている親コミットのうち、最初のコミットをたどるオプションです。(適切な歴史を持ったmasterで実行すればmasterのみをたどります)

これによってリストされる歴史は、些細な1コミットの変更か、masterにマージされたトピックのマージコミットだけになります。結果として上記のgit logコマンドでは、トピックの細かいコミットまで目を通すことなく、前回リリースからのmasterの変更の概観を得ることができます。

このようなすっきりとした歴史を持つことは、あとから当時の変更を調査しようという人にとって、大きな利点になることは想像に難くないと思います。

例えばmergeをrevertしたりすると、場合によっては再マージ前にrevertをrevertしないといけなかったりして、結構歴史が汚れてしまいます。そういった作業はnextでトピックを洗練させることでmasterに持ち込まないようにできます。

逆に、gitworkflowsを用いないでも綺麗なmasterをキープできる環境であれば、gitworkflowsは少しオーバースペックです。
これは、

• 開発者が不特定多数でない（少数固定）
• 開発者間のコミュニケーションチャネルが極太

というような環境、例えば同じ会社の1担当などであれば、Ω「ちょっとあのトピックいけてなかったからmasterをrebaseするわ」ΩΩΩ『うぃーす』ですむからです。

まぁgitworkflowsを採用したからといっても、masterにマージされたトピックがいけてなかったなんてことは、起きるときは起きてしまうわけで、どう運用するかは環境やコストパフォーマンスなど、状況次第という感じですね。

Gitは分散VCSとして有名ですが、Gitを使う最大の利点のひとつに「コミットを好きなように組み立てて完璧に近い一連の歴史を作れる」という点があります。
つまりGitはコミットレベルで綺麗な歴史を作れるということですが、これをブランチレベルに拡張したのがgitworkflowsだと思っています。