# コミットとブランチとタグについて #git

git は超便利。ブランチがさくさく切り替えられて、細かいタスクをばんばん倒していくお供にとってもいい。気軽にコミットしても push 前ならあとから編集するのが簡単だし(あんまりやらないけど)、マージもとても賢い。でもちょっとなぜかコンフリクトする場面があったりするのは御愛嬌。SVN の頃など、普通にブランチきってコミットしてマージして、また改めてコミットして、正しい手順が重労働だった。git はいかにすばらしくショートカットさせてくれるのかと思います。

git になってから、コミット、ブランチの分岐・マージ、タグがかなりカジュアルになって意味も増したと感じているきょうこのごろ。本当にうまく使えば雄弁な歴史の証人になってくれるが、何も考えずにやってしまうと、無価値、もしくは負債のログに成り果てる。

そんなこんなで最近の自分はこんな風ですというメモを記してみます(総じて理想論の部分もあるので話半分程度に)。

(あと、git に限った話ではない)

## コミット

コミットは、名前の付く最小作業単位で分けます。

インデントを直す作業と余計な改行を取り払う作業は同じコミットでもいいけど、ロジックを直す作業とインデントを直す作業は一緒にして欲しくない(ロジックいじるのと改行も同じだけど、まあどちらも該当ブロックで同時に直さないと逆に見難いとかは除く)。とにかく別作業同士は混ぜるな危険。うっかり混ぜてしまいがちだけど、意識して混ぜない方が無難です。

コミットの粒度は、diff を読む人の能力や前提知識にも寄るし、コミットメッセージでの説明のうまさにもよる。だけど、大抵コミットメッセージは十分ではないし、取るに足らない差分ほど荒いコミットメッセージになります。だから自分はなるべく粒度が細かい方が好き。コミットメッセージも少なくてすみます。"わからない" コミットが最悪。わからないことには対処の仕様がないのです。細かすぎて気に食わないという程度の事態には、対処ができるという点がまだわずかに "わからない" より優れていると思います。むやみやたらな対処が何を産むか、エンジニアをやっていれば誰もが知っていますよね。

ただ、たまに自分が試行錯誤した差分(saveがわりのコミット？)を積み上げたままのひとがいるけど、それは "細かい" とかの切り口ではないですね。

### コミットメッセージ

コミットメッセージには、なぜこの差分が必要か、どのようなアプローチでこの差分なのか、を書きます。

1次情報へのリンクとかもどんどん書いておこう。特に、レビュー内容を反映するときのコミットは、いかにも革命的な diff になりがちだけど「レビューで言われたこの点を直した」という風に、そういう理由も含めて書けばいいと思う。原理主義はよくない。いつもいつも目的に向かって、最善のコミットだけが積みあがるわけなんてない。ぼくはそういうログを、共感をもって読みますし、自分のログをみて反省をします。

ただし、うそは書かないほうがいいです。コミットの差分と、コミットメッセージが食い違ってるのはだいぶ性質が悪いです。とはいえ、たまに自分もやってしまいますが、、


## ブランチ

ブランチはコミットが積みあがり、なにかのタスクを消化している粒度が好みです。

issue の解決、または新機能の追加など、なんらかの目的を達成している粒度が好みで、master にガツンとマージされているのが理想です。サクッと切り戻しがきくから。最近は、github の issue を活用するようになって、`feature/123_great_menu` のようなブランチ名にするようにしています(ブランチ名にスラッシュ使えるの最近知った)。`fix/124_very_sad_bug` とか、issue 番号をブランチ名にいれています(コミットメッセージにも `#123` もちろん書きますが)。

Yak Yak でブランチが派生していくのは、うっ！ってなりますけど、自分は健全だなあと思うようにしてます。依存関係を産まないようにタスクを切り分けるというのは作業効率をあげるのに重要だと思いますし。

## タグ

タグはリリースのスナップショットごとに打ちます。

面倒くさいのでデプロイツールに組み込むのが良いと思っています。複数のリリースマネージャがいたりする場合だと、`-a` とか使うんでしょうか。たぶん。

## まとめ

 * コミット: 名前のつく最小作業単位
 * ブランチ: issue/feature など目的に応じた粒度で。
 * タグ: リリース単位

だいたい自分が考えてるのはこんな感じです。

とはいっても、ここに書いたのはすでにリリースされたプロダクトの場合で、リリース以前の開発段階は実はもうちょっとゆるくてもいいと思っています。特にスピードが要求される場合、コミットログや粒度に時間割けない場面もあると思います(障害対応のときとか！)。そういうフェーズでは、チームメンバー同士の開発内容の共有されてる度がそもそも高いと思うし、一発世に出すタグを打つまでは、チームでやるならチーム間で共有できる最低限のログを基準にするのでいいんじゃないかなあと思っています。

バランスはいろいろですね。おわり。