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

Question

我想在使用vcs或dvcs时学习其他人的工作流程。

请描述您处理以下任务的策略：

• 实施功能
• 修复错误（在开发和部署应用期间）
• 代码审查
• 重构代码（审查后的代码）
• 合并补丁
• 发布较新版本的应用程序（台式机，网络，移动设备，您是否会区别对待？）

随意组织您的答案，而不是按任务分组，而是按您认为相关的任何分组，但请按VCS / DVCS进行组织（请不要混合使用）。

谢谢。

Answer 1

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很好地适应了此要求，但是重新编译所有内容并不总是/可行。