我们正在尝试将团队建设概念纳入团队。我不确切知道它的专业名称是什么，但是这种情况将是不言自明的我们想要实现的目标。我尝试在门户网站上搜索它，但找不到任何相关内容。
[当前，我们采用以下方法将功能从本地转移到主机。
这种方法的问题是，如果代码存在任何兼容性/合并问题，而这些问题在合并时被忽略，则最终会在构建或部署时产生问题；影响正在等待使用最新环境代码进行工作/测试的团队数量。
因此，我们希望使开发人员免于直接将其功能分支更改合并到master中，并提出了sprint集成分支的概念。通过集成分支，我们将构建该集成分支代码并将其部署到我们的团队服务器，并在那里进行所有测试。因此，所有合并问题或任何代码兼容性问题都将在团队构建级别解决，而不会影响环境。
总而言之，我对我们将要创建的功能分支有些困惑。
此模型正确还是我们遗漏了一些东西？
谢谢
据我了解，如果有的话，收益将是最小的……让我解释一下：
git中的分支不过是指向某些提交ID的命名指针，由您决定使用分支的策略。
因此，在sprint的开始，您在master上创建了一个指针（我从问题中了解到），该指针在sprint期间快速移动并且变化很大。集成分支从master重新获得基础，基本上看起来像master +在sprint期间开始和结束的功能（为清晰起见，我将其称为小功能）。
您描述的Feature分支取自master而不是Integration分支，好吧，请在冲刺开始时说。
冲刺结束了，功能已准备就绪，因此您尝试将其挑选到集成分支。在这一点上，樱桃选择将失败，因为集成分支既包含来自master分支的新提交（最初方法中的问题），又包含已合并到Integration分支中但尚未包含在master中的其他新功能-它们只能影响代码。
现在，功能的维护者无论如何都必须解决冲突-您在初始方法中遇到的同一组冲突+来自“小功能”的一组冲突]
[另一个担心是，如果这些小功能中的一个不能真正起作用，您将无法合并到主要功能中，而该大功能经测试证明可以正常工作。
基于这些想法，我提出一种替代方法：
如果您愿意，我将依靠以下“要求”：
我的方法是：
在要素开始处从母版中创建要素分支，假设母版未损坏。如果母版由于某种原因而损坏，请找到最后一次提交，使其可以与母版一起使用，并从那里创建功能分支。
当您处理要素时，请经常从master进行基准调整，并使要素分支保持“最新”。您执行得越频繁-发生碰撞的机会就越少。
当分支准备就绪时-再次从master重新设置基础，以保持最新状态，并推送到测试或随后合并的任何内容。假设您执行“ 2”，此步骤将很容易。
关于“ 2”的注释：Feature分支仅属于您（假定您仅在使用该功能），因此这些变基是无害的，只会影响您的本地提交。如果您需要将结果存储在远程存储库中，则每次执行基准库更改时，提交的SHA1-s都会更改。在这种情况下，您可以使用git push -f