考虑测试的团队git流

我们已经规划了一个git工作流，我们认为它可以很好地工作，但是遇到了问题

在SourceTree中 我们有4个主要分支机构

\u dev（我们从中创建功能分支，每个功能分支对应一个JIRA任务）

\u qa（一旦功能准备就绪并在\u dev上查看代码，我们将合并功能分支）

\u下一版本（当某项功能获得QA批准时，我们将该功能合并到该功能分支中）

master（当sprint结束时，我们将整个\u下一版本分支合并到该分支，从而仅合并批准的功能）

我们还有版本分支，在发布版本时，我们会将主分支合并到该分支（我们这样做是为了确保我们可以返回该分支，并在必要时进行调整，因为我们的产品是可安装的）

我们的问题是：

Dev1创建功能1（来自_dev的分支）

Dev1将feature1合并到_dev（假设此时它正在等待代码审查）

Dev1创建并开始使用feature2（再次从_dev分支）

Dev1将feature2合并到_dev中并通过代码审查

Dev1尝试将功能2合并到_qa

结果：功能1和功能2似乎都合并到QA中，尽管功能1还没有准备好

我们通过右键单击分支并选择“将featureX合并到当前分支”进行合并

请注意，我们有4个环境（应该）反映每个分支，因此QA有地方检查功能

为什么要将功能与我们不想合并的功能合并在一起

什么是通用工作流，它只允许将经过验证的功能合并到一个版本中，同时允许QA环境检查功能，并允许一个干净的历史记录来反映每个功能的生命周期-开发->质量保证->发布->版本

---

谢谢

首先，我要提醒你一句：如果你坚持这个工作流程，解决当前的问题，你将面临其他更微妙的问题。像这样的工作流，试图在开发生命周期的多个阶段返回到单个功能分支的合并，遇到了麻烦，因为它们忽略了不同分支上更改之间可能的交互

话虽如此，让我们关注一下你的一些问题。您的场景（带有插图）如下所示：

首先，您有

\u dev

和

\u qa

分支。（为了简单起见，我们暂时把其他的放在一边。）

Dev1将feature1合并到_dev（假设此时它正在等待代码审查）

在这种情况下，git将在

\u qa

和

特性2

之间找到一个合并基，即一个共同的祖先。那将是

B

。然后，它将“在

B

和

u qa

之间的更改”与“在

B

和

feature2

之间的更改”结合起来。同样，在

B

和

feature2

之间的更改包括

feature1

所做的更改，因为

feature2

是在

M1

（即，

feature1

之后的一个点被合并到中）

在所有情况下，要点都是一样的：在大多数情况下（包括合并期间），git不会将提交（或它们之间的增量）视为“属于”这个分支或那个分支。相反，它关心的是更改是否位于合并基础的路径上

git通常可以单独查看“来自分支”的更改的一种情况是

重新基址

。然而，您的工作流需要进行重大检修才能利用这一点，这将导致其他复杂情况。这不是我在此推荐的路径

另一种修补工作流的方法可能是要求开发人员在

\u dev

和

\u qa

之间的合并基础上启动新的功能分支，但这可能只会让问题迎刃而解（除非更改始终“保持有序”）“一旦他们达到

\u qa

，这不是一个合理的假设-尤其是如果qa发现缺陷）。此外，这增加了为一个功能完成的工作与为下一个功能完成的工作之间的隔离，最终意味着您可能要处理更多的合并冲突

无论如何，我认为这解决了你的为什么的问题。至于什么：

---

好吧，当您使用“git流”作为“分支和合并策略”的通用术语时，实际上，git flow是一种特定的分支和合并策略的名称。我建议您仔细阅读。您概述的需求并不是独一无二的，甚至不常见，因此，不要认为您必须自定义此流以满足这些需求，而是要研究人们如何使用此流满足这些需求。

首先，请注意：如果您坚持使用此工作流并解决您当前的问题，您将面临其他更微妙的问题。像这样的工作流，试图在开发生命周期的多个阶段返回到单个功能分支的合并，遇到了麻烦，因为它们忽略了不同分支上的更改之间可能的交互

话虽如此，让我们关注一下您的一些问题。您的场景（带有插图）如下所示：

首先，您有

\u dev

和

\u qa

分支（为了简单起见，我们暂时将其他分支放在一边）

Dev1将feature1合并到_dev（假设此时它正在等待代码审查）

在这种情况下，git将在

\u qa

和

特性2

之间找到一个合并基，即一个共同的祖先。这将是

B

。然后，它将“B和

之间的更改”与“B

和

特性2

之间的更改”结合起来。同样，在<

A -- B -- C <--(_dev)(_qa)

A -- B -- C <--(_dev)(_qa)
           \
            D -- E <--(feature1)

        (_qa)
          |
A -- B -- C ------ M1<--(_dev)
           \      /
            D -- E <--(feature1)

        (_qa)         F -- G <--(feature2)
          |          /
A -- B -- C ------ M1<--(_dev)
           \      /
            D -- E <--(feature1)

        (_qa)         F -- G <--(feature2)
          |          /      \
A -- B -- C ------ M1 ------ M2 <--(_dev)
           \      /
            D -- E <--(feature1)

       Q <--(_qa)     F -- G <--(feature2)
      /              /      \
A -- B -- C ------ M1 ------ M2 <--(_dev)
           \      /
            D -- E <--(feature1)