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
宮田勉
December 28, 2023
Programming
0
69
コミットするタイミングについて
コミットの粒度を適切にしようとする時のポイントをまとめてみました
宮田勉
December 28, 2023
Tweet
Share
More Decks by 宮田勉
See All by 宮田勉
コミットメッセージを書く時に気をつけていること
tmiyata
2
250
Other Decks in Programming
See All in Programming
Exploring Type-Informed Lint Rules in Rust based TypeScript Linters
unvalley
3
620
ペパボOpenTelemetry革命
pyama86
2
710
Next.js App Router
quramy
14
2.3k
Three ways to use AI on Android: The Good, the Bad and the Ugly
marxallski
0
120
Prepare for Jakarta EE 11 - Performance and Developer Productivity
ivargrimstad
0
190
CQRS meets modern Java
simas
PRO
2
470
JS RPCを理解する
yusukebe
3
210
TypeScriptで使いやすいOpenAPIの書き方
yukimochi_dwango
1
570
Sheets API使ってみた
toshi0383
2
180
Direct Style Effect Systems The Print[A] ExampleA Comprehension Aid
philipschwarz
PRO
0
410
Fast JSX: Don't clone props object #28768
yossydev
1
230
How to improve maintainability and readability of your automated tests? ( #scrumniigata )
teyamagu
PRO
1
130
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
228
130k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
34
6.1k
GraphQLの誤解/rethinking-graphql
sonatard
56
9.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.7k
How to train your dragon (web standard)
notwaldorf
75
5.2k
What's new in Ruby 2.0
geeforr
338
31k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
9
1.3k
Build The Right Thing And Hit Your Dates
maggiecrowley
25
2k
Rebuilding a faster, lazier Slack
samanthasiow
74
8.3k
Raft: Consensus for Rubyists
vanstee
133
6.3k
Transcript
コミットするタイミングについて 宮田 勉
注意事項 • あくまで一個人の考えです • 正解はありません • 私が普段考えていることの共有です
今日の内容 • 導入 • コミットの粒度とは? • コミットするタイミング
コミットとコミットログ • コミット ◦ 変更をバージョン管理ツールに保存されたもの • コミットログ ◦ コミットの集合体
コミットログで出来ること • 過去の変更を振り返れる • 問題があったら、1つ以上前の変更まで戻れる • 既にコミット済みの内容を後から修正できる • 複数のコミットを1つにまとめられる
便利だが、何も考えずにコミットすると... • 1つのコミットの中で色々な変更が入って何をしたいのかがわからない • 1つ1つのコミットが細か過ぎて、繋がりがわからない • 不具合があってコミットを切り戻したいけど、不具合と関係ない所まで切り 戻されてしまう • 日常生活で例えると整理整頓せずに収納しているイメージ
今日の話 • 整理整頓されていれば、探すときに時間かかからない • 保守しやすくなったり、レビューしやくなったりする、という話
コミットの粒度とは? • コミットするときの変更の度合いや規模
コミットの粒度が大きすぎる • 切り戻ししづらい ◦ 一部にバグがあっても、コミットのリバートができない • 修正内容がわかりづらい ◦ 差分が大きくなると、情報量も増える ◦
修正内容がわかりづらくなったり、見落としが発生しやすい 保守しづらく、レビューもしにくい!
コミットの粒度が小さすぎる • コミットが多くなる ◦ 1つ1つのコミットを見た時に、他のコミットとの繋がりがわかりづらい • 切り戻しの数が多くなる 細か過ぎても保守しづらく、レビューもしにくい!
コミットの粒度が適切であると • コミット単位で切り戻しがしやすい • コミット単位での差分が見やすくなる その結果 保守しやすく、レビューもしやすい!!
コミットするタイミング • 1つの作業単位 • 正常に動くタイミング
1つの作業単位の例:コマンド実行 • コマンドやツール等によって自動的に作成や変更が加わる単位でコミット • 以下が区別できる ◦ 人による変更 ◦ コマンド実行による変更
コマンド実行と手動変更が混ざっている例 • コードのフォーマット修正(自動で修正)されたもの • statusがcompletedだったらメールを送らない
コマンド実行と手動変更を分けた例 人の手とそうでない変更が区別つきやすいので見やすい 片方の変更だけ切り戻すこともできる
1つの作業単位の例:ファイル移動やリネーム • ファイルの移動やリネームといった機械的な変更のみでコミット • 上記以外の変更も混ぜると移動やリネームによってクラス名やファイル名な どの修正漏れかどうかがわかりづらくなる ※ファイルの移動やリネームする時に、コマンド実行で変更する場合もあるが、 クラス名の変更と同じコミットにする →1つの作業単位でコミットすることを意識する
1つの作業単位の例:TODOリスト • タスク単位でコミットする • コミットを見ただけで対応内容が想像つく
正常に動くタイミング • エラーが起きない状態でコミットする • エラーが起きる状態だと切り戻せない • アプリのコード修正とテストコードの修正がセットで1つのコミットになっ ていると動作が担保されているので尚良い
まとめ • 保守しやすさ、レビューしやすさもコミットの粒度次第で変わります • コミットする時は、紹介したポイント意識してみてください
参考 • https://qiita.com/jnchito/items/40e0c7d32fde352607be • https://www.codegrid.net/articles/git-tech-1 • https://qiita.com/chihiro/items/04482caebc702e75e84d