先日とある方と開発ワークフローについてお話していて初めて知ったのですがgit-commitには--allow-emptyという空の（親コミットと差分がない）コミットを作成できるらしいですね。
僕が今関わっているプロジェクトでは WIP PR を用いたワークフローを取り入れているのですが、このgit commit --allow-emptyを用いるともう一段階快適なワークフローになるかと思ったのでメモがてら書き留めておきます。
WIP PR って何？
Work In Progress Pull Request の略です。
Github に Pull Request （以下、PR と表記）という機能があるのは皆さんご存知だと思います（知らない方はググってください）し、業務で取り入れている方も多いと思いますが、それを作業途中の状態で出すことを WIP PR と呼びます。
作業途中のトピックブランチを PR することによって
- 早期にコードレビューのプロセスをまわせるので仕様誤認や設計不備があった場合の修正コストが比較的低い
- 修正コストが低いため、レビュワーも気兼ねなく指摘することができる
- 実装完了後のコードレビューだと「ここはもう少しこうしたほうがいいけど、スケジュールも詰まってるしすぐに問題になることはなさそうだから今回はこれでいいや…」となりがちです
- 作業に着手した段階で PR が作成されるので進捗を追いやすい / 他のメンバーが何をやっているか可視化される
といったメリットがあります。
これについては以前 LT をしたことがありますので（ほとんど同じことしか言っていませんが）そのときの資料をはっておきます。
WIP PR に感じていたモヤモヤ感
WIP PR の説明で「作業に着手した段階で PR が作成される」と書きましたが、これはすごく厳密には正しくなくて実際には「作業に着手した後最初のコミット作成された段階で PR が作成される」が正しいです。コミットがなければ PR は作成できませんので。
これが結構今までモヤモヤしていたことで、
- 最初のコミットまで時間がかかる（詳細設計が必要、等）場合、なかなか PR が作成されない
- （少なくとも最初の）コミットに関連付ける Issue が別途必要になる
- PR の番号を関連付けたいけど、最初のコミット時点では PR が存在していないためそれはできない
という問題がありました。
もしすべてのコミットが PR に紐づいていればそれ以外の Issue って必要ないなぁと思っていて、PR にコードが関連付いているので議論がしやすいですし、仕様の確認等も WIP PR が作成された後はそちらで行われ、もともとの Issue は形骸化してしまってました。
空のコミットで WIP PR を作成する
上記のようなモヤモヤが先日のお話の中で解決してしまいました。たった一言「あれ？Gitって --allow-empty オプションってありましたよね？」と。
空のコミットで WIP PR を作成すればそれ以降のコミットに WIP PR の番号を関連付けることができるため、事実上すべてのコミットが PR に関連付くことになります。これはあとからコミットログを追うことになった場合に大変便利ですね！
まだ実プロジェクトで導入はしてないのですがぜひ試してみたいと思います。