問題
開発が1ヶ月以上続いていくと、「あれ？このときのログはなんだっけ？」となることはないでしょうか？
「あのときの実装どうなってる？」と聞かれたり調査しようとしても、なかなか辿れなかった経験はないでしょうか？
そんなときのために、日頃から、チケット管理ツールと見比べやすいようなコミットログを作っていくことが大事だと思います。以下にやり方を書きます。
やり方
下準備
(絵文字付き)コミットテンプレートを作る
以下２ファイルの設定を行うと git commit によって、↓のテンプレートを見ながらコミットログを打ち込むことができるようになります。この設定をプロジェクトメンバ全員で揃えましょう。
[commit]
template = .commit_template
# ==== 以下、変更不要です。 ====
１行目にコミットメッセージを書いて、そのまま保存してください。
ここから下を消す必要はありません。
# === format ===
# :emoji: issue-id issue-title
# ==== example ====
# :+1: SR-400 認証機能の実装
# :bug: BG-128 Thanksメッセージは２通ではなく１通
# ==== Emojis ====
# 👍 機能追加 :+1:
# 🐛 バグ修正 :bug:
# 💚 リファクタリング :green_heart:
# ✅ テストの追加 :white_check_mark:
# 📝 ドキュメント追加 :memo:
# 🚀 パフォーマンス改善 :rocket:
# 🆙 バージョンアップ :up:
下準備おわり。
日々の運用
チケットを作る
GitHub, GitLab, Redmine, Backlogなど、お好きなツールでチケットを作りましょう。
仮に、チケットのIDを「SR-400」、タイトルを「認証機能の実装」としましょう。
作業開始
GitHub Flowを採用するとしたら、こんな感じで開発を始めるかと思います。
git checkout master
git pull
git checkout -b feature/SR-400/auth
# developing...
最初のコミット
開発が一段落して、コミットする際には、さきほど作ったテンプレートを使いましょう。 git commit と打ち込むだけです。すると、コミットテンプレートが現れるので、 ↓のように書いて、保存しましょう。（書いてるのは１行目だけ）
:+1: SR-400 認証機能の実装
# ==== 以下、変更不要です。 ====
１行目にコミットメッセージを書いて、そのまま保存してください。
ここから下を消す必要はありません。
# === format ===
# :emoji: issue-id issue-title
# ==== example ====
# :+1: SR-400 認証機能の実装
# :bug: BG-128 Thanksメッセージは２通ではなく１通
# ==== Emojis ====
# 👍 機能追加 :+1:
# 🐛 バグ修正 :bug:
# 💚 リファクタリング :green_heart:
# ✅ テストの追加 :white_check_mark:
# 📝 ドキュメント追加 :memo:
# 🚀 パフォーマンス改善 :rocket:
# 🆙 バージョンアップ :up:
ログを確認してみます
ログを１つだけ確認してみましょう。
$ git log -n 1
commit fe585630d1b681bec82000455244534cc3806d0a (HEAD -> feature/SR-400/auth)
Author: xxxxxxxx <xxxxxxxxxxxxxxxxx@gmail.com>
Date: Fri Jun 28 23:52:00 2019 +0900
:+1: SR-400 認証機能の実装
以降のコミットは自由に
２つめ以降のコミットは自由な書式で構いません。（あとでrebaseでまとめます）
ここでは仮に１個だけ、「Fix it!」というコミットメッセージとしておきましょう。（書いた本人にしかわからなくてよいのです）
開発完了！
開発が完了したので、コミットをまとめます。
まずはログを確認
git log --oneline -n 3
fe58563 (HEAD -> feature/SR-400/auth) Fix it!
deea1b2 :+1: SR-400 認証機能の実装
c5802b5 (github/master) :+1: SR-398 支払い通知機能
次にrebase
まとめたいコミットの１つ前のコミットを指定します。
git rebase -i c5802b5
すると、こんな感じの画面に切り替わります。コミットの上下が逆順になっているので、お気をつけください。
pick deea1b2 :+1: SR-400 認証機能の実装
pick fe58563 (HEAD -> feature/SR-400/auth) Fix it!
# Rebase c5802b5..fec822c onto c5802b5 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# ..略..
squashする
このようにpickをsに変えることで、１つ上のコミットにまとめることができます。この状態で、esc→wqで保存すると..
pick deea1b2 :+1: SR-400 認証機能の実装
s fe58563 (HEAD -> feature/SR-400/auth) Fix it!
こんな感じの画面になります。そのまま保存します。
# This is a combination of 2 commits.
# This is the 1st commit message:
:+1: .commit_template の修正
# This is the commit message #2:
Fix it!
結果を確認
こんな感じにまとまります。コミットIDが変わっているということは、新しいコミットが作成されたということですね。いちおう、squashして消えてしまったコミットにcheckoutしたところ、移動できたので、squashしたといってもコミットを消すわけではなさそうなので、なにかあっても取り返しがききそうですね。
$git log -n 2 --oneline
46e1a62 (HEAD -> feature/SR-400/auth) :+1: SR-400 認証機能の実装
c5802b5 (github/master) :+1: SR-398 支払い通知機能
まとめ
やり方、日々の運用としてはこんな感じです。
squashのタイミングはプロジェクトごとに、PullRequestの前とか、（LGTMがもらえて）マージする直前にやるとか、あるいは、GitLabであればマージするさいのSquash機能を使うとか..いろいろ選択できそうです。いずれにしても、あとから振り返る際に、ビジネス側の人から「あのときのチケット、、、ええとSR-117のとき、どうだった？」と聞かれたりしても、ログをすぐに追えると気持ちよさそうです。