フロントエンド - git rebase -i HEAD を使用した以前にコミットされたコードの変更について

Question

今日、私はそのような状況に遭遇しました。私は長い間それを勉強していましたが、何をすべきかわかりません。たとえば、今日はたくさんの関数を書きましたが、それらはすべてcommitでした。たとえば、commit の歴史は次のようになります。

commit message は、それぞれ「1、2、3、4」で、1 番目から 4 番目までを表します。提出物。
毎回同じファイル test.md を変更すると、4 回送信した後のファイルの内容は次のようになります。 リーリー

は、各投稿に 1 行追加されることを意味し、対応するコンテンツはこの投稿の

です。 commit messageその後、2 回目の提出に見落としがあり、修正する必要があることがわかりました。
を使用して git rebase -i HEAD~3 インタラクティブ ページに入るだけです。以下に示すように、2 番目の送信の前にある
を pick に変更して 2 番目の送信を変更します。 e
この時点で、
内の内容は次のようになります: test.md リーリー

次に、何かを追加する必要があります。たとえば、新しい行に

を書き、次に 5、git add . と 2 番目の git commit --amend が変更されます。次に commit を実行します。これは、3 回目の送信時に 3 行目の内容が git rebase --continue である必要があるためです。このとき、2 回目の送信を補足する必要があったため、3 行目に新しい内容を追加しました。そのため、競合が発生します。は確実に発生するため、3 を実行する前にこの競合を解決する必要があります。現時点でのファイルの内容は次のとおりです: git rebase --continue リーリー

しかし、紛争を解決できれば。 。その後、後続の

情報はすべて失われます。 。 commitその後、私が思いつく最も愚かな方法は、2 番目の
ポイントに戻って、すべてを再度修正することです。 。 commitしかし、3 回目と 4 回目の改訂が特に大きい場合は。 。それはもっと面倒です。
後続の
を失わずに 2 番目の commit を正常に変更するには、この競合をどのように解決すればよいでしょうか。 。 commit私の考えは間違っているかもしれません。 。何か良いアイデアはありますか？ 。私はひざまずいて皆さんに感謝します。 。

Answer 1

1. マージが完了したら、後続のコミットが失われることはありませんgit rebase --continue。

2. しかし、私は個人的にあなたのアプローチには同意しません。一般的に、途中でコミットを強制的に変更する必要はなく、新しいコミットを再送信するだけです。