会社でGit使ってて、ちょっといろいろモニョモニョする部分があるのですが、一応現時点でそこまで困ってないので強めに言えない的なものの、やっぱりモニョモニョするので個人的なGitの運用ポリシー的なものを書いて整理してみようと思います。

今回はとりあえず、コミットの部分を中心に書いてみたいと思います。以下は私が「コミットはこうあるべきじゃないのかな~」と思うものです。従って、書いてる内容がベストとは思いませんし、現場にあったそれぞれのやり方が別にあると思います。実際、以下を全て実践しようとすると、そこそこのGitの知識も必要だし、手間がかかる部分もあるので会社であんまり強く言えない的なのはある…。

コメント

私がコミットコメントを書く上で気を付けているのは下記の辺りです。

  • 自分も含めて後から見た人が解るように書く
  • コメントの1行目は50文字くらいを目安に
    • 書ききれないものは改行して箇条書きで詳しく書く
  • チケットやIssue番号がある場合はコメントの頭に書く
    • 基本的に何らかのチケットやIssueで起票されているべき

なんか、前にもどこかで書いた気もしますが、私はコミットコメントは「自分も含めた後の人が見たときのため」に書くものだと思っています。ですので、コミットコメントはできるだけ丁寧に書く必要があると考えています。多くのGitのGUIツールは樹形図上でコミットコメントの1行目しか表示されない(git logで簡易表示した場合も同様のハズ)ので1行目に概要を書きます。1行目に書ききれないものは改行して詳細を箇条書きで書くようにしています。確か、Gitそのものの開発リポジトリもそのような方針だったと思います。

また、開発中であろうとなかろうと、実装する機能はなんらかのプロジェクト管理ツール等でチケットやIssueが起票されているべきです。従って、コメントの頭にその番号を記述するようにします。

と、偉そうに書いておきながら、個人で開発するやつは初期のリリースまではIssueを起票せずにやってます…。また、GitHubに上げるものは英語の勉強も兼ねてコミットメッセージを英語にしていますが、英語だと詳細を書ききれずに適当になってしまったりしてます…自分に甘い…。

動く単位でコミットする & squash

そのコミットで最低限動くのが担保されているべきだと考えています。要するに、そのコミットまで戻して動かしたときに全く動かないとかエラーが出るとかいうのはアカンと思ってます。ローカルのコミットの段階(あるいはリリースにマージされる前)では構わないと思いますし、私も作業途中のものをローカルでガンガンコミットしますが、リリースにマージするのはナシです。動作が担保されていないコミットを含むブランチはマージする前に動作する単位でsquashでまとめてからマージするべきです。

ちょっと上記じゃ何書いてるかわかんないですね。書いといてアレですが、私もわかりません。ですので、頑張ってもうちょっと説明してみます。

いいですか?まず、ブランチ切って開発はじめますよね?で、開発中のものをコミットする。で、このコミットはその時点で動作が担保されてない。この動作が担保されてないってのはそのブランチで実装・修正する機能の開発が完了していないというものではなくて、その時点のコミットで動かないとかそういう致命的な意味での担保されてないってことね。で、開発時点で別にそれは構わないと思うんですよ。(個人的にはアカンと思うけど、私も個人開発だとたまにやるので強く言えない…)

で、ですよ、そういう致命的に動かないコミットが積み重なって、最終的にそのブランチでの開発が終了しますよね。

私が言いたいのは、この後で、そいつをマージする前にsquashするべきっていう話なんですね。わかりました??要するに、マージしたら基本的に取返しが付かないので、致命的に動かないコミットが含まれてる場合は、そいつを動く単位のコミットにまとめてからマージするべきって話ですね。オッケー??たぶん伝わった。え~っと、ちょっとアレだな、よくまとまってないので、もう少し書くとですね…ああ!もうなんだ、最初に書いてる通りなんですが 最低限動作する単位でコミットするべきってことですね。説明ヘタで、これ以上書けないんですけどオーラを感じてください。

関係ないコミットをしない

これね~ホントに困るんですよ…。いいですか、機能の変更とか修正してるときについつい「インデントとかもなおしたいな~」ってなりません?なりますよね?私はなる。しかし、これをですね機能の変更とか修正とかのコミットと一緒にやらないでくださいね。お願いなので。いやね、後から変更を追うのが大変になるんですよ。マジで。「ほうほう、これはこの修正で変更かかったのか…」って調べたら「ただのインデント修正でした!」ってのはよくあって疲れる。疲れるので、こういう変更は別のコミットでするべきです。まぁ、インデントに関していえばIDEで統一させるとか、コミット時にhookでそろえるようにしておくとか、もっと別の対応方法がありますが、今回はそういう話ではないので書かないですが。

先日の話ですが、私がとある修正をしてるときに「バックアップのコミット」とかいうよくわからないコメントが書かれたコミットを発見しまして「コードの修正・コードのコメントアウト・インデントの修正」を一つのコミットでやっているという3段コンボを喰らいまして、飲んでいたコーヒーを噴出しながらイスからひっくり返りそうになりましたね。こういうコミットはダメです。ダメダメ。(ちなみに弊社社員のコミットではなかったです)

コミットの前に変更箇所をチェックする

これね~ホントね~やってない人多すぎじゃないのかという疑惑があるんですよ。上記で書いたようなことって基本的に(本人が解ってやってるのを除いて)これさえやってれば防げるんじゃないかと思うんですね。コミットの前に関係ない変更が含まれていないかどうかとかチェックしてます??私はやってます。個人開発だとちょっと気を抜いてやらかすことはありますが…

こういうのを防ぐためにレビューがあると思うのですが、実際コミット・マージでちゃんとレビューできている組織ってそんなにないんじゃないかな~と思ったり。こういうのどうしたらいいんですかね~。ちなみに、私も協力会社から上がってきたものの中で流石にアレなのは修正してほしい旨を伝えるのですがsquashせずに続きでコミットしてpushしてくるんですね~。不要なコミットはなるべく入れたくないので私が先方に連絡したうえでsquashしなおしてマージするのですが、やらない理由がよくわかんないですね。squashが無理ならせめてforce pushで上書きしてくれませんかね。force pushの是非はあると思いますが、そのブランチに関連している人が認識していれば私は別にやっても構わないと思ってます。こういったあたりの意識ってどうしたら根付いてくれるんでしょうか…?

まとめ


個人開発を言い訳に私もサボるときはありますが、要するに 全ては自分も含めて後から見たときに解り易くする ためのものだと思ってます。保守フェーズで苦労したくなかったらコミットはキッチリやりましょう。たぶん上記で書いたことはそこまでずれた内容ではないと思います。

次はブランチとかマージとかについて書くと思います。