Git功能分支从开发问题合并到暂存

目前，我们有以下工作流程：

我们基于

develope

分支创建要素分支（

develope

基于主分支）

我们使用base

develope

打开PRs，在代码审查后，我们合并到

develope

我们只希望将批准的功能分支移动到

暂存

分支旁边，这正是我们目前稳定的主分支

因此这里的问题是当我们将功能分支合并到

staging

时，整个

develope

历史也会合并（因为您知道功能分支基于

develope

）

因此，问题是我们如何将功能分支合并到

暂存

，而不将整个

开发

历史记录纳入其中

此外，如果我们根据

master

建立功能分支，我认为在合并开发时可能会产生冲突（例如，如果两个功能分支对相同的文件和行进行提交）

如果我错了，请纠正我最后一点

---

注意：以下工作流的原因是我们希望遵循Gitflow，但develop的发布分支使我们的部署等待develop稳定后才能发布，因此我们希望通过将准备好的功能添加到发布分支（staging）来简化这一过程.

您可以

选择
并只选择要包含的相关提交。为什么你要把所有东西都合并到
开发
中，而不仅仅是批准的功能分支？是的，我想的是
cherry pick
，我对此没有信心，不，我们只合并批准的功能分支来开发，但
批准的
这里指的是未经测试的代码审查，因此，我们在
develope
server中进行测试，然后我们只想将准备好的（测试过的）功能移动到登台服务器（这是某种程度上的预生产或预发布环境），我们在其中再次测试。我希望这能澄清这种工作流的目的。@Maroun因此，如果我选择了从功能分支到发布分支（
staging
）的所有提交，那么我将其合并到
master
（这将导致一些重复的内容提交，这些提交将具有不同的提交哈希）。然后，如果我将
master
合并到开发中，重复就会出现，我认为如果我将
develope
重新设置为
master
，这可以解决，对吗？@Maroun我们有一个非常类似的过程。虽然我并不完全反对通过挑选来获得批准的工作，但这将是一件复杂的事情，因为有10多名开发人员必须对其进行管理。是否有任何合理的方法通过拉取请求来管理此问题？我认为最好的解决方案是从
staging
创建所有分支，然后最初将它们合并到
develope
，然后在批准后再合并到
staging
。然而，这在
develope
分支中产生了问题，不相关的分支可以有效地回滚最近合并的工作，因为它在
staging
中还不存在。思想？