あまりにも多くのオーバーヘッドなしでコーディングの進行を意味のあるコミットに分割する

修正または機能の作業をしているとき、数秒でその場で改善できる他の小さな問題に出くわすことがあります。すぐにそれらを行い、完成した機能/修正をコミットすると、コミットには複数のことが含まれます。たとえば"add feature X and code clean up"または"fix bug X and improved logging"。これを2つのコミットに分割することをお勧めします。同じファイルで2つの変更が発生した場合、1つのファイルを追加してコミットし、もう1つのファイルを追加してから再度コミットすることはできません。したがって、次の3つのオプションが表示されます。

1. 何かに取り組んでいる間、無関係なものを故意に見落とします。

2. 2つの変更を加えてファイルをコピーし、元に戻し、1つの変更を含めてコミットし、もう1つの変更を含めて再度コミットします。

3. 関係のない小さなことは変更せずに、todoリストに追加して後で実行します。

次の理由により、3つのオプションのすべてが本当に好きではありません。

1. 小さな問題を解決しないと、コードの品質が低下する可能性があります。そして、多くの努力をせずに何かを改善する機会を意識的に逃した場合、私は気分が悪いです。

2. これにより、手作業が増え、エラーが発生しやすくなります。

3. これはあまり手間がかからないTodoには問題ありませんが、ToDoリストに小さなアイテムを追加して後で再訪することは、すぐに修正するよりもはるかに時間がかかります。

そのような状況にどのように対処しますか？

プログラミングするときは、非常に実用的でなければならないと思います。完璧なスキーム、ワークフロー、または実装を策定することが可能であっても、作業を完了する必要がある場合があります。ここに私がやることがあります：

私はgitの機能を使用して、可能な限り個々のハンクと行をステージング/コミットし、無関係な変更を分離しますが、分離が適切に行われなかった場合、一時的な問題が発生することがあります。変更は隣接しているため、CIパイプラインの個々の変更をすべてテストするというポリシーがない限り、通常は大きな問題ではありません。

関連のない変更が大きすぎる場合は、todoリストに追加し、通常はその直後に実行します。時々、私がそれに戻ることができるまでに1、2日かかるかもしれません、それは私の現在の仕事と思考の列に依存します。良い解決策が準備できていない場合は、問題のコードの横に単にTODOを配置することがあります。

物事を分離することは実際的ではないことが起こります。私は元の作品とともに微調整をコミットします。

変更のサイズは、通常、移動するルートを選択する際の決定要因ですが、最終的には、臭いを残すよりも、ワークフロールールを無視するほうがはるかに重要です。

私のエディターには、ファイルの個々の部分のステージングを非常に簡単にするプラグインがあります。他のプログラマーエディターも同様のプラグインを持っていると思いますが、いつでも手動で行うことができますgit add --patch | -p。次に、git stashを使用して他の変更を保存し、小さなコミットを単独でテストします。その後、コミットした後、aを実行し、git stash pop中断したところから続行します。それがまさにこれらの機能が設計された理由です。

トリックは、変更に値するだけの労力をかける準備ができていない限り、変更を加えないことです。

私がしがちなのは、todoリストに追加することです（コードにコメントを追加したり、バグチケットのメモに追加したり、修正が最終的にマージされることを別のブランチでコードを更新したりすることがあります）。マイナーな品質問題のロールアップのバグチケットがない場合は、このために特別に上げます。そのため、私と他の誰もが、ブランチがマージされたときにそれらのコード変更の理由を知ることができます。コードの変更時に同僚が驚かないように、すべての変更をトレーサビリティとして取得します。

要するに-はい、コーディング時にそれらを見落とします。機能を追加する場合は、どんなに小さくても2つの機能を追加しようとしないでください。誰かがあなたのブランチを元に戻すことを決めた場合（あなたの機能はもはや必要ないので、たとえば）、あなたはあなたのミニバグ修正もすべて失います。同様に、正常に動作していた一部の重要なコードに小さな「修正」を加えたくありません。

私がかなり使用するオプションは、TODOコメントを追加してgit add --patchから、ファイルの関連部分を選択することで、頻繁に「部分的な」コミットを多数行うことです。次に、を使用git rebase --interactiveして、部分的なコミットを並べ替えて最終機能にマージし、プッシュする前にコミットを修正します。

これにより、メインコミットがクリーンに保たれ、発見した他の問題をすぐに修正できます。

git rebaseローカルコミットのみを書き換えているため、このコンテキストでは問題はありません。

別のオプションは、現在の変更を「git stash」することです。ワークフローは次のようになります。

1. 機能Aに関連する変更を開始します
2. バグBを発見し、すぐに修正することにしました
3. リポジトリのコマンドラインから実行しますgit stash （その後、コードは機能Aで作業を開始する前の状態に戻ります）
4. この時点で、機能Aのコミットされていない変更は「スタッシュ」に保存されます
5. バグBを修正するために必要なコード変更を行い、レポジトリにコミットします
6. コマンドラインから実行 git stash pop
7. 機能Aのコミットされていない変更が隠され、バグBの（既にコミットされた）修正とともに進行中のコードに復元されます。

バグ修正に関連する変更を個別にステージング（およびコミット）します。Git Extensionsでは、これは非常に簡単です。コマンドラインから、あなたがする必要があると思いますgit add -p。