[解決済み] git rebase --fork-point master` とはどういう意味ですか？

質問

私のユースケースは 自分のコミットを変更する を公開する前に、コミットメッセージを書き換えたりいくつかのコミットを削除したりといったことができます。 コミットを新しい拠点に移動したくないのですが。

そのために、私はいつも次のようなことをしています。

git rebase -i HEAD~4

ここで、quot;4" という数字は、私の feature ブランチのコミットを手作業で数えた結果です。

Gitには、以下のようなコマンドはないのでしょうか？ "機能ブランチのすべてのコミットに対して対話式リベースを開始しますが、そのコミットをより新しい master - そのままでいいんです"。 . を発見しました。 --fork-point のオプションは git rebase で、これを試してみました。

git rebase -i --fork-point master

しかし、これには目立った効果はなく、以下のような挙動となります。 git rebase -i master .

代わりに、これは私が必要とすることを行います。

git rebase -i $(git merge-base --fork-point master)

のドキュメントを読みました。 --fork-point で git rebase のドキュメントを参照しましたが、なぜ私の期待する結果にならなかったのか、よく理解できません。どなたか説明していただけませんか？

どのように解決するのですか？

期待した結果にならなかったのは --fork-point は新しいコミットのベースを決定することとは関係ありません[1]。

そのため、デフォルトでは新しいコミットのベースは上流( master この場合)、そして --fork-point はその影響を受けません。

(参考までに、どのような --fork-point は、どのコミットを書き換えるべきかを推測する計算を改良するために reflog を使用しています。 これは常にというわけではありませんし、私の経験では しばしば - 非常に便利です)。

選択肢は2つ、マージベースを上流として使うか - おっしゃるとおり - あるいは --onto オプションを使用して、新しいベースを明示的に設定します (この場合、元のベースと一致するように設定します)。

[1] - 概念的にはコミットを編集していることになりますが、実際には rebase は常に新しいコミットを書き込んでいます - 何もしないときを除いて。 ですから、コミットを「編集」するときは、実際には古いコミットと同じような、しかし編集された新しいコミットを作成することになります。