チーム開発をより快適に！ チームでのコミット時の注意点とは
コミットハッシュの書き換え
今回紹介したcommit --amendやrebaseはコミットのハッシュを書き換えます。そのため、すでに他のメンバーに公開しているコミット（push済だったりレビュー依頼済みのコミット）に対して実行するのは基本的にはやめた方が良いです。
筆者の使い方としては、レビュー依頼を出すまではrebaseコマンドなどを利用してコミットを書き換えています。一度プルリクエストを作成してレビュー依頼をした後はrebaseコマンドのような履歴を書き換えるコミットは利用しません。これは補足となりますが、PCの不調に備えて業務終了時にはGitHubへコードをpushするようにしています。どうしても中途半端な状態でコミットとプッシュをすることもありますが、翌日以降にコミットを調整するようにしています。
rebaseなどの利用については各個人で意見が異なることもありますし、チームの開発の運用方法によって異なります。ぜひチームでも相談してみてください。
コミットの単位に絶対はない
コミットの単位については、チームや人それぞれです。今回はその中でも一案を紹介しました。コミットの作り方としても、細かくコミットを積んでいき、最後にrebaseコマンドを使って複数のコミットを合わせるという方法もあります。
そのほか、プルリクエストの単位＝レビューの単位を小さくする、という方法も取れます。プルリクエストの単位が小さくなればコードの修正量も減るため、コミットの単位も自然と適切な単位になりやすいと感じます。
また、コミットの単位を気にしすぎることによってミスをしてしまう可能性もあります。 rebaseコマンドの多用によって、合わせる必要がなかったコミットを合わせてしまったり、コミットを誤って消してしまったりというミスをすることもあります。筆者も経験しております。どんな単位であれ「コミットしてはいけない」というものではありません。完璧を目指すのでなく、「やりながら学んでいく」という心持ちで進めることをオススメします。
まとめ
今回は以下について説明させていただきました。
- Gitを使いこなすことはシステムの品質向上につながる
- 適切なコミットを行うことにより、レビューの品質向上につながる
- コミットに関連する便利なコマンドの紹介
第2回では、ブランチ戦略の説明などを交えた、開発やリリースプロセスの品質向上とGitについて説明していく予定です。
