チーム開発を行う上で、必ずと言っていいほど使用するGitだが、自分自身あまり意識できていなかったので、Git Commitに関するベストプラクティスを下記にまとめます。
- 1.Commit Often,but Not Too Often
- 2.Write Clear and Descriptive Messages
- 3.Use Branches Effectively
- 4.Review and Squash Commit
- 5.Automate Testing
- 6.Use Husky
1.Commit Often,but Not Too Often
コミットの頻度が多すぎても、少なすぎてもよくありません。バランスをとるように努めます。
各コミットは意味のある変更を表す必要があります。
無関係な変更を 1 つのコミットにプッシュしないでください。
2.Write Clear and Descriptive Messages
コミット メッセージでは、コミットの内容と変更を加えた理由を説明する必要があります。
コミットする内容に合わせて、タイプを使用します。
タイプ一覧：
feat ・・・ 新しい機能
fix ・・・ バグ修正
docs ・・・ ドキュメントのみの修正
style ・・・ コードに影響を与えない変更(空白、書式、コメントなど)
refactor ・・・ バグを修正したり機能を追加したりしないコード変更
perf ・・・ パフォーマンスを向上させるコード変更
test ・・・ 不足しているテストの追加
chore ・・・ ビルドプロセスや、ドキュメント生成などの補助ツールやライブラリのへんこう
3.Use Branches Effectively
新しい機能、バグ修正、実験には機能ブランチを使用します。
これらのブランチに対してプル リクエストを発行すると、プロジェクト マネージャーまたは管理者がコードを確認し、メインにマージします。
4.Review and Squash Commit
プロジェクトの所有者、リーダー、管理者、またはコードをレビューする人の場合は、ブランチをマージする前に、小さなコミットまたは修正コミットをレビューして論理的な単位にまとめます。
この方法により、コミット履歴が整理され、追跡しやすくなります。
5.Automate Testing
継続的インテグレーション ツールを使用して、コミットごとにコードを自動的にテストします。
これにより、変更が検証され、バグが発生するリスクが軽減されます。
6.Use Husky
husky のようなライブラリを使用すると、git スキルを向上させることができます。
husky で設定されたルールに違反している場合は、コミットが許可されません。
参考記事：
https://dev.to/sheraz4194/good-commit-vs-bad-commit-best-practices-for-git-1plc?ref=dailydev