据我所知，收益将是最小的……让我解释一下：

git中的分支不过是指向某些提交ID的命名指针，由您决定定义使用分支的策略。

因此，在sprint开始时，您会在master上创建一个指针（我从问题中可以理解），该指针在sprint期间快速移动并且变化很大。 集成分支从master重新获得基础，基本上看起来像master +在sprint期间开始和结束的功能（为清晰起见，我将其称为小功能）。

您描述的Feature分支取自master而不是Integration分支，好吧，请在sprint的开头说。

冲刺结束了，功能已经准备就绪，因此您尝试将其引入集成分支。在这一点上，樱桃选择将失败，因为集成分支既包含来自master分支的新提交（这是初始方法中的问题），又包含已合并到Integration分支中但尚未包含在master中的其他新功能-它们只能影响代码。

现在，功能的维护者无论如何都必须解决冲突-您在初始方法中遇到的同一组冲突+来自“小功能”的一组冲突

另一个问题是，如果这些小功能之一不能真正起作用，那么您将无法合并到已被测试证明可以正常工作的大功能中。

基于这些想法，让我提出一种替代方法：

如果您愿意，我将依靠以下“主张”：

1. Git不会“鼓励”长期存在的分支机构。
2. 功能分支还可以，但是功能分支的维护者应该将其更新。

我的方法是：

1. 在要素开始时从母版中创建一个要素分支，假设母版未损坏。如果母版由于某种原因损坏，请找到最后一个提交，使其可以与母版一起使用并从那里创建功能分支

2. 处理功能部件时，请经常从master进行基础调整，并使功能部件分支保持“最新”。您执行得越频繁-发生碰撞的机会就越少。

3. 分支准备就绪时-再次从master重新设置基础，使其处于最新状态，并推送至测试或随后合并的任何内容。假设您做的是“ 2”，这一步将很容易。

关于“ 2”的注释： Feature分支仅属于您（假定您仅在使用该功能），因此这些重新设置是无害的，并且只会影响您的本地提交。如果您需要将结果存储在远程存储库中，那么每次执行基准库更改时，提交的SHA1-s都会更改。在这种情况下，您可以使用git push -f