もふもふ技術部

IT技術系mofmofメディア

mofmofメンバーに聞いてみた!より良いコミット・コミットメッセージとは?

背景

こんにちは!mofmofのエンジニアの齊藤です。この度、弊社のホームページ内にmofmofへの応募を考えてくださっている人のためのコンテンツ、「もふもふ診断」をリリースしました。

「技術診断」「相性診断」の2つの診断を用意していて、それぞれ技術面/社風へのマッチの2つの側面からmofmofとの相性チェックできます。

▼mofmof診断トップページ Image from Gyazo

ところで、もふもふ診断の中にはコミットとコミットメッセージに関する問題があり...

▼コミットメッセージに関する問題はこちら Image from Gyazo

その解説には、以下のように書いてあります。

細かい書き方は色々な流儀があるから、案件ごとに確認するといいぞ。

問題を精査していく中で、開発チーム間で 「コミットメッセージの"書き方"や"流儀"ってなんだろう」 という話になりました。

なんとなく、今まで「こう書けば良いのだろうな」という暗黙の了解はあったのですが、社内に明文化されたルールはなかったので、これを機にmofmofのメンバーに聞いてみました。

mofmofメンバーに聞いてみた

mofmofには、技術に関することを勉強し、話し合うtechの時間という時間があります。

今回はtechの時間を利用して、座談会形式でmofmofメンバーと 「より良いコミットとは?」 について話し合ってみました。

(写真を撮り損ねてしまったのですが、techの時間の雰囲気は、この記事の内容が近いかもしれません。ビデオ会議ツールを使って、わいわい楽しく雑談しつつ話し合います。)

以下、座談会の内容を要約する形で紹介します。

コミットメッセージを書く時、どんなこと心がけていますか?

tips1

齊藤: コミットメッセージを書く時って、色々気を遣うことが多いですよね。みなさんはどんなことに気をつけてコミットメッセージを書いていますか?

Aさん: コミットでは、 そのコミットでやったことが端的にまとまっている とありがたいかな。 コミットを後から辿るときがたまにあるよね。 その時に「何でこのコード書いたの?」というのは、コードを見ただけではわかりづらい よね。

Bさん: 僕は そのコードを書いた背景 なんかも書くようにしているかな。あまり大きい背景はプルリクの説明文に書いても良いかも。

Aさん: その意味で、問題文に出ていた”Push”というコミットメッセージは、背景ややったことを全く説明していないよね。

理想のコミットって、どんなコミットですか?

tips2

tips3

齊藤: なるほどです。コミットの大きさ、粒度についてはいかがでしょう? 「こうしたら良い」など心がけていることはありますか?

Cさん: 一つ一つのコミットに意味を持たせるのが良い よね。複数のことが混じると、何をやったかわからなくなりがちだから。

Bさん: 機能の追加なのか、修正なのか、削除なのか。「やったこと」ごとに分離していると良い かな。 あとは、不具合ややり直したい内容があったときに、戻せる単位が良いよね。

Cさん: そうだね。 バグがあった時にもコミットが大きすぎるとどこに不具合があるのか特定しづらくなる

プレフィックスつける?英語 or 日本語?どこまで気を使えば良いの?

tips4

齊藤: コミットメッセージにプレフィックスをつけましょうという意見もありますよね? 「やったこと」をわかりやすくするという意味ではそういった方法もあるかと思いますが、どうでしょう?

Dさん: 追加 … 絵文字 / 削除 … 絵文字 という方法もあると聞いたことがあります。コミットの前に、add, crearte, delete などをつけたこともあります。

Bさん: 1コミット単位でやると訳がわからなくなりがちだし、mofmofは少人数のチームで取り組むことが多いので、そこまでしなくてもチーム内で意味は共有できる印象かな。

齊藤: なるほど。意味の共有ですね...。同じく「意味の共有」的なところでいうと、コミットメッセージを英語で書く人と日本語で書く人がいますが、そのあたりはどう判断していますか?

Aさん: 個人でアプリを作るときは英語の時もあるけど、チームで作業するときは可読性も考えて、日本語かな。

コマンドを実行したときのコミット

tips5

Bさん: ただ、コマンドを実行したときなんかは、そのコマンドをそのまま貼りたくなるときない?

yarn add liblary-name

みたいな。

Aさん: あー、それはある。

Cさん: コマンドと、その後に書いたコードはコミットを分けられると良い よね。 ライブラリの初期状態のコードがこれで、その後自分で書いたコードがこれ、みたいな。

Aさん: その方が、どこで設定に失敗したのかわかりやすいよね。

Dさん: 学習を始めたばかりの時は、ネット上の記事に書いてあるセットアップ方法(ライブラリのインストールとその後に書いた設定のコード)を全て書いてからコミット、みたいなことをよくやっていました。 不具合があったときに後戻りが大きかったので、しまったと思ったことが何度かあります。

mofmof的コミットのベストプラクティスは?

齊藤: ありがとうございます。ところで、結局mofmofのコミットのベストプラクティスって、何になりますか?

全員: プロジェクトに合わせる、じゃないかな。笑

齊藤: 笑 でも、みなさんの話した内容を聞くと、一緒に作業するメンバーや、あとでコードを見る人への気遣いが見て取れますね。となると、 「相手のことを気遣いつつ、チームの方針に合わせる」 がベストなのかもしれませんね。

本日はありがとうございました。

conclusion