誤ってコミットに無関係な変更を含める

私のgitコミットへの個人的なアプローチは、すべてのコミットがその完全性に変更の単位を含める必要があるということです。

私が開発するとき、私は通常そのようなユニットに焦点を合わせます。しかし、時々、私の注意がどこか他の場所に迷子になり、しばらくの間別のユニットで作業します。これはおそらく最適ではありませんgit add --interactiveが、慎重にコミットすることを学びました（私の良い友達です）。

ただし、変更を選択的にステージングするのを忘れて、代わりにファイル全体をコミットする場合があります。diffに表示されるすべての変更は、実際には同じユニットに関連していると信じています。

それから私git push。

これは危険ですか？意図した変更のみが含まれるようにコミットを修正するよう努力する必要がありますか？私の主な懸念は、歴史を見る他の誰もが変更を目にし、おそらくそれが間違いであることに気付く前に数分間頭を掻くでしょう。さらに悪いことに、変更が関連しているように見え、プログラマーがエラーを認識しない可能性があることは想像できます。

問題は、すでにプッシュしているため、サーバーの履歴を安全に書き換えることができないため、おそらく最初にコミットを元に戻して、適切に分割して再度コミットする必要があるでしょう。または、コミットをより適切なコミットメッセージで修正することもできますが、履歴の書き換えも必要になるため、本当に高速でなければなりません。最後の手段として、私が取り組んでいるユニットを次のようにコミットするだけで、以前のコミットに関連する変更があることに注意してください（ただし、これは間違っていると感じています）。

適切なコードレビューワークフローを備えたマルチ開発者の設定では、これが発生しない可能性があることを理解しています。私がプロジェクトの唯一の開発者である場合、履歴を書き換えることがこれに対する最良の解決策であることも理解しています。

コミット履歴は非常に重要ですが、3つの理由があります。

1. 別の場所にマージします。ブランチからピースを取り出して他の場所に貼り付ける必要があります。必要なピースをすべてそこに置き、望まないものは何もないことが重要です。したがって、「乱雑な」コミットに、作業中の機能を対象とした変更が含まれている場合（そして、他の何かの偶発的なコミットではない）、それで問題ありません。
2. 後で何が起こったかを監査する-通常、特定のバグまたは機能がいつ導入されたかを特定します。この場合、関心のある変更を特定できれば、コミットの内容は関係ありません。
3. コードレビュー。適切なピアレビューがコミットされてからレビューされ（レビュー担当者を待つことでdev / commitプロセスを保留しないでください！）、これらの場合、レビュー担当者は変更内容を理解する必要があります。ただし、通常、レビュー担当者は全体的な変更の方に関心があります。3つのコミットすべてを一度にレビューするよりも、行われた、元に戻された、再作成されたコミットをレビューしようとすると、時間の浪費になります。

そのため、作業単位のコミットは理想的に聞こえますが、実際的には主張するものではありません。私はコミットを賢明に保つように努めていますが、作業単位はコミットを正常に保つための良い方法ですが、コミットを整頓するためだけにコミット履歴をいじろうとしないでください。これは、コードファイルを更新して、すべての角かっこを好みの方法で整列させるようなものです。

ここで、別のブランチを対象とした少しの作業をコミットした場合は、それを元に戻し、適切なブランチに適切にコミットします。これは重要ですが、GUIで作業しているときにサーバーコードを少し更新した場合は、心配する必要はありません。

これが発生した場合、次のコミットで変更を元に戻すことは大きな問題ではありません。適切なコミットメッセージ（Removing the XYZ that I accidentally added in C92A891）を追加すると、他の開発者がコードレビューで理解できるようになります。

特定のインシデントの修正について心配するのではなく、そもそも状況を回避するようにしてください。

これが本当の問題です：

ただし、変更を選択的にステージングするのを忘れて、代わりにファイル全体をコミットすることもあり得ます

ファイル全体をコミットしない（またはワークスペース全体を最悪の状態にしない）習慣を身に付ける必要があります。常に行ごと、または調査したHunk全体によってコミットしてください。

この方法でコミットする場合（ほとんどの場合はそうしているように思われます）、不注意による変更がコミットに潜入する可能性ははるかに低くなります。

コンピューター上にローカルリポジトリが1つあり、サーバー上の同僚と共有しているリポジトリが1つあるようです。ローカルコンピュータにリポジトリが1つしかないのはなぜですか。通常、少なくとも5つあるので、1つのリポジトリで1つのことに取り組んだり、不完全な状態にある可能性がある最初のリポジトリに触れたりせずに別のリポジトリのバグを修正したりできます。