version-control - さまざまなクラスにさまざまなコメントを付けてコードをチェックインするにはどうすればよいですか？

Question

複数の変更を実装しているが、一度に入力する準備ができている複数のファイルからコードをチェックインするためのベストプラクティスは何だと思いますか？

チェックを適度にアトミックに保ちながら、一度にすべてをチェックインし、変更を1つの長いコメントに入れますか？

適切なコメントが適切なファイルに関連付けられるように、ファイルをグループでチェックインしますか？

さまざまなファイルにさまざまなコメントを付けて一度にチェックインできるツールはありますか？

Answer 1

一度にチェックしてください。グループをチェックインすると、ビルドが中断されます。

ただし、変更が完了したらチェックインすることをお勧めします。

Answer 2

私はGitを使用しています。これにより、絡み合った作業コピーの問題を簡単に解決できます。どの変更が何に関連しているかを気にせずに作業を終えることができます。いくつかの作業を行った後、それぞれの論理変更を個別にコミットし、独自のコミットメッセージを表示します。

この方法は、小さな論理的な変更をまとめるのに最適です。を使用してファイルの履歴を振り返るとgit annotate、無関係な変更の全体を1回のコミットでカバーしなくても、各変更が行われた理由を簡単に確認できます。さらに、他の誰かが述べたように、コミットを小さくすると、後で気が変わった場合に以前の変更をロールバックするのが簡単になります。

Answer 3

それらが複数の変更間の依存関係でない限り、チェックインは小さくしてください。ビルドを壊したり、他の問題を引き起こしたりしない変更の最小のコレクションをチェックインします。

バグまたは小さな変更要求の場合、通常、バグ（または変更）ごとに1回のチェックインが最適に機能する傾向があります。これにより、特定の問題に対処するために更新されたファイルを簡単に識別できます。これは、変更をロールバックするだけでなく、将来同様の問題が発生した場合に問題を修正するためにどのような変更が行われたかを判断するのにも役立ちます。

大きな変更については、チェックインする作業の小さな単位に分割できる場合は、そうしてください。A-小さな間違いのために何かをロールバックする必要がある場合、すべての変更をロールバックする必要があるのは、単に気のめいることです。B-ハードドライブがクラッシュする-長時間何かに取り組んでいる場合、実装する変更が多く、チェックインせずに作業する時間が長くなるほど、作業と組織を投入するリスクが高くなります。

Answer 4

各チェックインは、特定のチケット番号やプロジェクトなどに関連するようにしています。

Answer 5

特に何かをロールバックしたい場合は、いくつかの理由から、チェックインをできるだけ小さくすることをお勧めします。このため、可能な限り最小の「意味のある」増分でコードをチェックインしてみてください（各チェックイン後にすべてがコンパイルされる限り）。