我们使用长寿命分支PROD，TEST和DEV。
下一个应用程序版本是在DEV中开发的，它在准备好进行测试时合并到TEST中，并在发布后合并到PROD中。
有些提交是直接在TEST分支（对于正在测试的版本进行错误更正）和PROD（用于维护错误）中进行的。
PROD和TEST中的这些提交总是“合并”到子分支中（即：PROD在TEST和DEV中合并; TEST在DEV中合并）。
偶尔会在PROD中提交错误更正，然后在TEST和DEV中合并，然后推送到原点。但是，规划中存在一些变化，并且错误更正应该是TEST中版本的一部分，而不是PROD中的版本。
现在问题是：如果我在PROD中恢复提交，当PROD合并时，还将在TEST和DEV中完成恢复。如何在PROD合并之后继续删除PROD中的更改并将其保留在TEST和DEV中？
我目前所做的是来自TEST：
git merge PROD --no-commit
这允许我在TEST中提交合并之前丢弃PROD的恢复更改。然后从TEST到DEV进行合并，无需特殊干预。 如果从PROD合并的唯一提交是还原的提交，则会导致合并没有文件......但这似乎仍然有用。
所以我想知道我的方法是否正确或是否有更好的方法来做到这一点？
答案 0 :(得分：3)
通常，将生产分支合并回测试分支是个坏主意。通常应该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上的版本。）