在之前的工作中，通过让每个开发人员在他/她自己的分支上工作，我发现更容易管理并保持稳定的预发布分支（或主要，取决于设置）。我们只有一个生产实例，因此无需支持相同应用的多个版本。
这个“预发布”分支以这种方式命名，因为还有另一个分支（主要）我们将从中进行暂存和生产发布。设置分支使得只有来自预发布分支的代码才能合并到发布分支中。这些合并是我们的代码审查检查点。 CI构建也是从这个预发布分支构建的，并且每个开发人员都可以在完成该工作的开发时从“预发布”到他们自己的分支合并到迁移复杂的合并问题。 p>
如果开发人员需要配对并合作一个给定的功能，除了他们自己的分支机构权限之外什么都不能阻止他们与其他人合作。这对于管理分布式团队非常有效，每个团队中的个人都在处理单独/多个功能。
在频繁（每周1-2次）30分钟的状态更新会议的帮助下，我们作为一个团队，将决定将进入QA的内容以及针对该特定QA版本的内容。
这个系统有效，但在搜索这个主题时，我发现开发者分支机构有很多不满。关于git的本地存储库功能似乎有很多热情。然而，似乎它们只是解决同样问题的不同方式。不考虑本地存储库解决的跨网络问题，例如检查延迟等。
答案 0 :(得分：3)
主要有三个不同之处：
本地存储库意味着：它是您的系统的本地存储器，如果您发现自己被困在没有Internet连接的荒岛上，您仍然可以提交更改。关于Git最好的事情之一就是您不必连接到您的存储库就可以利用版本控制系统。开发人员有时无需访问主存储库即可远程工作，当您拥有 Subversion ， Perforce 或其他类型的集中存储库版本控制等系统时，通常会很麻烦系统。使用 Git 和 BitKeeper ，您可以轻松脱机工作。
在开发人员分支情况下，您通常会从集成分支分支到开发人员分支并合并回到集成分支。在Git中，您不合并，但发送补丁，您不仅可以将更改发送到主存储库，还可以将其更改发送给其他开发人员，而无需先将补丁发送到主存储库。这允许开发人员在不触及主存储库的情况下一起工作。
在开发人员/集成分支设置中，开发人员分支位于存储库中，这意味着其他人可以看到它。在Git中，开发人员的更改在开发人员发布更改之前不可用。
答案 1 :(得分：2)
像Git或Mercurial这样的DVCS引入了 orthogonal to branching 的发布工作流程（推/拉）。
这意味着：
即使所有开发人员都在同一个分支上工作，他们也可以在他们自己的回购中“私下”：只要他们不发布他们的工作（即推送到上游回购），这是常见的分支实际上是他们自己的。他们可以定期拉（获取+合并），以便在同一主题上不会与其他人的工作分歧过多，但是他们会在准备好时推动。
开发人员甚至可能永远不会推动他/她的工作，但是集成商可以从上游“集成”存储库中获取尽可能多的开发人员需要的开发人员回购的分支（具有相同名称）：每个分支将存储在其自己的命名空间中的集成存储库中dev1/branch，dev2/branch，dev3/branch，...）
从那里，集成商可以查看每个开发人员的分支机构正在引入的提交，并决定是否合并集成存储库中的这些更改。
注意：这在Mercurial中略有不同，因为命名分支在全局命名空间中有名称（请参阅Jakub Narębski对“Git and Mercurial - Compare and Contrast”的回答，查看“个人意见：我个人认为“命名分支”......“部分）
因此，git“local repo”会转换开发人员分支中的任何分支（这不会阻止开发人员在来自共同仓库的分支之上创建他/她自己的私有分支。） 这些分支可用于主动发布（由开发人员推送）或被动发布（从上游仓库中提取或提取，无需所述开发人员的直接干预）
另请参阅“Describe your workflow of using version control (VCS or DVCS)”，了解使用分支的集中式VCS方式与使用存储库的分散式VCS方式的对比方式。
答案 2 :(得分：0)
如果它适合你，那很好。我想你会发现DVCS可以更好地工作，因为它们可以支持你现在所做的一切以及更多。
本地存储库优于开发人员分支的一个优点是，您可以在本地拥有任意数量的分支。您可以启动一个快速分支来测试您感兴趣的内容。您可以启动分支以测试迁移到您喜欢的库的最新版本。所有这些都不需要用可能不应该看到光明的东西“污染”集中式服务器。