合并时排除恢复提交

我们使用长寿分支PROD，TEST和DEV。合并时排除恢复提交

下一个应用程序版本是在DEV中开发的，当它准备好测试时在TEST中合并，并在发布后合并到PROD中。

一些提交是直接在TEST分支（用于错误更正测试版本）和PROD（用于维护错误）中进行的。

PROD和TEST中的这些提交总是“合并到”子分支（即：在TEST和DEV中合并的PROD;在DEV中合并的TEST）。

有一段时间，错误更正在PROD中提交，然后在TEST和DEV中合并，然后推送到原点。但是，计划中有一些变化，错误更正应该是TEST版本的一部分，而不是PROD中的版本。

现在问题是：如果我在PROD中恢复提交，则在PROD合并后，还将在TEST和DEV中完成还原。如何在PROD合并后继续删除PROD中的更改并将其保留在TEST和DEV中？

我目前做的是，从TEST：

git merge PROD --no-commit

这允许合并处于测试提交之前我从PROD放弃恢复的变化。然后做一个从TEST到DEV的合并，不需要特别的干预。如果从PROD合并的唯一提交是已还原的提交，则会导致没有文件的合并...但这似乎仍然有效。

所以我想知道我的方法是正确的还是有更好的方法来做到这一点？

来源

2011-10-27 Guillaume Morin

通常，将生产分支合并回测试分支是个不错的主意。通常应该是git checkout PROD，然后是git merge TEST。（如果您想了解更多关于这个经验法则，这blog post on merging and branches给出了充分的理由。）

如果有人不小心犯PROD修复它的意思是在TEST，你应该是固定到大概摘樱桃TEST并在PROD上还原它。为了一步步地描述这个问题，我们假设PROD上的修复提交了对象名称A。然后：

# cherry-pick the commit onto `TEST`. 
git checkout TEST 
git cherry-pick A 

# Now revert the commit on `PROD`: 
git checkout PROD 
git revert A

现在，当您合并TEST到PROD，修复应该在合并（根据不同的历史，它可能会产生冲突，但即便如此，这应该是很容易支持的版本，以解决在TEST。）

来源

2011-10-27 13:32:20

对不起，但我不明白你的建议，将TEST合并到PROD中......这是相反的方法，我想保持TEST与PROD最新，直到TEST准备好发布（仅当时TEST在PROD中合并）。 –

看着你提到的博客文章，我不知道我得到了关于不将合并分支（父）合并到功能分支（子）中的完整理由。在我们的情况下，从哲学的角度来看，我们可以说每个子分支的目的是“添加功能xxx（到最新版本的父分支）”，而不是“添加功能xxx（到版本分支从）“。我们不介意不能将TEST合并到PROD的较旧代码库（例如：PROD中的TEST的最后合并），因为我们只有一个生产版本的应用程序，而不是任何客户特定版本。 –

从技术角度来看，我认为将父母合并为孩子比挑选樱桃更好......因为一旦孩子分支合并回父母身上，我的快速尝试与樱桃挑选导致许多冲突。 –

合并时排除恢复提交

回答

相关问题