Git 非常大的树：我们的分支工作流有什么问题，如何修复？

我的团队已经开始在git下工作，工作流程接近GitFlow。 我们有几个限制：

• 我们需要一个拥有目前正在开发的所有功能的分支，为用户提供一个测试环境。我们称之为分支集成
• 我们需要一个分支，它只有用户验证的功能特性和通过Pull请求的每个技术特性，才能创建一个发布包。我们把那个分支叫做德夫
• 我们希望将我们的特性开发成分支，这些分支从evol开始，并从dev分支出来
• 我们希望每个功能分支都能从任何技术（无需用户验证）进步中受益：我们决定从evol分支中挑选技术提交到dev（进入技术分支，从dev中获得拉入请求到dev中）。然后，我们将dev合并到任何需要它的evol分支中

当一个特性准备好进行测试时，我们将其合并到集成中，让用户对其进行测试，如果有效，则将该特性分支合并到dev中

这意味着许多合并到集成，从许多不同版本的dev的功能分支，因此我们有这种树（左边是当前的集成分支）

团队规模为5名开发人员。我们通常同时存在许多特性分支，每个分支都需要很长时间才能完成和验证

因为Visual Studio Team Services（是否为Visual Studio Online）处理请求的方式（显示源分支与目标分支的任何差异，而不是模拟的合并真实结果）我们希望减少从dev获得最新技术进步的特性分支所引起的差异

我想方法是

将它们重新基址到dev上，而不是将dev合并到它们中，但这在合并到集成时显示了一个问题：合并一直指向旧的提交，而不是来自重新基址的新提交

我通过
git-rebase-p得到了我想要的结果，每次合并都是新的旧的
，但这似乎有点错误，尤其是当从特性到集成的合并已经超过了几个时


我做到了：

git-rebase-p--on


git-rebase-p--on


因为git删除了B之后的第一次合并，所以我甚至还得到了一棵外观更好的树

有没有办法：


指定一个重设基础的选项，以便使用该重设基础的分支的提交为源的合并使用新的合并更新
修复我们的工作流程，这样我们就不再有一个可怕的巨树，也不会有重新设置基础的问题（在重新设置基础之前，可能会以某种方式删除功能中的合并到集成）
看来我们可以使用
git merge--squash
创建一个集成提交，该提交承载来自源分支的差异，但没有指向该分支的父指针。这将允许我们轻松地在dev HEAD上重新设置evol分支的基础，而不会在集成合并中有冲突的指向旧提交的指针。

我将与我的团队讨论这一点，并在更新更多细节之前进行几天的试用

见下图：


在执行了
git-rebase dev
之后，我将evol-B重命名为evol-B-rebase，以便保留此视图，并且仍然能够在github上创建拉取请求。

集成时的提交是使用
git merge--squash--ff evol-[A | B]

这看起来比我们原来的树看起来好多了。我们应该确保只有挤压合并被允许进行集成，并且每个人都在挤压的提交消息中输入源分支的名称

唯一不完美的是拉请求仍然会显示所有特性的提交，而不仅仅是那些还没有被集成压扁的提交，但我想这是一个必要的缺点

下面是将evol-B-rebase合并回dev并清理旧的evol-B后的情况：



树枝甚至自己掉在自己的泳道上，这很好

对于长功能分支，在合并到集成时会产生巨大的拉入请求，我们只需为该功能的每个部分创建一个子分支，并将这些请求拉回到功能的主分支（就像sprint分支/sprint集成分支一样）