Question

假设以下git历史记录（按时间顺序排列）：

master    [I]------------------------[M2]---[MG]---[RV]---[MG2]
dev         \---[D1]----------[D2]----------/              /
release            \---[R1]-------------------------------/

repo以初始提交I开始。
使用一个新提交D1创建开发分支。
发布分支使用新的提交R1从开发分支。
新的提交被添加到开发分支（D2）。
新的提交已添加到主分支（M2）。
dev合并为master（MG）
哦，哦！我们并不意味着这样做...我们将合并提交RV还原为-m 1，以指定主要应被视为主线
我们原本打算将发布合并到master中，所以我们现在就这样做（MG2）

哦不！现在，D1中引入的更改不存在于主数据库中。我希望他们被包括在内（但我不希望D2的更改存在）。所以我的问题是：

假设我刚刚将dev合并到master（MG），是否有一个命令可以代替git revert使用，这样当我合并释放到master {＆＃39}时; ll仍然有来自D1？
假设我已经完成了从dev到master和revert的合并，是否有一个命令我可以代替git merge使用，这样当我合并释放到master中时我就可以了。仍然会有D1？

我知道我可以通过在主分支上执行git reset --hard M2来实现此目的，但我希望尽可能避免重写历史记录。如果一个解决方案可以解释额外的“好”的可能性，那也会很棒。提交已添加到MG和RV之间或RV和MG2之间的主分支。

Answer 1

建议的解决方案here（搜索ADDENDUM）是重新创建D1（下面的D1'）的替代方案，以便以后的合并不会忽略其内容：

git checkout dev
git rebase --no-ff I

这应该导致：

dev         /---[D1']---------[D2']
master    [I]------------------------[M2]---[MG]---[RV]---[MG2]
            \---[D1]----------[D2]----------/              /
release            \---[R1]-------------------------------/

您还需要重新创建release分支，以便从D1'开始，然后将其合并到master：

git checkout release
git rebase D1' 
git checkout master
git merge release

结果：

release             /---[R1']---------------------------------\
dev         /---[D1']---------[D2']                            \
master    [I]------------------------[M2]---[MG]--[RV]--[MG2]--[MG3]
            \---[D1]----------[D2]----------/            /
                   \---[R1]-----------------------------/

当然，如果你没有推MG2，那么之前清理可能是个好主意。这种历史很容易让人们在将来迷惑。

Answer 2

我认为你可以使用git cherry-pick来解决你的错误＆gt; https://git-scm.com/docs/git-cherry-pick

恢复git合并，然后合并一些恢复的提交

2 个答案: