俺々コミットメッセージ規約を作るエントリ Part 1

コミットメッセージなんて、一般的にはgit自体のガイドラインや Gitのコミットメッセージに関する注意点を守ってればなんの問題もないと思います。先頭行は先頭大文字の現在形ではじめて、一行開けて詳細云々。

ただ最近gitに慣れてきて、rebase -iしまくるために過去のコミットをgit log --onelone | grepで一発特定できると嬉しい、という特殊事情が私の中だけで発生してまして、そのためにある程度コミットメッセージを統一しておきたくなりました。探しても深く主張しているものはあまり見当たりませんでしたので、俺ルールをどう作るかってエントリです。

全体の体裁

基本的に一行で全て済ませます。一行目に書かないと--onelineに出てこないのでgrepできません。72文字ルールは無視します。
3行目以降の詳細は余程のことがない限り書きません。主流とは逆になると思いますが、diff見たら一発でわかるものを書きなおすのは無駄です。基本的に私よりgitやコンパイラやdiff/grepのほうが賢いので、彼らの邪魔をしないほうがいいです。
ただ、本当に特記しておきたいことは書きます。普段書かないところを書いている、これは何かあったに違いない、ということで、重要なことが目立つ理論。

Initial commit(確定)

Initial commit

Initial commitのコミットメッセージはInitial commitです。
他から移行してきた場合はInitial commit, import from ...みたいにします。
なんといってもInitial commitはrebaseできません。grepして出てきたIDをろくに確認もせずにrebaseに渡して、なんてやってしまうと事故の元です。Initial commitはすぐに認識できる必要があります。

マージ(確定)

Merge branch 'マージ元' (commit 'ID7桁') into マージ先

並行ブランチ間で何度もマージしたりするので、デフォルトのメッセージだけでは特定ができなくなります。マージ元のコミットIDを付け加えます。
なおgit rebaseはマージコミットの再現に関しては非常に弱くて、自動マージは成功したけどビルドできなくなったからこのファイルも一緒に直さないと……なんてやっててもrebaseすると消失します。--preserve-mergesを付けても自動マージ分しか再現してくれません。
そのため、デフォルトで生成される本文のConflicts:の下に、Reverts:なりModifications:なりRemoves:なり勝手に書き加えて、一緒に変更したファイルをメモっておきます。

submoduleの更新(ほぼ確定)

Update サブモジュールのパス

Updateというのは便利な単語で、何にでも使えるのですが、submodule専用にしたいと今決めました。何しろsubmoduleとしてインポートしている外部ライブラリのリポジトリがpush -fされたり、最悪URL移転なんてされてしまうと、何もしなくても過去のコミットが壊れることになります。(この現象は、外部リポジトリも私作だったりすると特に頻繁に発生します) つまりsubmodule関連のコミットは潜在的にrebase -iしたくなるコミットなのです。なので、一般的なUpdateという単語をsubmodule専用にしてしまいます。grepabilityの向上のためです。

バグ修正(ほぼ確定)

Fix ...
Dirty fix ...

この辺はまあいいでしょう。

で、後が問題です。私に限らずその辺のリポジトリを覗かせていただいても、皆さん適当にAdd ...なんて書いているわけですが、機能の追加なのかモジュールの追加なのかファイルの追加なのかソースコードレベルでの定義の追加なのかごちゃ混ぜで、grepabilityは低いと言わざるを得ません。
ここはひとつ、大きめのリポジトリを覗かせてもらって、wcでもかけてみましょうか……。

(続く)

というわけで本家gitのリポジトリのコミットメッセージの単語を数えてきました

#!/usr/bin/perl
# 適当に検索して取ってきたソース、誰かに感謝
while ( <> ) {
    @words = split(" ");
    $wc{@words[1]} += 1; # [0]=commit id [1]=first verb
}
foreach $key (keys %wc) {
    print "$wc{$key} $key\n";
}

git --oneline | perl ↑ | sort -n -r | head -n 100 

……ごめんなさい実際にはエディタの機能を使いました。

俺々コミットメッセージ規約を作るエントリ Part 2

↑見てやる気を無くしたので終了します。

grepして一括で過去を書き換えたい需要を考えてみますと、submodule、makefile(いつの間にか別マシンでビルドできなくなってたetc)、readme(晒すのでメールアドレス消したいetc)……要するにメタ情報が多い気がします。
ソースコード本体を修正したいときは、具体的にどのコミットを直すべきなのか特定できているはずですし。
なのでこの辺を、Update submodule、Improve makefile、Edit readmeみたいに固定してしまえば、需要は結構満たせる予感がします。Addの使い方なんてどうでも良かったですね。