描述使用版本控制（VCS或DVCS）的工作stream程
我想在使用vcs或dvcs时学习其他人的工作stream程。
请描述您的策略来处理以下任务：
- 实现一个function
- 修复错误（在开发和部署应用程序过程中）
- 代码审查
- 重构代码（后代码审查）
- 整合补丁
- 发布你的应用程序的新版本（桌面，网页，手机，你会不同地对待他们？）
随意组织你的答案没有按任务分组，但按照你认为相关的任何分组，但请由VCS / DVCS组织（请不要混合它们）。
谢谢。
所有VCS在提到的各种任务中使用的主要function是分支 ：以协作方式隔离开发工作的能力。 由于它是一个中央VCS，一些开发人员可以在同一个分支上进行协作，对文件进行悲观或乐观的locking，以便开发并行历史logging。
但作为VCS对分支有两个主要的影响：
- 它往往会阻止提交，因为一旦提交了一个文件，就会立即影响其他视图的工作空间，具有相同的configuration（即“在同一个分支上工作”）。
〜“出版”过程是一个积极的过程，
〜“消耗”部分（更新你的工作空间）是被动的（你必须在更新工作空间时立即处理由其他人发布的更改） - 它适用于线性 合并工作stream程 （即“只从分支A合并到分支B，不在两个方向混合合并” – 从A到B到A到B …）。 合并是微不足道的，A的所有修改都被简单地转移到B上
现在：
实现一个function
任何VCS都可以通过创build一个分支来实现，但是让我大吃一惊的是一个“特性”分支并不容易：
*function可能会变得太复杂
*下一个版本可能会及时准备好
*只有一部分可能需要合并回主开发分支
*它可能取决于尚未完全完成的其他function
所以你需要小心处理你的特性分支和你的提交：如果它们与同一个特性紧密相关，那么它将会很顺利（当你需要的时候，你把整个事情合并回你的主要开发分支） 。 否则，这些工具不容易部分合并。
修复错误
在开发和发布后的错误修复之间的区别是，在前一种情况下，你可以经常在同一个分支中进行线性修改，就像在后一种情况下，你将不得不build立一个错误修复分支，并决定你会需要回到当前的开发分支。
代码审查
最好和外部工具（ 比如Crucible ）一起使用，并且广泛使用VCSfunction，如责备或注释，以便在审查后更好地分配代码修复。
重构代码（后代码审查）
如果重构较小，则可以在同一分支上进行。 但是如果它很大，需要设置一个特殊的分支，在开始重构之前完成unit testing。
整合补丁
与最后一点相同的评论。 如果补丁很大，需要创build一个分支。
发布您的应用的新版本
VCS在发布你的应用程序方面只会让你感到满意，因为它不是一个发布pipe理工具。
您将需要以前识别要发布的版本（标签），但是之后将涉及部署过程，其中包括：
- 停止正在运行的内容
- 复制新文件
- 部署它们（更新sql数据库，webapp，…）
- 实例化所有configuration文件（使用正确的值，地址，端口号，path等）
- 重新启动（如果您的系统由多个组件组成，请按照正确的顺序重新启动它们）
VCS和版本pipe理的关键是：
- 它们不太适合存储要发布的二进制文件，这意味着您需要它们来构build应用程序，而不是存储最终的可执行文件
- 在生产环境中（安全约束限制写入访问，以及在这些平台上运行的工具数量，本质上是监控和报告工具），并不总是受欢迎的。
发布机制对二进制依赖关系也有影响：
- 对于外部二进制依赖关系，您可能会使用像maven这样的机制来获取外部库的固定修订版本
- 但是对于内部的依赖关系，当你不是只开发一个应用程序，而是依赖于其他应用程序时，你需要知道如何引用其他应用程序产生的二进制文件（内部二进制依赖项），而且通常不会被存储在您的VCS中（特别是在开发阶段，您可以在其中为其他应用程序生成许多不同的版本以供使用）
您也可以select使用源代码依赖项（并获取您自己需要的其他内部项目的所有源代码），并且VCS可以很好地适应这种情况，但重新编译所有内容并不总是可行的。
与VCS的分布式版本控制（ DVCS ，Distributed Version Control）的主要区别在于，它是由分布式工作的性质决定的，
合并 。
所以你提到的任务可以从这个angular度来看待。
分支仍然会被创build，但并不是所有的分支都可以被其他开发者看到。 其中很多将不会真正离开您的本地存储库。
作为DVCS对合并有两个主要影响：
- 你可以随心所欲多次提交。 这些提交不会立即被其他人看到（即“下一次更新工作空间后不需要立即合并）”
出版过程是被动的：你的推动可以被其他回购忽略。
〜“消费”部分是一个积极的部分：你可以检查什么被推送给你之前合并到你的分支，并决定你想合并，从谁（而不仅仅是因为你都在一个“科”）。 - 它适用于任何合并工作stream程（部分，纵横交错，recursion，…）通常用于logging那些DVCS（至lessGit和Mercurial）的历史的DAG（定向非循环图 ）使得很容易find已经合并，find共同的祖先。 这是SVN和DVCS同行之间的一个重要区别 ，但也有其他一些 。
现在：
实现一个function
正如我在CVCS（中央VCS）答案中所详述的，“特征”分支背后的难点在于许多子特征将最终交织在一起。
这是DVCS将会发光的地方，因为它们允许你重新组织它们的本地（比如“尚未推送”）历史（Mercurial的变更集，SHA1提交或者Git），以便于部分合并或者子function分支的创build。
修复错误
如果你愿意的话，你几乎可以创build一个分支。 这个想法是确保一个错误修复是通过在开发分支（或者维护分支，如果这个被释放）合并回来的一个简单的线性集合来识别的。
我更喜欢确保首先在开发分支之上重新定位错误修复分支（以确保我的修复仍然符合在所述主分支上可能已经并行完成的任何工作），然后将该分支合并到错误修复一个（快进合并：主分支现在引用所有的修复）
代码审查
责备或注解function仍然有助于在代码审查期间分配任务，但这次所有开发人员不一定在一个站点上（因为它是* Distributed * VCS），而不是具有相同的识别scheme（例如不使用相同的LDAP）。
DVCS组织代码审查的方法是将新的更改推送到特殊的代码审查仓库，这将会：
- 如果不符合所要求的质量标准，则拒绝这些提交
- 接受这些（将它们与代码评论回购合并），并推送给一个新的回购（例如用于各种testing）
重构代码（后代码审查）
他们是在开发人员的本地回购，在一个分支（因为它很容易合并回来）
整合补丁
与上一节相同的过程。
发布你的应用程序的新版本（桌面，网页，手机，你会不同地对待他们？）
实际的发布过程仅仅是由一个特定的（标签）软件版本启动的。 （其余的“发布pipe理stream程”，即部署和configuration部分详见CVCS答案 ）
问题是，用DVCS：
“你的软件的正式版本从哪个版本库出来？”
你需要build立一个“中央”或者说“官方”的存储库，这个存储库将扮演以下angular色：
- 要发布的版本的回购
- 新仓库的回购想贡献
所以它既可以用于发布目的， 也可以用于新的开发目的。
