More than 5 years have passed since last update.

小規模開発のgit-flowの導入を楽にするブランチルールと拡張スクリプト配布

Last updated at 2016-02-10Posted at 2016-02-10

git-flowのフル利用は受託案件にはオーバースペック

個人的な感想として、開発で多いのは"成果物や期間の定まった小規模受託案件 > 継続的に運用を必要とする大規模案件"だと思ってます。あくまで個人的な感想です。

git-flowはプロダクトを継続的に開発・運用することを前提にした運用です。なので、「リリース後～次のリリースまでに問題が起きたらhotfixする」のようなワークフローが作られています。

逆に受託開発（特にアプリ開発）は「n月末までに納品物を作る。あとは知らん（契約によるからね！念のため！！）」という流れです。git-flowのワークフローは大仰すぎて、あんまり受託開発向けじゃありません。

有名だからというのが一番の理由です。完全な社内ルールとかオレオレルールを適用してしまうと、協力会社だけじゃなく、中途採用の人にも学習コストがのしかかります。

git-flowは結局のところ「束縛の強い命名規則」なので、命名規則さえ守ってくれれば文句を言いません。「とりあえずgit-flowな感じの運用だから」といっておけば、次の最低限のルールはすぐに飲み込めるでしょう。

git-flowを知らなくても、適当な解説ページの冒頭くらいを見せておけばとりあえず問題無いです。

受託の場合、「中間の成果物」が求められる場合があります。ゲームで言えばアルファ（ベータ）版とか言われるやつです。この中間提出をgit-flowでいうところの"release"とみなすことができます。

大体の場合はdevelopで開発を続けても問題ありません。中間提出に対して、ほぼすべての開発者が関わることになるからです。

無事に提出完了したらdevelopの内容をmasterにマージし、場合によってはtagを打って完了です。

git-flowに慣れている開発者であれば、ちゃんとgit-flowのrelease機能を使ったほうが良いですが、わざわざそこまでやる必要のないことがほとんどです。

中間提出が無いプロジェクトの場合、masterがほぼカラの状態であることを許容します。

featureにチケット番号を追加しているのは、どのチケットを処理しているか明示すると同時に、スクリプトで容易にコメントの自動生成を行うためです。

/masterを末尾に追加することで、チケットに対するブランチを容易に作成できます（gitの仕様上、あとから/masterとか/topickのようなブランチ階層は追加できない）。

「作業途中でちょっとリファクタしよう」とか、「他の人にチケットの一部を任せよう」とかを容易に実現できます。

特に開発末期のバグ修正では、トライ＆エラーのために割りと細かく修正とリセットを行ったりするので、有用です。

上記のルールを簡単に実現するために、個人的に拡張スクリプトを作って運用していました（改造元はbleis-tift氏のフックスクリプトです）。

動作確認はCygwinとUbuntuで行っているので、Macでも多分動きます。

従来は適当にリポジトリにコピペしていましたが、インストールスクリプトを作ったほうが新規案件とかでも使いやすい（プラス、個人的には便利だと思ってる）ので公開します。

インストールすることで、上記に沿ったルールのブランチが作られます。内部的にはgit-flowを使用しているので、互換性は保たれます。

拡張スクリプトは使わなくても、上記ルールにしたがって適度にゆるくやっていればきっと問題は無いです。ただ、チケット番号の付与は忘れがちなのでスクリプトで自動化したほうがおそらく自分のためです。

基本的にモノグサなので、真面目にgit-flowを適用して受託やったら疲れました。
楽に楽しく生きましょう。