Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コミットメッセージを書く時に気をつけていること
Search
宮田勉
November 04, 2022
Programming
2
360
コミットメッセージを書く時に気をつけていること
コミットメッセージについて、お客さん先で発表した内容になります。
宮田勉
November 04, 2022
Tweet
Share
More Decks by 宮田勉
See All by 宮田勉
コミットするタイミングについて
tmiyata
0
180
Other Decks in Programming
See All in Programming
無関心の谷
kanayannet
0
160
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
210
TypeScript LSP の今までとこれから
quramy
1
500
ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化
knih
10
1.8k
Perplexity Slack Botを作ってAI活用を進めた話 / AI Engineering Summit プレイベント
n3xem
0
650
PT AI без купюр
v0lka
0
230
イベントストーミングから始めるドメイン駆動設計
jgeem
4
830
Rails産でないDBを Railsに引っ越すHACK - Omotesando.rb #110
lnit
1
160
業務自動化をJavaとSeleniumとAWS Lambdaで実現した方法
greenflagproject
1
110
2度もゼロから書き直して、やっとブラウザでぬるぬる動くAIに辿り着いた話
tomoino
0
160
ReadMoreTextView
fornewid
1
400
実はすごいスピードで進化しているCSS
hayato_yokoyama
0
110
Featured
See All Featured
Gamification - CAS2011
davidbonilla
81
5.3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.8k
Side Projects
sachag
455
42k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
650
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
780
Into the Great Unknown - MozCon
thekraken
39
1.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Why Our Code Smells
bkeepers
PRO
337
57k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Transcript
コミットメッセージを 書く時に気をつけていること 宮田 勉
注意事項 • あくまで一個人の考えです • 正解はありません • 私が普段考えていることの共有です
今日の内容 • コミットメッセージとコミットログ • コミットメッセージのゴール • コミットメッセージを書く上でのポイント紹介 • まとめ
質問です! こんなコミットメッセージ書いていないですか? • 実装中 • fix bug • 指摘修正 •
リファクタリング • RSpecの修正
• 実装中 • fix bug • 指摘修正 • リファクタリング •
RSpecの修正 こういうコミットメッセージはよくないと思っています 何が問題だと思っているのかを解説していきます
コミットログ 変更履歴(差分、メッセージを含む) 解説の前にまずはコミットについて コミットメッセージ 変更内容の要約 コミットログ コミット メッセージ
コミットログについて考える • コミット ◦ 『確約する』『誓約する』 • ログ ◦ 記録 •
直訳すると『確約する記録』
記録の意味についてもう少し考える • 『記録』の意味を辞書で引くと... ◦ 将来のために物事を書きしるしておくこと ◦ 競技などで、数値として表された成績や結果 ◦ 歴史学・古文書学で、史料としての日記や書類
記録の意味についてもう少し考える • 『記録』の意味を辞書で引くと... ◦ 将来のために物事を書きしるしておくこと ◦ 競技などで、数値として表された成績や結果 ◦ 歴史学・古文書学で、史料としての日記や書類 重要そうな言葉が!?
記録をする意味 • 将来のために物事を書き記すということは? ◦ 後々見直した時に何が起きたかわかるようにするため ◦ 忘れても見れば思い出せるようにするため ◦ 未来でこの物事を見るであろう人にも伝えるため ◦
etc … 自分を含めた未来の人に伝わるようにする必要があります!
コミットログも同じ!
コミットメッセージ • コミット内容を要約したもの ◦ 修正内容を理解する為に役に立つもの 重要なのは... 読んで何を(What)しているかが伝わること 何を(What)だけでなく、何故(Why)その修正をしたかが伝わること
今回メインになるのはコミットメッセージ • コミットログは、コミットをどう積み方(分け方・まとめ方)の話になる • コミットメッセージは、メッセージをどう書くかの話になる • 今回は、コミットメッセージがメイン(コミットの積み方については深くは 話をしない)
例に戻りましょう コミットメッセージは、以下2点が重要 • 読んで何(What)をしているかが伝わること • 何(What)をだけでなく、何故(Why)その修正をしたかが伝わること 以下コミットメッセージから、修正内容がわかりますか? • 実装中 •
fix bug • 指摘修正 • リファクタリング • RSpecの修正
例に戻りましょう コミットメッセージは、以下2点が重要 • 読んで何(What)をしているかが伝わること • 何(What)をだけでなく、何故(Why)その修正をしたかが伝わること 以下コミットメッセージから、修正内容がわかりますか? • 実装中 •
fix bug • 指摘修正 • リファクタリング • RSpecの修正 何をしているか 伝わらないです
何故伝わらないかを考えてみる • コミット内容(差分)を見ないと何(What)をしているかわからない • 何故(Why)その改修をしたかがわからない コミット内容を見て、1から考える必要が出てくる 何(What)は、最悪差分を見ればわかるが、 何故(Why)は差分から推測しづらい ※ 何故(Why)を書くことが重要
その結果
でも、コミットメッセージって見直すことってある? • あります! • 例えば... ◦ 案件参画したばかりで、該当システムの仕様の知識が浅い場合、『何でこの処理があるんだ ろう?』って思う時がある ◦ 情報源としては、人、仕様書、コミット
▪ 人:実装者や詳しい人が常にプロジェクトにいる保証はない ▪ 仕様書:メンテされていないリスクやそもそも存在しない場合もある ▪ この場合、コミットメッセージが貴重な情報源になる! • コミットメッセージに何故(Why)が書かれていないと、実装当時の意図がわか らず、ソースコードから読み取っていくしかない ◦ 時間がかなり取られる! ◦ 時間をかけても、何故(Why)がわからない可能性もある!
時間を取られない為に意識して欲しいこと • 人間は忘れる生き物です ◦ 今はレビュアーもレビュイーも何でこの実装をしているのかわかるかも知れない ▪ 1週間、1ヶ月後、半年後と経って、改めて見た時に何故(Why)その改修をしたか思 い出せますか? ▪ 思い出せたとして、すんなり思い出せますか?(思い出し工数かかりませんか?)
• 自分一人で開発しているわけではない ◦ チーム開発をしているので、当然他の人も見ます ▪ 自分だけが見ればわかるだと、他の人が見た時に困ります ▪ 差分から何を(What)はわかっても、何故(Why)はコードだけでは推測しづらいも のです
コミットメッセージのゴール • コミットメッセージだけで、改修内容が想像つくように書かれている • 何(What)だけでなく、何故(Why)が書かれている あくまで一例ですが、 読んだだけで何となく 改修内容がわかるのが理想
何故(Why)を書くの難しいというあなたへ • 何(What)は書けるけど、何故(Why)を書くのは確かに難しい • 自分も完璧にできている自信はない • 自分が何故(Why)を書く為に意識しているポイントを紹介
コミットメッセージの書き方 • ポイントを紹介する前に、一般的な書き方 1. フォーマット a. 1行目 変更内容の要約(必須) b. 2行目
空行 c. 3行目以降 変更した理由(任意) 2. 敬語や丁寧語では書かない a. 命令形推奨ではありますが、日本語の場合は敬語や丁寧語を止めるぐらいで十分 3. 現在形で書く a. 1行目は現在形 b. 3行目以降で経緯を記載する際は過去形でも良い
ポイント①:変更が必要になった理由を書く • 何故(Why)を書くとなると、『何故そのコミットをしたのか』を書いてし まうことがある ◦ 例えば ▪ レビューで指摘されたので • 書いて欲しいのは、『何故その変更が必要になったのか』というWhyが必要
ポイント②:コミットの粒度 • 何故(Why)が書けない原因として、修正内容が複数混ざっていることがあ る ◦ 差分の大小関係なし
ポイント②:コミットの粒度(例) 『機能追加』と『リファクタリング』を1つのコミットにまとめた場合 • どこが機能追加でどこがリファクタリングなのかがわからなくなる ◦ 機能追加とリファクタリングは別物である ▪ 機能追加 → プログラムの動きが変わる
▪ リファクタリング→ プログラムの動きを変えないが、ソースコードを変える 修正内容が異なるので『機能追加』と『リファクタリング』でコミットを分ける
コミットの粒度について • コミットの粒度で調べると、人によって様々なやり方があるのであくまで先 ほどのは例です • ここ辺りの記事を参考にしてみたり、他の開発者の話を聞くことをお勧めし ます • 参考記事 ◦
https://qiita.com/jnchito/items/40e0c7d32fde352607be
ポイント③:コミットメッセージは1行で書かなくてもよい • 何故(Why)を書こうとすると、1行では説明できないことがある • 改修の経緯を記載すると1行で書くのは厳しい • その場合は3行目以降に経緯を記載する ◦ Slackやチケットのやり取りを載せることもある ▪
※注意 • URLだと、リンク切れやチケット管理システムの移行で見れなくなることもある 為、リンクのみは避ける
ポイント③:コミットメッセージの例 • 1行目 ◦ find_byだとnilを取得して後続処理が進んでしまう為、find_by!に変更 • 3行目以降 ◦ 現状、会員が存在しない場合に、find_byだと、存在しない場合にnilが返ってきて、後続処理 でNoMethodErrorで落ちる
◦ find_by!を使い、存在しない場合はActiveRecord::RecordNotFoundをハンドリングして500エ ラーにならないように修正
これらのポイントを押さえると • 差分をみなくても改修内容が想像つく • 何故(Why)が読み取りやすくなる レビューしやすくなる 理解する時間が圧倒的に減る 何故(Why)がわかる その結果
まとめ • コミットメッセージには、何(What)だけでなく、何故(Why)も書く • 何故(Why)は変更が必要になった理由を書く • 複数の修正内容を1つのコミットにまとめない • 背景の説明が必要な場合、1行で書かなくても良い
コミットメッセージを 上手に活用して、 開発を楽にしていきましょう
紹介 • 今回コミットメッセージの話でした が、開発する上で簡潔にまとまって いる言葉があるので紹介 • https://twitter.com/t_wada/status/9049 16106153828352
参考 • https://qiita.com/konatsu_p/items/dfe199ebe3a7d2010b3e • https://zenn.dev/shotaro/articles/2022-04-20-0000 • https://developers.freee.co.jp/entry/practice-of-git-commit-log • https://www.weblio.jp/ •
https://qiita.com/itosho/items/9565c6ad2ffc24c09364 • https://minus9d.hatenablog.com/entry/2014/02/11/125222
ご静聴ありがとうございました!