コミットするタイミングについて

コミットの粒度を適切にしようとする時のポイントをまとめてみました

Transcript

1. コミットするタイミングについて 宮田 勉
2. 注意事項 • あくまで一個人の考えです • 正解はありません • 私が普段考えていることの共有です
3. 今日の内容 • 導入 • コミットの粒度とは？ • コミットするタイミング
4. コミットとコミットログ • コミット ◦ 変更をバージョン管理ツールに保存されたもの • コミットログ ◦ コミットの集合体
5. コミットログで出来ること • 過去の変更を振り返れる • 問題があったら、1つ以上前の変更まで戻れる • 既にコミット済みの内容を後から修正できる • 複数のコミットを1つにまとめられる
6. 便利だが、何も考えずにコミットすると... • 1つのコミットの中で色々な変更が入って何をしたいのかがわからない • 1つ1つのコミットが細か過ぎて、繋がりがわからない • 不具合があってコミットを切り戻したいけど、不具合と関係ない所まで切り 戻されてしまう • 日常生活で例えると整理整頓せずに収納しているイメージ
7. 今日の話 • 整理整頓されていれば、探すときに時間かかからない • 保守しやすくなったり、レビューしやくなったりする、という話
8. コミットの粒度とは？ • コミットするときの変更の度合いや規模
9. コミットの粒度が大きすぎる • 切り戻ししづらい ◦ 一部にバグがあっても、コミットのリバートができない • 修正内容がわかりづらい ◦ 差分が大きくなると、情報量も増える ◦ 修正内容がわかりづらくなったり、見落としが発生しやすい 保守しづらく、レビューもしにくい！
10. コミットの粒度が小さすぎる • コミットが多くなる ◦ 1つ1つのコミットを見た時に、他のコミットとの繋がりがわかりづらい • 切り戻しの数が多くなる 細か過ぎても保守しづらく、レビューもしにくい！
11. コミットの粒度が適切であると • コミット単位で切り戻しがしやすい • コミット単位での差分が見やすくなる その結果 保守しやすく、レビューもしやすい！！
12. コミットするタイミング • 1つの作業単位 • 正常に動くタイミング
13. 1つの作業単位の例：コマンド実行 • コマンドやツール等によって自動的に作成や変更が加わる単位でコミット • 以下が区別できる ◦ 人による変更 ◦ コマンド実行による変更
14. コマンド実行と手動変更が混ざっている例 • コードのフォーマット修正（自動で修正）されたもの • statusがcompletedだったらメールを送らない
15. コマンド実行と手動変更を分けた例 人の手とそうでない変更が区別つきやすいので見やすい 片方の変更だけ切り戻すこともできる
16. 1つの作業単位の例：ファイル移動やリネーム • ファイルの移動やリネームといった機械的な変更のみでコミット • 上記以外の変更も混ぜると移動やリネームによってクラス名やファイル名な どの修正漏れかどうかがわかりづらくなる ※ファイルの移動やリネームする時に、コマンド実行で変更する場合もあるが、 クラス名の変更と同じコミットにする →1つの作業単位でコミットすることを意識する
17. 1つの作業単位の例：TODOリスト • タスク単位でコミットする • コミットを見ただけで対応内容が想像つく
18. 正常に動くタイミング • エラーが起きない状態でコミットする • エラーが起きる状態だと切り戻せない • アプリのコード修正とテストコードの修正がセットで1つのコミットになっ ていると動作が担保されているので尚良い
19. まとめ • 保守しやすさ、レビューしやすさもコミットの粒度次第で変わります • コミットする時は、紹介したポイント意識してみてください
20. 参考 • https://qiita.com/jnchito/items/40e0c7d32fde352607be • https://www.codegrid.net/articles/git-tech-1 • https://qiita.com/chihiro/items/04482caebc702e75e84d