git-flowのフル利用は受託案件にはオーバースペック
個人的な感想として、開発で多いのは"成果物や期間の定まった小規模受託案件 > 継続的に運用を必要とする大規模案件"だと思ってます。あくまで個人的な感想です。
git-flowはプロダクトを継続的に開発・運用することを前提にした運用です。なので、「リリース後～次のリリースまでに問題が起きたらhotfixする」のようなワークフローが作られています。
逆に受託開発（特にアプリ開発）は「n月末までに納品物を作る。あとは知らん（契約によるからね！念のため！！）」という流れです。git-flowのワークフローは大仰すぎて、あんまり受託開発向けじゃありません。
じゃあ、なんでgit-flowを使うのか
有名だからというのが一番の理由です。完全な社内ルールとかオレオレルールを適用してしまうと、協力会社だけじゃなく、中途採用の人にも学習コストがのしかかります。
git-flowは結局のところ「束縛の強い命名規則」なので、命名規則さえ守ってくれれば文句を言いません。「とりあえずgit-flowな感じの運用だから」といっておけば、次の最低限のルールはすぐに飲み込めるでしょう。
- masterにはビルド可能なものが入っている
- developが開発用の最新内容が入ってる
- featureにはなんか新機能が入ってる
git-flowを知らなくても、適当な解説ページの冒頭くらいを見せておけばとりあえず問題無いです。
このブランチルールの利点
- git-flowの"master", "develop", "feature", (場合によっては"release")しか使わず、最低限の知識のみで開始できる
- git-flowと互換性を保ってるので、自分一人からでも始められ、いつでもやめることができます。
リリースルール
受託の場合、「中間の成果物」が求められる場合があります。ゲームで言えばアルファ（ベータ）版とか言われるやつです。この中間提出をgit-flowでいうところの"release"とみなすことができます。
大体の場合はdevelopで開発を続けても問題ありません。中間提出に対して、ほぼすべての開発者が関わることになるからです。
無事に提出完了したらdevelopの内容をmasterにマージし、場合によってはtagを打って完了です。
git-flowに慣れている開発者であれば、ちゃんとgit-flowのrelease機能を使ったほうが良いですが、わざわざそこまでやる必要のないことがほとんどです。
中間提出が無いプロジェクトの場合、masterがほぼカラの状態であることを許容します。
featureのブランチ命名ルール
- feature/id/{チケット番号}/master が基本的な作業ブランチ
- feature/id/{チケット番号}/{トピック名} も使用する
- 他人のチケットの手伝いや、チケットに対するさらなるブランチを切る場合に使用する
- チケット番号のないfeatureブランチは基本的に作成しない
- コミットメッセージには "refs #チケット番号"、完了時には"closes #チケット番号"を入れる
- Redmineやgithubでチケットに対して自動的に参照を追加できます。これはあとから修正内容を見返すときに重要になるので、ルール化したほうが良いです。
featureにチケット番号を追加しているのは、どのチケットを処理しているか明示すると同時に、スクリプトで容易にコメントの自動生成を行うためです。
/masterを末尾に追加することで、チケットに対するブランチを容易に作成できます（gitの仕様上、あとから/masterとか/topickのようなブランチ階層は追加できない）。
「作業途中でちょっとリファクタしよう」とか、「他の人にチケットの一部を任せよう」とかを容易に実現できます。
特に開発末期のバグ修正では、トライ＆エラーのために割りと細かく修正とリセットを行ったりするので、有用です。
拡張スクリプトの配布 git-flow-hook
上記のルールを簡単に実現するために、個人的に拡張スクリプトを作って運用していました（改造元はbleis-tift氏のフックスクリプトです）。
動作確認はCygwinとUbuntuで行っているので、Macでも多分動きます。
従来は適当にリポジトリにコピペしていましたが、インストールスクリプトを作ったほうが新規案件とかでも使いやすい（プラス、個人的には便利だと思ってる）ので公開します。
インストールすることで、上記に沿ったルールのブランチが作られます。内部的にはgit-flowを使用しているので、互換性は保たれます。
拡張スクリプトは使わなくても、上記ルールにしたがって適度にゆるくやっていればきっと問題は無いです。ただ、チケット番号の付与は忘れがちなのでスクリプトで自動化したほうがおそらく自分のためです。
- git mktopic {チケット番号}
- feature/id/チケット番号/master を作成します
- 以後、コミットすると自動的に"refs #チケット番号"がコメントの末尾に付与されます
- git endtopic
- feature/id/チケット番号/master の開発を完了してdevelopにマージします
- 実行すると、自動的に"closes #チケット番号"がコメントの末尾に付与されます
- git mksubtopic {トピック名}
- feature/id/チケット番号/{トピック名} を作成します
- git endsubtopic
- feature/id/チケット番号/{トピック名}の開発を完了して feature/id/チケット番号/master にマージします
- masterブランチ制限の強化
- masterへの直接的なコミットが禁止されます
- developからmergeする、もしくはpull requestの経由を強制できます
最後に
基本的にモノグサなので、真面目にgit-flowを適用して受託やったら疲れました。
楽に楽しく生きましょう。