その大規模なコミット内で発生したすべての変更を十分に理解していない限り、これはかなり退屈な作業になる可能性があります。
通常、非常に大きな (悪い大きな) コミットには、さまざまな変更が含まれます。あなたがする必要があるのは、これらすべての変更を概念的に分離し、異なるコミットを書き直すことです。
次の 4 つの基準に従って変更を分類することをお勧めします。
[NEW] 単独で特定された技術レベルの機能に関連するすべてのコードを含みます (複数の技術レベルの機能を含む可能性のあるユーザー レベルとは対照的に)
[RFG] 行動不変条件の変更。実行された動作と API (インターフェース) を保持
[CHG] 仕様/要件の変更を表すあらゆるものの実装
[FIX] コーディングの背後にある意図に準拠するように動作を変更する可能性のある変更。
次に、git-wise で行う必要があるのは次のとおりです。
git checkout <bad commit SHA1> -b CULPRIT
これにより、「CULPRIT」ブランチが作成されます。次の手順の多くの退屈な繰り返しを実行する必要がある場合があるため、これを常に参照として保持します. 補足として、途中で部分参照を保持しておくと役立ちます(ブランチまたはタグとして)。
git reset HEAD^ --mixed
これにより、コミットからのすべての変更がステージングされていない変更のパッチとして前のコミットに適用されたかのように、コミットが取り消されます。次に、
git add --patch
これらの変更のサブセットを変更できます。[s]plit オプションを使用して、行ごとに変更を個別に選択することを躊躇しないでください。場合によっては、必要な変更を手動で選択するエディションを避けられないことがあります。そして、上記で提案した NEW、RFG、CHG、FIX スキームで分割された複数のコミットとして再ステージングし、必要な数のコミットを書き直します。
次の点に注意してください。
- コンパイルされない新しいコミットのステージング
- 「些細な」実行時エラー (たとえば、segfault など) を生成する新しいコミットのステージング
- 物事を機能させるために組み合わせる必要があるサブコミット
...目標はバイセクトを機能させることだからです。さらに、新しいコミットが git diff によって古いコミットと同じであることを確認し、新しい HEAD コミットが CULPRIT に対して行われ、それ以上の変更が導入されていないことを確認します。
これは最初は苦痛であり、多くの練習が必要ですが、これが十分にできるようになると、チーム全体が崇拝するデバッグの神になり、小さなコミットの福音を NEW の形で広めることができます。 CHG、RFG、FIX。