Question

我有像

这样的提交

Initial->FeatureX->B->C->D->FixBugInFeatureX->E->F->

现在我想做一次提交 FeatureX，FixBugInFeatureX

所以我试过

   git -rebase -i -<FeatureX>

然后我在文本文件中的FeatureX之后立即移动提交FixBugInFeatureX，并将其从pick更改为squash 如果没有冲突，这都有效。但它显示了一个新的分支，其中 ALL 重写提交初始 - > FeatureX-> B-> C-> D-> FixBugInFeatureX-＆gt; E-> F。我可以将这个分支合并到我的头部 - 但我仍然拥有所有先前的提交（其中FixBugInFeatureX现在第二次包含FeatureA。更多的是在提交B，C和D之间现在存在两次。

我想要的是像

这样的新提交树

Initial->FeatureX->B->C->D->E->F

我怎么能这样改变 - 或者我需要一个不同的命令？

Answer 1

您可以检查您的FeatureX和FixBugInFeatureX提交（然后您将处于分离头状态）并将它们提交到2个新分支

git checkout <FeatureX> 
git checkout -b featureX

git checkout <FixBugInFeatureX>
git checkout -b bugfix

然后将这些分支合并在一起，这样原始提交和修复

之间就不会有任何冲突

git merge featureX

然后你可以检查你的主人（或包含该链的分支）

git checkout master

并运行git rebase交互模式来重新绑定主分支和包含FeatureX固定版本的分支。

git rebase -i bugfix

只需将您想要的订单提交给提交，并且rebase将为您完成剩余的工作（您希望链接的顺序）

Answer 2

我找到了解决方案：

rebase --interactive完成这项工作，如果我将提交的哈希值传递给初始提交压缩：

git rebase  -i --no-autosquash "<hash of comitt BEFORE FeatureX>"

这将打开一个像

这样的文本文件

pick 07b952c some unrelated committ 
pick 6c46e25 FeatureX
pick b4bc625 B
pick f2fab98 C
pick dc6ba8b D
pick 5633408 FixBugInFeatureX
pick 077888f E
pick 0123445 F

# Rebase xxx..yyy onto zzz
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

我现在可以将此文件修改为

pick 07b952c some unrelated committ 
pick 6c46e25 FeatureX
squash 5633408 FixBugInFeatureX
pick b4bc625 B
pick f2fab98 C
pick dc6ba8b D
pick 077888f E
pick 0123445 F

git会将两个提交压缩在一起。之后会出现一个可编辑的文本文件，我可以编辑6c46e25的新提交消息，现在还包括5633408

如果在两次提交之间进行了合并或推/拉，这将无法令人满意地工作。这导致我至少在我的试验中有重复的历史。但除此之外它正是我想要的。没有重复的历史。显然，关键是在第一次提交编辑之前传递提交的哈希值。

Git：如何合并/重组不是直接后继者的2次提交

2 个答案: