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

Question

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

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

• 实施功能
• 修复错误（在开发和部署应用程序期间）
• 代码审核
• 重构代码（代码审查后）
• 合并补丁
• 发布您应用的较新版本（桌面，网络，移动版，您会以不同方式对待它们吗？）

随意组织您的答案，不按任务分组，但按您认为相关的任何分组，但请通过VCS / DVCS进行组织（请不要混淆）。

谢谢。

Answer 1

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

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

1. 它倾向于阻止提交，因为一旦文件被提交，它将立即影响具有相同配置的其他视图的工作区（即“在同一分支上工作”）。
   〜“出版”过程是一个积极的过程，具有直接后果，
   〜“消费”部分（更新你的工作空间）是被动的（你不得不在更新工作区时立即处理其他人发布的更改）。
2. 适用于linear merge workflow（即“仅从分支A合并到分支B，而不是在两个方向上混合合并” - A到B到A到B ......）。合并是微不足道的，来自A的所有修改都简单地转移到B

现在：

实施功能

任何VCS都会通过制作分支来实现这一点，但让我感到非常惊讶的是，“功能”分支并不容易：
*该功能可能会变得太复杂 *它可能会在下次发布时及时准备好 *只有部分内容可能需要合并回主开发分支
*它可能取决于尚未完全完成的其他功能

因此，您需要注意管理功能分支和提交的方式：如果它们与同一功能紧密相关，则会很顺利（当您执行时，将整个功能合并到主开发分支中）需要它）。否则，使用这些工具不容易进行部分合并。

修复错误

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

代码审查

最好与外部工具（例如like Crucible）一起使用，并广泛使用blame或annotations等VCS函数，以便在审核后更好地分配代码修复。

重构代码（代码审查后）

如果重构是次要的，它可以在同一个分支中继续。但如果它很大，需要设置一个特殊的分支，在开始重构之前完成单元测试。

合并补丁

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

发布较新版本的应用

VCS只会在发布应用时为您提供帮助，因为它不是发布管理工具。
您需要先确定要发布的版本（标签），但之后会出现涉及以下内容的部署过程：

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

VCS和发布管理的关键是：

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

发布机制也会对二进制依赖性产生影响：

• 对于外部二进制依赖项，您可能会使用maven等机制来获取外部库的修复版本
• 但是对于内部依赖项，当你不是只开发一个应用程序而是依赖于另一个应用程序的几个应用程序时，你需要知道如何引用其他应用程序生成的二进制文件（内部二进制依赖项），它们通常会赢得'存储在您的VCS中（特别是在开发阶段，您可以为其他应用程序生成很多以供其他应用程序使用）。

您也可以选择在源依赖项中（并获取您自己需要的其他内部项目的所有源代码），并且VCS很适合于此，但重新编译所有内容并不总是可行/实用

Answer 2

来自VCS的 DVCS （分布式版本控制）的主要区别在于（通过其分布式工作的本质）做一件事，一件事情：

<强>合并

所以你可以从这个角度看待你提到的任务 分支机构仍将制作，但并非所有分支机构都能看到它们。其中很多实际上不会离开您的本地存储库。

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

1. 你可以根据需要多次提交。其他人不会立即看到这些提交（即“他们不必在下次更新工作区后立即将它们合并”） 〜publication process是被动的：你的推动可以被其他回购忽略 〜“消费”部分是一个活跃的部分：您可以检查在将其合并到您的分支之前已推送给您的内容，并确定您要合并的内容和来自谁（而不仅仅是因为您所有人都在进行“同一工作”分支“）。
2. 它适用于任何合并工作流程（部分，纵横交错，递归，......） DAG (Directed Acyclic Graph) 经常用于记录那些DVCS的历史记录（至少Git和Mercurial）可以很容易地找到已经合并的内容并找到共同的祖先。这是一个important difference between SVN and its DVCS counterparts，但有others as well。

现在：

实施功能

正如我在CVCS (Central VCS) answer中详述的那样，“功能”分支背后的困难在于许多子功能最终会交织在一起。
这是DVCS将发光的地方，因为它们将允许您重新组织其本地（如“未推送”）历史（Mercurial的变更集，Git的SHA1提交），以便促进部分合并或子功能分支创建。

修复错误

如果需要，您几乎可以为每个bug修复创建一个分支。我们的想法是确保通过在开发分支（或维护分支，如果已发布）中合并的简单线性提交集来识别错误修复。
我prefer making sure to first rebase开发分支顶部的bug修复分支（以确保我的修复程序仍然符合可能已在所述主分支上并行完成的任何工作），然后将该dev分支与bug混合-fix one（快进合并：主分支现在引用所有修复）

代码审查

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

组织代码审查的DVCS方法是将新更改推送到特殊代码审核仓库，其中包括：

• 如果他们没有回答所要求的质量标准，则拒绝这些提交
• 接受这些（将它们与代码审查仓库合并），并将它们推送到新的仓库（例如用于各种测试）

重构代码（代码审查后）

它们是在开发人员的本地仓库中，在一个分支中完成的（因为它很容易合并回来）

合并补丁

与上一节相同的过程。

发布您应用的新版本（桌面版，网络版，移动版，您会以不同方式对待它们吗？）

实际的发布过程只是由您的软件的特殊标识（标记）版本启动。 （“发布管理流程”的其余部分，即部署和配置部分详见CVCS answer）
问题是，DVCS：
“你的软件的官方版本来自哪个存储库？”

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

• 要发布的版本的回购
• repo for new repositories想要贡献

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