2019 年更新：
如今，这个问题会在使用 Git 的环境中出现，并且已经使用了 10 年了分散式 https://stackoverflow.com/a/2563917/6309发展workflow https://stackoverflow.com/a/2705286/6309（主要合作通过 GitHub https://github.blog/2018-04-10-ten-years-of-code/) 显示了一般最佳实践：
-
master该分支是否已准备好随时部署到生产中：下一个版本，其中合并了一组选定的功能分支master.
-
dev（或集成分支，或'next') 是为下一版本选择的功能分支一起进行测试的分支
-
maintenance (or hot-fix) 分支是当前版本演变/错误修复的分支，可能合并回dev and or master https://stackoverflow.com/a/55077131/6309
那种工作流程（你不合并dev to master，但是您只将功能分支合并到dev，然后如果选择，则master，以便能够轻松删除尚未准备好下一个版本的功能分支）是在 Git 存储库本身中实现的，其中git 工作流程 https://stackoverflow.com/a/53405887/6309（一个词，此处图示 https://stackoverflow.com/a/44470240/6309).
更多信息请访问rocketraman/gitworkflow https://github.com/rocketraman/gitworkflow。这样做与基于主干的开发的历史记录在评论和讨论中亚当·迪米特鲁克 (Adam Dymitruk) 的这篇文章 http://dymitruk.com/blog/2012/02/05/branch-per-feature/.
(source: Gitworkflow: A Task-Oriented Primer https://github.com/rocketraman/gitworkflow/blob/master/docs/task-oriented-primer.adoc#topic-graduation-to-master)
注意：在分布式工作流程中，您可以随时提交并将一些 WIP（正在进行中的工作）推送到个人分支，不会出现任何问题：您将能够在将提交成为功能分支的一部分之前重新组织（git rebase）您的提交。
原始答案（2008年10月，10多年前）
这一切都取决于发布管理的顺序性质
首先，你行李箱里的东西都在吗真的是为了下一个版本？
您可能会发现当前开发的一些功能是：
- 太复杂，还需要完善
- 没有及时准备好
- 有趣，但不适用于下一个版本
在这种情况下，主干应包含所有当前的开发工作，但在下一个版本之前早期定义的发布分支可以充当合并分行其中仅合并适当的代码（针对下一个版本进行验证），然后在认证阶段进行修复，最后在投入生产时冻结。
当涉及到生产代码时，您还需要管理您的补丁分支，同时记住：
- 第一组补丁实际上可能在首次发布到生产之前开始（这意味着您知道您将进入生产，但会出现一些无法及时修复的错误，但您可以在单独的分支中启动针对这些错误的工作）
- 其他补丁分支将有机会从明确定义的生产标签开始
当涉及到 dev 分支时，你可以拥有一个 trunk，除非你需要进行其他开发工作在平行下 like:
- 大规模重构
- 测试新技术库，这可能会改变您在其他类中调用事物的方式
- 新发布周期的开始，需要纳入重要的架构更改。
现在，如果您的开发-发布周期非常连续，您可以按照其他答案的建议进行：一个主干和多个发布分支。这适用于小型项目，其中所有开发都肯定会进入下一个版本，并且可以冻结并作为可以进行补丁的发布分支的起点。这是名义上的过程，但一旦你有一个更复杂的项目......它就不再足够了。
回答 Ville M. 的评论：
- 请记住，开发分支并不意味着“每个开发人员一个分支”（这会引发“合并疯狂”，因为每个开发人员都必须合并其他人的工作才能查看/获取他们的工作），而是每个开发一个开发分支努力。
- 当这些工作需要合并回主干（或您定义的任何其他“主”或发布分支）时，这是开发人员的工作，not- 我再说一遍，不是 - SC 经理（他不知道如何解决任何冲突的合并）。项目负责人可以监督合并，这意味着确保它按时开始/完成。
- whoever you choose for actually doing the merge, the most important is:
- 拥有可以部署/测试合并结果的单元测试和/或组装环境。
- 已定义标签before合并的开始，以便在所述合并证明其本身太复杂或太长而无法解决时能够返回到之前的状态。
