普段のコミット小話 とか
新人エンジニア向けのブートキャンプでドキュメントの話があって、その中でコミットメッセージ大事ですねという話があった。近い将来としては、レビューのためとかは考えられるけど、遠い将来も考えてみましょうといっていて、こんな文書を引用していた。
Re-establishing the context of a piece of code is wasteful. We can’t avoid it completely, so our efforts should go to reducing it [as much] as possible. Commit messages can do exactly that
確かにコードに落とし込んだ時は、コンテキストがかなり少ない状態になっていて、命名の工夫やコメントで手がかりを少しばかり残しておくことは出来るけど、それでもその時のコンテキストを再構築するのは大変だと思う。そのためにコミットメッセージがあるという話だ。
そこで、コミットのテンプレとしてこんな感じで書くとよいでしょう、というのが挙げられてた。
* このコミットを適用するとどうなるのか * なんでこのコミットが必要なのか * チケットのリンクとか参照情報
この話をしているのは僕の上司なのだけれど、たしかにコミットがこんな感じになっている。これは理想だけど、とはいえいちいち開発中考えてられなくて、だいたい普段は
ファイル追加した 大枠書いた wip wip 頼む lint これでどうだ 治ってくれ 今度こそ頼む テスト忘れてた うごいた
みたいになる。これは問題なくて、プルリク出す前に考えればよかろうと言ってた。そうですね。普段のワークフローもこんな感じだったんだけど、最近iOS開発始めてから状況が変わってきた感じがしてる。
iOSはプロジェクトファイルやGUIのファイルがXMLで構成されているので、なんかうまい感じにマージされるのが難しくなる。なので適当にコミットし続けていると、あとでgit rebase -i して歴史改変した時にうまくいくか不安だし、結果としてきれいなコミットログが残しにくくなる気がしてる。
そもそもプルリク出す前には割と時間かけてgit rebase -iとかしてるんだけど、なかなか時間が無駄なのでもっと普段から組み換えやすいコミットにしたほうが良いですね。
メンターの人から git push --force-with-lease 教えてもらってから、プルリク中でもガンガン歴史改変してる。ワークフロー整理してみると
- 適当にコミット
git rebase -i- PR出す
- 修正コミットしてそのままpush
- Approveされたら
git rebase -iし直して修正コミットとかを統合しちゃう - マージ
みたいな感じになっている。みなさんのgitワークフロー気になってきた。
ところで最近はiOSとかRailsとか書いてる。プログラミングでこう書けておしゃれですねみたいな話よりも、アーキテクチャとかどうしたら良いか、何処に何を置いたら複数人開発時に便利ですかね、みたいな工夫話の方が大事な気がしている。
