通过git构建团队的分支模型

我们正试图将团队构建概念融入到团队中。我不知道它的专业名称到底是什么，但我们想要实现的目标是不言自明的。我尝试在门户网站上搜索，但找不到任何相关内容

目前，我们采用以下方法将功能从本地迁移到主功能

我们从主节点创建特征分支。 实现该功能，并将更改作为合并请求推送到主服务器。 这种方法的问题在于，如果在合并时忽略了代码的兼容性/合并问题，那么最终会在构建或部署时产生问题；影响等待使用/测试环境中最新代码的团队数量

因此，我们希望将开发人员从直接将其功能分支更改合并到master中隔离开来，并为sprint提出了集成分支的概念。使用集成分支，我们将构建集成分支代码并将其部署到我们的团队服务器上，并在那里进行所有测试。因此，合并的所有问题或任何代码兼容性问题都将在团队构建级别得到解决，而不会影响环境

总而言之，对于我们将要创建的特性分支，我有一些困惑

在sprint开始时，我从master创建并推进集成分支，在随后的几天中，我从master重新设置集成分支的基础。我们正在将此分支部署到我们的团队服务器。 在选择要工作的特性之后，我们从主特性创建特性分支，在那里实现特性，然后在特性完成时，选择提交给集成分支的特性。 在团队服务器上完成测试后，我们将从要在主服务器上合并的功能分支创建合并请求。 这个模型是正确的还是我们遗漏了什么

---

谢谢

据我所知，如果。。。让我解释一下：

git中的分支只不过是指向某个提交id的命名指针，由您定义使用分支的策略

因此，在sprint开始时，您在master上创建一个指针，我从问题中了解到，该指针在sprint过程中移动得很快，变化很大。 集成分支从master重新设置了基础，基本上看起来像一个master+特性，在sprint期间开始和结束。为了清晰起见，我将它们称为小特性

您描述的特性分支来自master，而不是integration分支，好吧，假设在sprint的开始

sprint结束了，特性已经准备好了，所以您可以尝试将其挑选到集成分支。此时，cherry pick将失败，因为集成分支包含来自主分支的新提交（这是初始方法中的问题）和其他已合并到集成分支但尚未在主分支中的新功能，它们只能影响代码

现在，该特性的维护者无论如何都必须解决冲突-与您在初始方法中遇到的冲突集相同+来自小特性的冲突集

另一个问题是，如果这些小特性中的一个不能真正工作，您将无法将测试证明可以正常工作的大特性合并到主特性中

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

如果您愿意，我将依赖以下声明：

Git不鼓励长寿分支。 功能分支是可以的，但是功能分支的维护者应该更新它。 我的做法是：

假设主控形状未损坏，则在特征开始处从主控形状创建特征分支。如果主节点由于某种原因而中断，请查找最后一次提交，以便能够使用主节点并从此处创建功能分支

处理要素时，请经常从主控形状重新设置基础，并使要素分支保持最新状态。你做得越频繁，碰撞的机会就越小

当分支准备就绪时，再次从主分支重新设置基址，使其成为最新的，并推送到测试或其他任何地方，然后合并。假设你做了2，这一步会很容易

注2：

---

功能分支只属于您，前提是您正在处理该功能，因此这些回扣是无害的，只会影响您的本地提交。如果您需要将结果存储在远程回购中，那么每次执行重基时，您的提交的SHA1-s都会更改。在这种情况下，您可以通过使用git push-f

标记来抑制原始分支，感谢您的详细解释，但是在第3点中，当您说push-to-tests时，您是指集成分支吗？哦，我的意思是提交准备好的分支以合并到master中。有时需要在分支上运行CI测试，以确认 nch有资格被推送到master