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

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

1. 它倾向于阻止提交，因为一旦提交了文件，它将立即影响具有相同配置的其他视图的工作区（即“在同一分支上工作”）。
   〜“发布”过程是一个主动的过程，具有立即后果，
   〜而“消费”部分（更新您的工作空间）是一个被动的过程（您被迫在工作空间更新时立即处理其他人发布的更改）
2. 它适用于线性 合并工作流（即“仅从分支A合并到分支B，不混合双向合并”-A到B到A到B …）。合并是微不足道的，所有来自A的修改都简单地转移到B
   现在：

实施功能

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

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

修复错误

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

代码审查

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

重构代码（审查后的代码）

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

合并补丁

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

发行新版本的应用程序

VCS并不是发行管理工具，所以仅在发布应用程序时能带您到此为止。
您将需要以前确定要发布的版本（标签），但是之后是涉及以下内容的部署过程：

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

VCS和版本管理的关键在于：

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

释放机制还对二进制依赖项有影响：

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

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

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

合并。

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

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

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

实施功能

正如我在CVCS（中央VCS）答案中所详述的那样，“功能”分支背后的困难在于许多子功能最终会交织在一起。
这就是DVCS的亮点，因为它们允许您重组其本地历史记录（如“尚未推送”）（Mercurial的变更集，SHA1 commits of Git），以便于部分合并或创建子功能分支。

修复错误
如果需要，几乎每个错误修复都可以创建一个分支。这样做的目的是确保通过合并到开发分支（或维护分支（如果已发布）中）中的一组简单线性命令来标识错误修复。
我更喜欢确保先将bug-fix分支重新置于development分支的基础上（以确保我的修订仍符合在所述main分支上并行完成的任何工作），然后再将该dev分支与错误修复之一（快速合并：现在，主分支引用了所有修复）

代码审查

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

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

• 如果他们没有按照要求的质量标准拒绝这些承诺
• 接受这些代码（将它们与代码审查存储库合并），并将其推送到新的存储库（例如，用于各种测试）

重构代码（审查后的代码）

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

合并补丁

与上一节相同的过程。

发布较新版本的应用程序（台式机，网络，移动设备，您是否会区别对待？）
实际的发布过程仅由软件的特殊识别（标记）版本启动。（“发布管理过程”的其余部分，即部署和配置部分在CVCS答案中进行了详细说明）
。问题是，使用DVCS：
“您的软件的正式版本将来自哪个存储库？”

您需要建立一个“中央”或“官方”存储库，该存储库将扮演以下角色：

• 回购要发布的版本

• 新仓库的回购想贡献
  因此，它既可以用于发布目的，也可以用于新开发目的。