在之前的工作中，我发现通过让每个开发人员在他/她自己的分支上工作，更容易管理和保持稳定的预发布分支(或主要，取决于设置)。我们只有一个生产实例，所以不需要支持相同应用程序的多个版本。
这个"预发布"分支是这样命名的，因为有另一个分支(主分支)，我们从那里制作我们的阶段和生产版本。分支的设置使得只有来自预发布分支的代码可以合并到发布分支中。这些合并就是我们的代码审查检查点。CI构建也是从这个预发布分支中生成的，并且当工作主体的开发完成时，由每个开发人员从"预发布"合并到他们自己的分支，以迁移复杂的合并问题。
如果需要开发人员结对并共同完成给定的功能，除了他们自己的分支权限之外，没有什么可以阻止他们与其他人合作。这对于管理分布式团队非常有效，其中每个团队中的个人都在处理单独/多个特性。
在频繁的(每周1-2次)30分钟的状态更新会议的帮助下，我们作为一个团队，将决定在特定的QA版本中哪些应该进入QA，哪些不应该。
这个系统是有效的，但是当我搜索这个主题时，我发现很多对开发者分支的不满。人们似乎对git的本地存储库特性很感兴趣。然而，它们似乎只是解决同样问题的不同方式。没有考虑本地存储库解决的跨网络问题，例如签入延迟等。
主要有三个区别:
-
本地存储库的意思是:它是您系统的本地存储库，如果您发现自己被困在没有互联网连接的荒岛上，您仍然可以提交您的更改。Git最好的一点是，您不必连接到存储库就可以利用版本控制系统。开发人员有时在远程工作时无法访问主存储库，当您拥有像Subversion、Perforce或其他类型的集中式存储库版本控制系统这样的系统时，这通常会很混乱。使用Git和BitKeeper，您可以轻松地离线工作。
-
在开发人员分支的情况下，您通常是从集成分支分支到您的开发人员分支，并合并回集成分支。在Git中，你不需要合并，而是发送补丁，你不仅可以将你的更改发送到主存储库，还可以发送给其他开发人员，而无需先将补丁发送到主存储库。这允许开发人员在不接触主存储库的情况下一起工作。
-
在developer/integration分支设置中，developer分支位于存储库中，这意味着其他人可以看到它。在Git中，开发者的修改在开发者提交之前是不可用的。
像Git或Mercurial这样的DVCS引入了一个发布工作流(推/拉)，它与分支是正交的。
这意味着:
-
即使所有开发人员都在同一个分支上工作，他们也可以在自己的repo上"私下"这样做:只要他们不发布他们的工作(即推送到上游的repo)，那个公共分支实际上是他们自己的。他们可以定期拉(取+合并)，以避免与其他人在同一主题上的工作过多地分散，但他们会在准备好时推送。
-
开发人员甚至可能永远不会推送他/她的工作，但是集成商可以从上游"集成"存储库中获取集成商需要的尽可能多的分支(具有相同的名称):每个分支将存储在集成存储库中自己的命名空间(
dev1/branch,dev2/branch,dev3/branch，…)
从那里，集成商可以查看每个开发人员的分支正在引入的提交，并决定是否合并集成仓库中的这些更改。
注意:这在Mercurial中略有不同，因为命名分支在全局命名空间中有名称(参见Jakub Narębski对"Git和Mercurial -比较和对比"的回答，查看"个人意见:我个人认为"命名分支"…"部分)
所以git的"本地repo"可以转换开发者分支中的任何分支(这并不妨碍开发者在来自公共repo的分支之上创建自己的私有分支)。
这些分支可用于主动发布(由开发人员推送)或被动发布(从上游repo提取或获取，而无需上述开发人员的直接干预)
David W的回答(已投票)更清楚地表明:
- 从新分支中的分支工作(可以链接到开发人员，尽管我更喜欢链接到任务或任务集的分支，以便隔离开发工作:参见"何时应该分支")
- 从你自己的repo中克隆的分支中工作:你可以在相同的分支上工作，除非它是从上游repo克隆(副本)的分支。如果开发者的repo不能被集成商访问，那么是的，正如David所说，"在Git中，开发人员的更改在开发人员交付更改之前是不可用的。"如果开发人员的repo是可访问的(即使是通过简单的"本地协议"，如网络共享)，那么开发人员的更改可以从下游repo拉到集成的上游repo。
请参见"描述你使用版本控制(VCS或DVCS)的工作流程"，以另一种方式来对比集中式VCS使用分支的方式和分散式VCS使用存储库的方式。
如果它对你有效，那就太好了。我想你会发现用DVCS会更好，因为它们可以支持你现在做的一切，甚至更多。
本地存储库相对于开发人员分支的一个优点是，您可以在本地拥有任意多的分支。您可以快速启动一个分支来测试您感兴趣的内容。您可以启动一个分支来测试迁移到您喜欢的库的最新版本。所有这些都不需要用可能永远不应该看到的东西"污染"集中式服务器。