Question

使用git flow。我们有一个不熟悉Git的同事昨天意外地合并了发展成师。

Develop有很多功能在我们的下一个版本中启动，需要恢复合并。这创建了一个撤消所有更改的提交。当我们将master合并回develop时，revert commit会删除我们的功能生成的代码。

在保留新功能的同时，能够将开发与主要修补程序同步的最佳方法是什么？

- 编辑 - 只是为了澄清，还原是还原。 I.E. git revert -m 1 <sha>，因为提交已经被推送到远程存储库。

自发布以来，我已经提出了一个可能的解决办法，即通过分支主人并恢复还原，但我很好奇是否还有其他可能会减少冲突的可能性。

Answer 1

选项1：硬重置和强制推送

如果可以对master分支执行非快进强制更新在您的上游存储库中，而不是还原develop的合并进入master，你可以简单地重置master：

# On master branch, do a hard reset back to the commit before the merge
git reset --hard <commit of master before the merge>

# Force push to upstream ONLY IF IT'S OK WITH OTHER DEVELOPERS
git push <remote> master --force

进行硬复位和强制推动的一个可能的缺点是，如果是其他的话开发人员已经完成了合并提交的工作（即已经完成了在它上面提交），然后他们需要重做同样的工作重置master的头部。这可能是也可能不是困难/昂贵的任务它们。

选项2：还原还原

我用快速测试回购测试了这个。我必须强调它 可能工作 ，我并非100％确信没有任何我没有的情况考虑。因此，请务必使用您的repo的备份克隆在本地进行测试第一。如果您选择在实际的回购中使用它，请自行完成风险。

此外，这可能不是最简单/最简单的解决方案。它的优势超过了然而，硬重置选项是它不会强迫开发人员重做在重置master分支之上工作。

好的，除了所有这些之外，你可以尝试做的一件事就是合并 master进入develop，然后将合并的恢复从develop恢复为 master，然后在您准备好时将develop合并到master。在命令中：

# Coworker accidentally merges develop into master before it's ready
git merge --no-ff develop

# You revert the merge in the master branch (this creates commit "ABCDEFG"
git revert -m 1 <sha of merge commit>

# You want to merge fixes from master into develop
git checkout develop
git merge --no-ff master

# But now all that work in develop is reverted, so revert the revert "ABCDEFG"
git revert ABCDEFG

# When you're ready to merge develop into master...
git checkout master
git merge --no-ff develop

这是我用来在测试仓库中测试它的一系列命令：

mkdir practice
cd practice/
git init

touch readme.txt
git add practice.txt
git commit -m "Add practice.txt"

git checkout -b develop

touch feature1.txt
git add feature1.txt
git commit -m "Add feature 1"

touch feature2.txt
git add feature2.txt
git commit -m "Add feature 2"

git checkout master

touch hotfix1.txt
git add hotfix1.txt
git commit -m "Fix issue 1"

git merge --no-ff develop

# Creates commit "ABCDEFG" that reverts the merge
git revert -m 1 head
git checkout develop
git merge --no-ff master
git revert ABCDEFG
git checkout master
git merge --no-ff develop

您可以在official Linux Kernel Git documentation for git revert：

了解有关“还原还原”技术的更多信息

-m parent-number

--mainline parent-number

通常你无法恢复合并，因为你不知道哪一方   合并应被视为主线。此选项指定父级   主线的编号（从1开始）并允许恢复反转   相对于指定的父级更改。

恢复合并提交声明您永远不会想要更改树   合并带来的。因此，以后的合并只会带来树   由不是以前的祖先的提交引入的更改   恢复合并。这可能是也可能不是你想要的。

有关详细信息，请参阅revert-a-faulty-merge How-To。

强烈建议您使用How to revert a faulty merge的链接完全想要了解这种技术是如何工作的，这并不难理解，它实际上有点有趣和迷人。

Answer 2

我的团队发生了类似的事情。我实际上已经有一个相对简单的解决方案，我只找到了这个帖子，因为我正在研究防止这种情况发生的方法（仍然没有解决方案）。

以下是我修复它的方法，假设子分支（“develop”）在与主程序“错误”合并（提交M2）之前更新（提交M1）：

问题状态

           ... <-- Work after revert that needs merged to develop
            |
            R  <-- Revert Bad Merge
            |
            A  <-- Commits after merge,
            |    /   but before revert 
           ... </    and needs merged to develop
            |
           M2  <-"bad" merge
  ... ____/ |
   | /      |
   M1       |
   | \____  |
  ...     \...
develop   master

第1步

# Get latest from both parent and child branches locally

git checkout master
git pull
git checkout develop
git pull


# Merge all code from before revert in master branch to develop
# (not necessary if "bad" merge into master was immediately reverted)

git merge A

在第1步之后说明：

           ... <-- Work after revert that needs merged to develop
   M3       |
   | \____  R  <-- Revert Bad Merge
   |      \ |
   |        A  <-- Commits after merge,
   |        |    /   but before revert
   |       ... </    and needs merged to develop
   |        |
   |       M2  <-"bad" merge
  ... ____/ |
   | /      |
   M1       |
   | \____  |
  ...     \...
develop   master

第2步 - 重要部分！

# Use "ours" strategy to merge revert commit to develop.
# This doesn't change any files in develop. 
# It simplly tells git that we've already accounted for that change.

git merge R -s ours

在第2步之后说明

   M4
   | \____  ... <-- Work after revert that needs merged to develop
   M3     \ |
   | \____  R  <-- Revert Bad Merge
   |      \ |
   |        A  <-- Commits after merge,
   |        |    /   but before revert
   |       ... </    and needs merged to develop
   |        |
   |       M2  <-"bad" merge
  ... ____/ |
   | /      |
   M1       |
   | \____  |
  ...     \...
develop   master

第3步

# Merge as normal, from the tip of master to develop.
# This should now be an "easy" merge, with only "real" conflicts.
#  (Those that have changed in both branches)
#
# Note: I've had issues using origin master to merge from latest on remote, 
#   so instead I just ensure I've pulled the latest from master locally and 
#   merge from there

git merge master

在第3步之后说明

   M5
   | \_____
   M4      \
   | \____  ... <-- Work after revert that needs merged to develop
   M3     \ |
   | \____  R  <-- Revert Bad Merge
   |      \ |
   |        A  <-- Commits after merge,
   |        |    /   but before revert
   |       ... </    and needs merged to develop
   |        |
   |       M2  <-"bad" merge
  ... ____/ |
   | /      |
   M1       |
   | \____  |
  ...     \...
develop   master

现在使用develop中的最新版本更新master，而无需解决重复或无意义的合并冲突。未来的合并也将表现得正常。

合并时避免在另一个Git分支中恢复提交的影响

2 个答案:

选项1：硬重置和强制推送

选项2：还原还原