本記事は、 Qrunch からの移転記事です。

移転元: Gitのコミットメッセージに絵文字付きプレフィックスを適用する - 雑木林

TL; DR

コミットメッセージのプレフィックスは、Angularスタイルを基準としています。
また、各プレフィックスに絵文字を付ける際は、下記のようにしています。

はじめに

コミットメッセージにプレフィックスを付ける文化が、少しずつ広がっています。

• 【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
• angular.js/DEVELOPERS.md at master · angular/angular.js

一方、コミットメッセージに絵文字を付ける文化も、広まりつつあります。

• customizable-gitmoji-cliで、gitのコミットメッセージに絵文字を付ける - Qiita
• gitmoji | An emoji guide for your commit messages

両者を組合せれば、最強のプレフィックスが出来上がるのではないかと考えました。
ということで、絵文字付きプレフィックスという考え方を提案し、ここに記すこととします。

コミットメッセージにおける絵文字の付け方

コミットメッセージに、絵文字名を : で挟むことにより、GitHub上で表示できます。
また、コンソール上では、 emoji-cli などを利用することで、表示が可能です。

コマンドラインで emoji を扱う - Qiita

例えば、 ✨ (sparkles) という記号をコミットメッセージに書きたい場合、コミットメッセージを次のように記述します。

:sparkles: feat(ruby): やさしい日本語ページのルビタグ対応

すると、GitHub上のコミットメッセージとして登録されます。

covid19-miyazaki/covid19: 宮崎県(非公式) 新型コロナウイルス感染症対策サイト / Miyazaki COVID-19 Task Force website

コミットメッセージの1行目は、表示できる文字数に制限があるため、長すぎる絵文字名の絵文字は気をつけたほうがいいかもしれません。

git commit 時に書くコミットメッセージ1行目の表示文字数上限を調べてみた - Qiita

各プレフィックスと絵文字の紐付け

大前提として、プレフィックスを使う場合は、リポジトリ内で統一する必要があります。
これは、プレフィックスを使ったとしても、意味がわからなければ伝わらないからです。
同様に、多くの種類の絵文字を使うことも否定的です。
これからの時代は、プロジェクト毎に、コーディングスタイルと共にコミットメッセージスタイルも定義する必要があると思います。

今回は、Angularスタイルのプレフィックスを参考にします。
理由は、それ以外のスタイルを知らないからです。

angular.js/DEVELOPERS.md at master · angular/angular.js

また、絵文字については、Gitmojiを参考にします。
理由は、サイトが綺麗だからです。

gitmoji | An emoji guide for your commit messages

オリジナル絵文字を利用する場合は、GitHubで使える絵文字チートシートを参考にします。

🎁 Emoji cheat sheet for GitHub, Basecamp, Slack & more

以降、各プレフィックスの内容を説明し、それに見合った絵文字を紹介します。

feat

feat: A new feature

新機能を追加する際に利用します。

Gitmojiでは、同等の絵文字として ✨ (sparkles) を定義しています。
新機能を導入する際に使う絵文字です。

:sparkles: Introducing new features.

ということで、 feat には ✨ (sparkles) を利用します。

余談ですが、新機能というと、無かった機能を追加した際のみにも聞こえます。
僕の場合は、既存機能を変更する際や、既存機能を削除する際にも使っています。
変更／削除についても、変更することによって統一性が図れるとか、削除することによってUIが向上するとか、変更／削除そのものが機能追加という場合が多いなーと思っていたからです（いわゆる enhansement と同じ意味として捉えています。
これについては、プロジェクト毎に決めておくといいかもしれません。

fix

fix: A bug fix

不具合を修正する際に利用します。

Gitmojiでは、同等の絵文字として 🐛 (bug) を定義しています。
意味は全く同じです。

:bug: Fixing a bug.

ということで、 fix には 🐛 (bug) を利用します。

また余談ですが、個人的には、修正コミットに 🐛 を付けることは、若干抵抗があります。
GitHubでIssueファーストの開発をしていると、Issueでは不具合発見として 🐛 を付けて、修正プルリクとして 🐛 の絵文字を付けてしまいませんか？
🐛 という絵文字自体には2つの意味があるからです。

• 不具合発見時
• 不具合修正時

前者は 🐛 で問題ないのですが、後者については考える余地があるはずです。
もし虫網や虫籠の絵文字があれば、それを使っていたのですが......

コミット時に不具合を意図的に入れることは考えられない点と、不具合発見時をコミットメッセージで表すことが無い点、さらに 不具合 == バグ == 🐛 を知らないエンジニアがほぼいない点を考慮して、 fix には 🐛 がいいかなと考えました。

docs

docs: Documentation only changes

ドキュメント類を修正する際に利用します。
修正と言っていますが、追加や削除時にも使ってよいと思います。

Gitmojiでは、同等の絵文字として 📝 (pencil) を定義しています。
ドキュメント類を記述する際に利用します。

:pencil: Writing docs.

また、 pencil と memo は、GitHubでは同じ絵文字として認識されます。

ちなみに、鉛筆だけの絵文字は pencil2 です。
これは酷い......

ということで、 pencil では文字ベースとして判断しづらい点から、 📝 (memo) を利用します。

style

style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

ソースコードの可読性を変更する際に利用します。
Lintを適用した際や、空行を追加した際など、振舞いに変化を与えない変更が該当します。

Gitmojiでは、 🎨 (art) が当てはまるかもしれません。
🎨 は、ファイル構造を変更する際、または、ソースコードのフォーマットを変更する際に利用します。

:art: Improving structure / format of the code.

style という観点で言えば、2番目の意味に該当することは間違いありません。
また、1番目の意味も、ファイル構造の style という側面で見れば、該当すると見ることもできます。

しかし、 art という単語からは、UIに関連しそうなイメージが付きます。
実際、下記のようなIssueも上がっています。

🎨 for design and 📐 for structure · Issue #320 · carloscuesta/gitmoji

style という内容に合わせるため、ここでは 📁 (file_folder) を利用します。

📁 File Folder Emoji

refactor

refactor: A code change that neither fixes a bug nor adds a feature

ソースコードの可読性を向上する際に利用します。

Gitmojiには、同等の絵文字として ♻️ (recycle) を定義しています。
意味はほとんど同じです。

:recycle: Refactoring code.

ということで、 refactor には ♻️ (recycle) を利用します。

perf

perf: A code change that improves performance

パフォーマンスを向上する際に利用します。

Gitmojiには、同等の絵文字として ⚡️ (zap) を定義しています。
意味は全く同じです。

:zap: Improving performance.

ということで、 perf には ⚡️ (zap) を利用します。

test

test: Adding missing or correcting existing tests

テストコードを追加する際や、既存テストコードを修正する際に利用します。

Gitmojiには、同等の絵文字として ✅ (white_check_mark) を定義しています。
意味は全く同じです。

:white_check_mark: Updating tests.

また、チェックマークの絵文字は、他にも ✔️ (heavy_check_mark) が存在します。

正直、どちらでもいいとは思います。
個人的には、Windowsでの開発が多かったため、 ✔️ を利用していました。
✔️ のチェックの色が緑色で、わかりやすかったためです。

しかし、他OSではチェックの色が黒色で、わかりづらくなっています。
一方、 ✅ は、殆どのメーカーが緑色矩形の白抜きチェックであり、わかりやすくなっています。

• ✅ White Heavy Check Mark Emoji
• ✔️ Heavy Check Mark Emoji

ということで、 test には ✅ (white_check_mark) を利用します。

chore

chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

自動生成ツールによりファイルを変更する際に利用します。
chore とは、雑務という意味があります。

choreの意味・使い方・読み方 | Weblio英和辞書

Gitmojiには、該当する絵文字はありません。
一部分で該当しそうな絵文字は、いくつか定義しています。

少し頭を悩ませましたが、英語圏のスラングである 'It's a piece of cake' から取って、 🍰 (cake) を利用します。

it's a piece of cakeの意味・使い方・読み方 | Weblio英和辞書

Angularスタイル以外

以下は、Angularスタイル以外のコミットメッセージで利用する絵文字です。
プレフィックスは付けても付けなくても構いません。

First commit

最初のコミットとしてよく使われる first commit ですが、Gitmojiでは 🎉 (tada) として定義しています。

:tada: Initial commit.

ということで、 first commit には 🎉 (tada) を利用します。
プレフィックスは init とします。

余談ですが、個人的には first commit を空メッセージにするのは懐疑的です。
必要無いから消したのか、書き忘れたのか、空メッセージでは判断できないためです。

Gitの最初のコミットは空コミットにしよう - Qiita

Merge commit

マージ実行時のコミットですが、Gitmojiでは 🔀 (twisted_rightwards_arrows) として定義しています。

:twisted_rightwards_arrows: Merging branches.

ということで、マージコミットには 🔀 (twisted_rightwards_arrows) を利用します。
長いですが、マージコミットの1行目はあまり重要であることは少ないため、問題なしとします。
プレフィックスは merge とします。

Review commit

レビュー指摘反映時のコミットですが、Gitmojiでは 👌 (ok_hand) として定義しています。

:ok_hand: Updating code due to code review changes.

ということで、レビュー指摘反映コミットには 👌 (ok_hand) を利用します。
あまり個人的には多用しないようにすべきとは思いますが......

WIP commit

作業中コミット (WIP: Work in Progress) ですが、Gitmojiでは 🚧 (construction) として定義しています。

:construction: Work in progress.

ということで、作業中コミットには 🚧 (construction) を利用します。
プレフィックスは wip とします。

おわりに

現在ではプライベートリポジトリでしか利用してませんが、個人的には可読性が上がっている気がします。
これを開発チームに展開して共有できれば、また違った世界が見えるかもしれません。

絵文字は、用法用量を守り、適切にご利用ください。

ちなみに

Gitmojiでは、本記事と似たようなIssueが立っていました。
もしかしたら、Gitmoji側で方針が決まるかもしれません。

Add a "semver" field for each emoji · Issue #429 · carloscuesta/gitmoji

こんなリポジトリもあります。
これを使えば、本記事の内容をPJで統一しやすくなりますね。

negokaz/git-fancy-message-prefix: A Git prepare-commit-msg hook for fancy commit message