Git工作流涉及从主版本到发布版本的更改

我们的团队有以下工作流程。两个分支机构：

• master：提交和审查所有变更的地方
• 发布：这始终是生产中的内容（按下此按钮将触发部署）

开发人员在master上进行更改，对更改进行审查和测试，不时会有一个更改（不一定是最新的，也不一定是master上唯一的一个）获得批准，并发布以供部署

问题是，我们在主版本中验证了单个变更后，从一个主版本到另一个发布版本中挑选单个变更。这意味着我们在一个上下文中测试更改，验证它们，然后期望它们在另一个上下文中也能正常工作

---

此工作流/问题是否有名称？您将如何解决此问题？

就两个分支的上下文而言，如果两个分支的提交都是同步的，并且测试环境与生产环境类似，那么出现部署问题的可能性就非常小

但是，我觉得在公共共享的分支上采摘樱桃不是一个好方法

Cherry picking将更改您的提交id，即两个不同分支中的相同更改将有两个不同的提交id。这将影响将来对任何特定提交的搜索，因为没有链接到更改何时完成以及更改何时发布

恢复任何更改都将是一件痛苦的事情。由于相同的更改将有两个提交id，因此您必须首先在master中找到提交id，在release中找到另一个提交id，然后将两者都还原

更好的方法是遵循合并策略，即对主分支进行更改，然后合并到发布分支。在这个策略中，将添加一个额外的合并提交，并且您的发布分支，但是您的特性提交将具有与master中相同的id

这将提供完成提交和合并提交的历史记录，也有助于回溯到特定提交。您可以关联提交何时完成以及何时发布

恢复与恢复合并提交一样简单

---

使用这种方法的一个例子是。

关于cherry picking，您应该知道的一件事是它会更改您的提交SHA1 id，即对于同一个提交，主分支和发布分支上的id将不同。这就像两个分支的两个不同的历史。您是否正在为工作流考虑这一事实？当一个功能由多个提交组成时，您是否没有遇到问题？生产问题将很难解决并重新合并。我认为这不是一个好的解决方法。我认为您应该在手之前决定应该发布哪些更改，并相应地合并到另一个测试更改的分支。