こんにちは。次世代デジタル基盤開発事業部の熊谷です。 普段はWebアプリケーションのフロントエンド・バックエンドの開発に携わっています。
突然ですが、Gitとは何でしょうか？
多くのソフトウェア開発者は「ソースコードのバージョン管理ツール」と答えるでしょう。 しかし、私はそれだけではなく「コミュニケーションツール」としての側面も大いにあると考えています。 今回は私が実務の中で得た経験から、Gitのコミュニケーションツールとしての側面について記載します。
…と、大層な事を言っていますが、先に結論を書いておくとコミットメッセージをちゃんと書こうという話です。 この話題については色々な意見があり、すでにネット上にはコミットメッセージに関する記事は沢山あります。 この記事では、私の経験から導き出した一つの意見を共有します。
この記事を読んで欲しい人
対象読者としては、すでにある程度Gitの知識があり、基本的な操作ができる方を想定しています。 また、会社で仕事として開発することを前提として話をするので、仕事でGitを使っているという方に読んでいただきたいです。 Gitの使い方を、コミュニケーションの観点から改善するきっかけになればと思います。
新年度も始まり、ソフトウェア開発者として新社会人になった方も多いと思います。 新人研修でGitを使ったという人も多いと思うので、そういった人にも読んでもらい、実務でGitを使う際に役立てていただければ幸いです。
コミュニケーションを取る相手は未来の自分
まず、Gitでコミュニケーションを取る相手とは誰でしょうか？
これはリポジトリの公開範囲にもよりますが、企業や特定の団体だけで共有される非公開リポジトリであればプロジェクトメンバー、GitHubなどで共有している公開リポジトリであれば全世界の人々など、基本的には他者とのコミュニケーションになります。
しかし、もう一つ忘れてはいけない相手が「未来の自分」です。
これは個人開発で一人でコードを書いている状況が良く当てはまりますが、他者と共同で開発している場合でも未来の自分とのコミュニケーションは発生します。
長年開発をしている方であれば経験があると思いますが、自分が書いたコードでも、時間が経つとそのコードを書いた経緯を忘れてしまうことがありますよね（少なくとも私がそう）。
そうすると、「このコードを書いたの誰だよ！？あ、俺だったわ…でもなんでこんな書き方したんだっけ？」というようなことになりかねません。
なので半年後の自分は他人であるという意識を持ち、未来の自分もGitでコミュニケーションを取る相手だと認識することが大事です。
コミットメッセージを明確に
ではどうやってGitでコミュニケーションを取るのでしょうか？ それはやはりコミットメッセージです。
Gitのコミットメッセージの書き方については散々議論されていて、人により見解は異なります。 けれども共通して言えることは、そのコミットで何をしたのかが分かるようなメッセージを書く事です。
コミットメッセージは、上記で言う「Gitでコミュニケーションを取る相手」に向けて書くものです。
相手がメッセージを読んで、そのコミットで何が行われたのかが理解できなければ、それはコミュニケーションが取れていないことになります。
このコミットメッセージでのコミュニケーションが取れていないと、相手は知りたい事柄（発生したバグの原因など）に対して関係ありそうなコミットを一つ一つ確認したり、場合によってはその対応が行われた経緯を探すために資料やチャットの履歴や過去のプルリクエストをさかのぼって調べなくてはなりません。
ソースコードにちゃんとコメントがあったり、過去の経緯が調べやすくなっているのであれば問題ありませんが、少なくともコミットメッセージがちゃんと書かれている場合に比べて時間がかかります。 そのような状態が続くと、プロジェクトの円滑な進行に支障が出てしまい、最終的には会社にとって不利益になる可能性があります。 （プロジェクト期間延長に伴う損失や、リポジトリ自体が技術的負債になってしまいかねないという不利益）
なので、Gitを介したコミュニケーションを円滑にするため、コミットメッセージは明確に記載するように心がけましょう。
コミットメッセージを明確にするテクニック
コミットメッセージを明確にする方法は色々ありますが、この点については人によって様々な意見があります。 そのため、ここでは私が今までの経験から考える私なりの方法を挙げていきたいと思います。
コミットの変更内容を1行で要約する
まず第一にするべきことは、そのコミットで加えた変更について1行で要約することです。 コミットの一覧を見たときに、そのコミットで何が行われたのかが分かるように記載してください。
もし1行で要約することができないくらい変更量が多い場合は、それは一つのコミットで加えようとしている変更内容が多すぎる可能性があります。 その場合は変更内容を見直し、1行で要約できるくらいの粒度に変更を分けてコミットしてみましょう。 そうすることで、コミットメッセージだけでなくコミットの内容自体も確認しやすくなるはずです。
複数行のコミットメッセージを活用する
コミットメッセージを書く上で、1行で要約した内容だけでは情報を伝えきれない場合があります。 主にはそのコミットを行った背景や理由になりますが、そういった情報もコミットメッセージに入れておくと、相手により多くの情報を渡すことができるためコミュニケーションが取りやすくなります。 そう言った理由を書くと1行では収まらなくなるので、複数行に分けてコミットメッセージを書きましょう。
GitのGUIツールを使えば複数行のメッセージを書くのは簡単ですが、CLIから使う場合でも簡単に複数行メッセージを書けます。 複数行のメッセージを使って、その変更を行った理由、背景、関連するissueやPRなどを共有しましょう。
# 複数行のメッセージを残す git commit -m "コミットの要約" -m "背景などの説明文" # エディタでメッセージを書く # デフォルトではnanoエディタが開くので、vimを使いたい人はgit configで設定する git commit
※エディタやGUIツールでコミットメッセージを記載する場合、2行目には空行を入れ、3行目から詳しい内容を記載してください。2行目にもテキストを入れてしまうと、Gitのツールによっては空行が入るまでを1行目としてみなされてしまう場合があるためです。
もちろん理由を書くまでもない場合もあるので、無理に複数行コメントを付ける必要はありません。 Gitのコミュニケーションを取るうえで必要だと判断した場合に適宜使用してください。
コミットメッセージは日本語で書いてもいい
コミットメッセージを書く際に、しばしば英語で書くべきかという点が話題に上がります。
最近の環境であれば、日本語で書いたり絵文字を入れたりしても文字化けなどの問題は起こらないはずなので、Gitのシステム的にはどちらでも大丈夫です。
（むしろ、特定の絵文字を接頭語として使って見やすくしようという動きもあったりする。）
なのでどの言語でコミットメッセージを書くかは、そのリポジトリを利用する人や公開範囲で判断すると良いと思います。
私としては、リポジトリにアクセスする人がほぼ日本語話者であるならば、日本語で書いた方がコミュニケーションを取りやすいはずなので、日本語でコミットメッセージを書く方が良いと思います。 逆に、英語の方がコミュニケーションを取りやすい環境であるならば、英語で書いた方が良いと思います。 また、OSSなど日本語圏の人以外にも利用される可能性がある公開リポジトリの場合は、英語で書いておいた方が無難です。
ただし、どちらの言語でメッセージを書く場合でも、明確なメッセージ内容にするという点は変わりません。 例えば、英語で書く事にこだわってしまった結果、メッセージの内容から必要な情報が欠落してしまっては意味がありません。 英語が得意でないのに英語で書かなくてはならない状況になってしまったら、機械翻訳の丸写しで構わないので、ちゃんとした内容を記載するよう心がけましょう。
プレフィックスはどちらでもいい
良いコミットメッセージの書き方として、1行目の先頭にはfeat, fix, refactor などのプレフィックスを付けるという方法がよく知られています。
しかし、私も以前は付けるようにしていたのですが、最近は付けなくてもいいのではないかと思うようになり、必須とはしなくなりました。
一番の理由としては、プロジェクトメンバー全員でプレフィックスを選ぶ基準を統一することが難しいという点です。
例えば、refactorが付けてあるのにロジックの修正がしてあったり、機能を変更することによりバグを解消した場合に、人によってfixを付けたりfeatを付けたりする場合などのケースです。
付与されているプレフィックスと変更の内容が合っておらず、プレフィックスが逆にノイズになってしまうという場面に遭遇することがありました。 このような経緯も含め、コミットメッセージにプレフィックスを付けることの恩恵を感じることがあまりありませんでした。
メンバー全員で全く同じ判断基準をもって付与できるのであれば良いですが、実際にはプロジェクトメンバーはその時々で変わるため、プロジェクトごとにメンバー間で認識を毎回合わせるというのはなかなか難しいものでした。 そのため、プレフィックスについて悩みながら実装をしてもらうよりも、いっそのことプレフィックスは付けず、コミットメッセージを明確にしてもらうことに注力してもらうという方針にすることが多くなりました。 プレフィックスを付けない場合、付けている時よりもコミット一覧は見づらくなりますが、コミュニケーションは取りやすくなると感じています。
ただし、必ずつけてもらいたいプレフィックスがあり、それが hotfix と revert です。
hotfixは本番で起こっているバグについて早急に対応した際に付与し、revertは特定のコミットを機械的に打ち消す場合に（多くの場合自動で）付与されるものです。
これらのコミットは重要度が高いので、そのコミットで何をしたのかが一目で分かるようにプレフィックスを付与しておいた方がありがたいです。
プレフィックスを付ける場合の基準
上記のように私はプレフィックスを必須としていませんが、プロジェクトメンバー間で基準を統一することができる場合は、プレフィックスを付けることによりGitによるコミュニケーションをさらに円滑化することができると思います。
プレフィックスを付ける運用の場合、 Conventional Commits や Semantic Commit Messages のような仕様を取り入れることで、メンバー間で基準をある程度統一することができると思います。
また、自動でプレフィックスを付けさせるツールを導入したりすることで機械的に統一してしまうのも一つの手です。
もしプレフィックスを付ける運用をする場合は、これらの点を参考にすると楽になるかもしれません。
まとめ
- Gitはソースコードのバージョン管理ツールであるとともに、未来の自分を含む開発者同士で、どのような変更を加えたのかを共有しあうコミュニケーションツールとしての役割を持っています。
- 伝達手段はソースコードはもちろんですが、コミットメッセージを使ってどのような変更を加えたのかを手短に伝えるのが効果的です。
- 良いコミットメッセージを書くために様々なルールが提案されていますが、どんな場合でも一番大事なのは、変更の内容とその理由が読み取れる内容を書き込むことです。
- 少し面倒に感じるかもしれませんが、1行目に加えた変更の要約を書き、2行目に空行、3行目から変更を加えた背景や理由などを書くようにし、コミットを行った際の状況を記録するようにしましょう。
この記事の内容を参考に、Gitは他の開発者とコミュニケーションを取るものであるという認識を持っていただき、チームでの開発をより円滑にしていく手助けになれば幸いです。
テコテックの採用活動について
テコテックでは新卒採用、中途採用共に積極的に募集をしています。 採用サイトにて会社の雰囲気や福利厚生、募集内容をご確認いただけます。 ご興味を持っていただけましたら是非ご覧ください。
