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

Question

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

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

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

您可以随意组织您的答案,不按任务分组,但按照您认为相关的任何分组,但请通过VCS/DVCS进行组织(请不要混用它们).

谢谢.

Answer 1

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

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

1. 它往往会阻止提交,因为一旦提交了文件,它将立即影响具有相同配置的其他视图的工作区(即"在同一分支上工作").
   〜"发布"过程是一个活跃的过程,具有直接后果,
   〜"消费"部分(更新您的工作空间)是被动的(您必须在更新工作区时立即处理其他人发布的更改)
2. 它适用于线性 合并工作流程(即"仅从分支A合并到分支B,而不是在两个方向上混合合并" - A到B到A到B ......).合并是微不足道的,来自A的所有修改都简单地转移到B.

现在:

实现功能

任何VCS都会通过创建分支来实现这一点,但让我感到非常惊讶的是,"功能"分支并不容易:
*功能可能会变得太复杂
*它可能会及时准备好以便下一个版本
*只有部分功能可能需要合并回主开发分支
*它可能依赖于尚未完全完成的其他功能

所以你需要小心管理你的功能分支和你的提交:如果它们与同一个功能紧密相关,它会很顺利(你需要时将整个东西合并回主开发分支) .否则,使用这些工具不容易进行部分合并.

修复错误

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

代码审查

它最好与外部工具(例如Crucible)一起使用,并广泛使用诸如blame或annotations之类的VCS函数,以便在审核后更好地分配代码修复.

重构代码(后代码审查)

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

合并补丁

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

发布较新版本的应用

在发布应用程序时,VCS只会让你到目前为止,因为它不是一个发布管理工具.
您需要先确定要发布的版本(标签),但之后会出现部署过程,其中包括:

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

VCS和发布管理的关键是:

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

释放机制也会对二进制依赖性产生影响:

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

您还可以选择处于源依赖项(并获取您自己需要的其他内部项目的所有源),并且VCS很适合于此,但重新编译所有内容并不总是可行/实用.

Answer 2

与VCS 的DVCS(分布式版本控制)的主要区别在于,它(通过其分布式工作的本质)可以做一件事,一件事情:

合并.

因此,您可以从该角度查看您提到的任务.
分支机构仍将制作,但并非所有分支机构都能看到它们.其中很多实际上不会离开您的本地存储库.

作为DVCS对合并有两个主要影响:

1. 你可以随意提交多少次.其他人不会立即看到这些提交(即"他们不必在下次更新工作区后立即将它们合并")
   〜发布过程是被动的:您的推送可以被其他回购忽略.
   〜"消费"部分是一个活跃的部分:您可以检查在将其合并到您的分支之前已推送给您的内容,并确定您要合并的内容和来自谁(而不仅仅是因为您所有人都在进行"同一工作"科").
2. 它适用于任何合并工作流程(部分,纵横交错,递归,...)DAG(有向无环图)通常用于记录那些DVCS(至少Git和Mercurial)的历史记录,这使得很容易找到什么有已经合并,找到了共同的祖先.这是SVN与其DVCS同行之间的一个重要区别,但也有其他一些.

现在:

实现功能

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

修复错误

如果需要,您几乎可以为每个bug修复创建一个分支.我们的想法是确保通过在开发分支(或维护分支,如果发布)中合并的简单线性集合来识别错误修复.
我更喜欢确保首先在开发分支之上修改bug修复分支(以确保我的修复仍然符合可能已在所述主分支上并行完成的任何工作),然后将该dev分支与bug-fix one(快进合并:主分支现在引用所有修复)

代码审查

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

组织代码审查的DVCS方法是将新更改推送到特殊代码审查存储库,该存储库将:

• 如果他们不符合要求的质量标准,则拒绝这些提交
• 接受那些(将它们与代码审查仓库合并),并将它们推送到新的仓库(例如用于各种测试)

重构代码(后代码审查)

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

合并补丁

与上一节相同的过程.

发布新版本的应用程序(桌面,网络,移动设备,您会以不同的方式对待它们吗？)

实际的发布过程只是由您的软件的特殊标识(标记)版本启动.("发布管理过程"的其余部分,即部署和配置部分在CVCS答案中详细说明)
问题是,使用DVCS:
"软件的正式版本将来自哪个存储库？"

您需要建立一个"中央"或"正式"存储库,它将扮演以下角色:

• repo发布的版本
• 新仓库的回购想要贡献

因此,它既可以用于发布目的,也可以用于新的开发目的.