描述使用版本控制（VCS或DVCS）的工作流程。

#1 楼

VCS用于您要提到的各种任务的主要功能是分支：以协作方式隔离开发工作的能力。由于它是中央VCS，因此多个开发人员可以在同一个分支上进行协作，对文件进行悲观或乐观锁定，以开发并行历史记录。

但是，作为VCS对分支有两个主要影响：


它倾向于阻止提交，因为一旦提交了文件，它将立即影响具有相同配置的其他视图的工作区（即“在同一分支上工作”）。
〜“发布”过程是一个主动的过程，具有直接后果，
〜而“消费”部分（更新您的工作空间）是一个被动的过程（您被迫应对其他发布的更改）在工作空间更新后立即生效）
对于线性合并工作流非常有效（即“仅从分支A合并到分支B，而不在两个方向上混合合并”-A到B到A到B ...） 。合并是微不足道的，对A的所有修改都将简单地转移到B

现在：

实现功能

任何VCS都会这样做创建分支，但令我惊讶的是，“功能”分支并不容易：
*该功能可能变得太复杂了
*它可能为下一个版本的发布做好了准备
*它的仅一部分可能需要合并回到主开发分支中。
*它可能取决于尚未完全完成的其他功能

，因此您需要在管理功能分支和提交的方式：如果它们与同一个功能紧密相关，那么它将很好（您需要时将整个事情合并回主开发分支）。否则，使用这些工具进行部分合并将变得不容易。

修复错误

开发期间和发布后的错误修复之间的区别在于，在前一种情况下，您通常可以在同一个分支中线性地进行此操作，因为在后一种情况下，您将必须建立一个Bug-fix分支，并确定要解决的错误需要向后移植到当前的开发分支。

代码审查

最好与外部工具（例如Crucible）一起使用，并使用blame或广泛的批注，以便在审阅后更好地分配代码修复。

重构代码（后审代码）

如果重构较小，则可以在同一分支。但如果很大，则需要设置一个特殊的分支，并在开始进行重构之前进行单元测试。

合并补丁

与最后一点相同。如果补丁很大，则需要创建一个分支。

发布新版本的应用程序

VCS只能解决您的问题。发布它的应用程序，因为它不是发布管理工具。
您需要以前确定要发布的版本（标签），但是此后是涉及以下内容的部署过程：


停止当前正在运行的文件
复制新文件
对其进行部署（更新sql数据库，webapp等）
实例化所有配置文件（具有正确的值，地址，端口号，路径等）
重新启动（如果您的系统由多个组件组成，请以正确的顺序重新启动它们！）

VCS和发行版管理的关键是：


它们不太适合存储要发布的二进制文件，这意味着您需要它们来构建应用程序，而不是存储生成的可执行文件
它们并不总是受欢迎在生产环境中（安全约束限制了写访问权限，以及在那些平台上运行的工具的数量，本质上是监视和报告工具）

该释放机制还会影响二进制依赖性：


对于外部二进制依赖性，您可能会使用诸如maven之类的机制来获取外部库的固定修订版本，但对于内部依赖性，当您开发的不是一个应用程序而是几个相互依赖的应用程序时，您需要知道如何引用其他应用程序生成的二进制文件（内部二进制文件依赖项），并且它们通常不会存储在您的VCS中（特别是在开发阶段，在那里您可以为其他应用程序生成许多不同的版本以供使用。

您还可以选择成为源代码依赖项（并获取源代码的所有源代码）。其他您自己需要的内部项目），并且VCS很好地适应了这一点，但是重新编译所有内容并非总是可行/可行的。

#2 楼

与VCS的DVCS（分布式版本控制）的主要区别在于，（通过其分布式工作的本质）它可以做一件事情，一件事情做得很好：

合并。

因此您可以从那个角度查看提到的任务。
仍然可以创建分支，但并非所有其他开发者都可以看到。它们中的许多实际上并不会离开您的本地存储库。

成为DVCS对合并有两个主要影响：


您可以进行任意多次提交。这些提交不会立即被其他人看到（即“他们不必在下一次更新其工作空间后立即合并它们”）
〜发布过程是被动的：您的推送可以被其他存储库忽略。
〜“消费”部分是一个活跃的部分：您可以在合并到分支之前检查已推送给您的内容，并确定要合并的内容以及与谁合并（而不仅仅是因为您是所有人在同一个分支上工作。
对于任何合并工作流（部分，交叉，递归等）都适用。DAG（有向无环图）通常用于记录那些DVCS的历史记录（至少Git和Mercurial）可以轻松找到已合并的内容并找到共同的祖先。这是SVN与DVCS同类产品之间的重要区别，但还有其他区别。

现在：

实现功能

在我的CVCS（中央VCS）答案中有一个详细信息，“功能”分支背后的困难在于许多子功能最终会交织在一起。
DVCS会在这里大放异彩，因为它们将允许您重组其本地（ （如“尚未推送”）的历史记录（Mercurial，SHA1提交ofr Git的变更集），以便于部分合并或创建子功能分支。

修复错误

如果需要，几乎每个错误修复都可以创建一个分支。这样做的目的是确保通过在开发分支（或维护分支，如果已发布）中合并的简单线性命令组合来标识错误修复。
我更喜欢确保首先对错误进行重新定位，在将开发分支与bug修复分支合并之前（快速前进合并），将开发分支放在开发分支的顶部（以确保我的修复程序仍符合在所述主分支上并行完成的任何工作）。主分支现在引用了所有修复程序）

代码审查

责备或注释功能仍然可以帮助在代码审查期间分配任务，但这次，所有开发人员不必一定在一个站点上（因为它是一个* Distributed * VCS），并且不具有相同的标识方案（例如，不使用相同的LDAP）。

DVCS组织代码的方式审查是将新的更改推到特殊的代码审查仓库中，该仓库将：


如果这些提交未回答所需的问题，则拒绝这些提交质量标准
接受这些标准（将它们与代码审阅存储库合并），然后将它们推送到新的存储库（例如，用于各种测试）

重构代码（后期代码审阅）

它们是在开发人员的本地存储库中的一个分支上完成的（因为将其合并起来非常容易）

包含补丁

相同

发布新版本的应用程序（台式机，网络，移动设备，您是否会区别对待它们？）

实际发布过程仅由以下步骤启动：软件的特殊识别（标记）版本。 （“发布管理过程”的其余部分，即部署和配置部分，请参见CVCS答案）。
问题是，带有DVCS：
”该正式版将从哪个存储库您的软件来自哪里？“

您需要建立一个“中央”或“官方”存储库，该存储库将起到以下作用：


要发布的版本的仓库
要提供新仓库的仓库

因此它既可以用于发布目的，也可以用于新开发目的。