rebase 功能分支 - 但提交 ID 已更改

rebase feature branch - but commit ids had changed

起点:

Dev: A -- B -- C
Feat:            \ -- D

然后将一些新的提交拉到 Dev:

Dev: A -- B -- C -- NEW
Feat:            \ -- D 

然后不小心导致 Dev 上的提交哈希发生变化*(并且 push--force 编辑) 大写和小写字母指的是相同的补丁 - 但提交哈希不同:

Dev: a -- b -- c -- NEW
Feat:  A -- B -- C -- D

现在我想从DevrebaseFeat,但是相同的补丁被识别为不同的提交,而rebaseA开始的 D

behavior: a -- b -- c -- NEW -- A -- B -- C -- D
expected: a -- b -- c -- NEW -- D (and recognize that A and a are actually the same)

请帮忙!!!

*也许你可以告诉我如何改回它们:我 运行 Dev 上的交互式 rebase 以便仅使用 r 选项更改提交消息。然后我意识到提交哈希值发生了变化,所以我 reset 返回 - 在使用 reflog 进行交互式变基之前。但是现在提交消息是旧的,但是提交哈希值仍然不同!!!

在这种情况下,您应该使用 cherry-pick 而不是 rebase

恢复对开发的更改(从你想重新设置基准的地方,新的更改)。

git reset --hard <last NEW changes commit>

通过本地开发分支与您的远程开发同步

现在cherry-pick 从功能分支提交并应用到开发

git cherry-pick <commit-ids from feat branch> //commit ids seprate with space

你是如何变基的,在哪个分支上用哪个命令变基?

你可以做的是,当你在 feat 分支上时,将你的功能分支重新设置为 dev

git rebase master

它应该按预期工作。

如果一切都坏了,你可以使用git reflog。它将向您显示本地存储库中发生的事件列表。复制你错误前事件的hash,然后运行

git reset --hard <reglog-sha>

它会在那个历史点重置一切

你可能会:

  1. 为您在分支 'feat'
  2. 中所做的新更改创建补丁
  3. 删除 'feat' 分支
  4. 从 'dev'
  5. 创建一个新的 'feat' 分支
  6. 在新的 'feat' 分支上应用第 1 步中的补丁
  7. 强制推送新的'feat'分支

现在,您现在 'feat' 分支更改 'dev'

例如,如果 'feat' 只有一个提交,下面的命令应该有效
(它也适用于 n 次提交。您需要在新分支上应用那么多补丁)

git checkout feat
git format-path HEAD~1
git branch -D feat
git checkout dev
git checkout -b feat
git am -3 patch-file-created-using-format-patch
git push -f origin feat