重设分支时要采取的步骤，该分支是从主分支分支出来的分支

如何解决重设分支时要采取的步骤，该分支是从主分支分支出来的分支

我不断收到噩梦般的变基，我认为这是因为我采取了错误的步骤。

我有 3 个分支 ... mainbranch,branch1,branch2 ... branch1 是 mainbranch 的一个分支 ... branch2 是 branch1 的一个分支

branch1 比 mainbranch 提前 1 次提交 branch2 比 branch1 早 1 次提交

所以在这种状态下，当我... git fetch -p; 时我遇到了问题。 git pull -r ... 在主分支上我现在想将 mainbranch 上的新更改引入 branch1 和 branch2。这就是我目前正在做的：

git checkout mainbranch
git fetch -p
git pull -r
git checkout branch1
git rebase -i mainbranch (i dont squash commits or anything like that)
git checkout branch2
git rebase -i branch1 <<< this causes the problem

当我运行最后一个命令时，我有一个冲突的噩梦。我假设是因为不知何故，当我在上面的步骤中进行第一个 rebase 时，它弄乱了提交哈希并混淆了 git。我应该采取哪些步骤来正确执行此操作？谢谢

这里的目标是最终处于初始状态（分支 1 彼此提前提交），但所有分支中的主分支的所有更改

解决方法

pull -r 对来自您的 mainbranch 的新提交进行 rebase，因此它们确实获得了新的哈希值，这使得 git 以不同的方式识别它们。我不确定有多少文本更改会影响这种行为（我猜他们做的最多），但这（仅？）在修改相同文件的 rebase 提交时可能发生。您需要做的只是告诉 git 使用它们的 single 提交重新设置 branch1 和 branch2 分支（我假设您的问题很清楚），因为 git 没有自行跟踪它们。

git checkout mainbranch
git fetch -p
git pull --rebase

# rebase branch 1
git rebase --onto mainbranch branch1~1 branch1

# rebase branch 2
git rebase --onto branch1 branch2~1 branch2

注意 rebase 命令告诉 git 根据这些规则开始 rebase：

--onto <base> 告诉 git 从哪里开始构建新的提交到（--onto mainbranch 然后是 --onto branch1）
<upstream>~1 告诉 git 要应用的补丁的范围/数量（字面意思是一个）
<downstream> 告诉 git 分支名称要变基

所以，它类似于“git 请将分支 branch1 重新绑定到当前的 mainbranch，请仅提供一个 (~1) 补丁”，然后对于 branch1-branch2 也是如此变基。

在使用交互式 rebase 时可能更容易追踪它发生的原因（至少你可以看到是什么原因造成的）：

git checkout mainbranch
git fetch -p
git pull --rebase

# rebase branch 1
git checkout branch1
git rebase -i mainbranch
# note that the editor opens with more than one command: two or more picks (depends on the number of commits on main branch)
# simply remove all commands except the last `pick` command that picks the only commit from the branch1 branch

# rebase branch 2
git checkout branch2
git rebase -i branch1
# the same here: note that this will also include the original commit from branch1 that should be dropped too
# keep the last `pick` command only

一旦完成，在两种情况下（您决定您更喜欢哪个），git log --oneline 会产生如下结果：

CCCCCC (branch2) the only commit from branch2
BBBBBB (branch1) the only commit from branch1
AAAAAA (mainbranch) the tip commit at mainbranch
...

如果您熟悉那里发生的事情并且您对执行变基感到安全并了解可能会出错，那么您甚至可以执行以下操作：

git checkout mainbranch
git fetch -p
git pull --rebase

# rebase branch 1
git rebase master
git rebase --skip # assuming conflicts will occur here
                  # and this is equivalent to dropping the current patch from the interactive rebase (scenario 2 above)
                  # or excluding the commit from the commit range (scenario 1 above)
# possibly more `git rebase --skip` (unless the only patch is applied)

# rebase branch 2
git rebase branch1
git rebase --skip # one time than the previous rebase because of the old "branch1 commit on branch2" commit

我更喜欢最后一个，因为我可以在我的 bash 提示中看到它（要应用的补丁数量、完成变基后的前进/后退等），但我总是使用 git log 仔细检查结果在强制推动之前。