Python 高手编程系列七十：集中式还是分布式

暂时先忘了集中式版本控制系统。
说实话。集中式版本控制系统是过去的残遗物。在大多数人有机会远程全职工作的时
候，就会受到集中式 VCS 的所有缺陷的约束。例如，对于 CVS 或 SVN，你不能在离线时
跟踪更改。这是愚蠢的。当你的工作场所的 Internet 连接暂时中断或中央存仓库关闭时，你
应该怎么办？你应该忘记所有的工作流程，只是允许堆积更改，直到恢复正常，然后只是
把它作为一个非结构化的大对象的更新进行提交？这样不好！
此外，大多数集中式版本控制系统不能有效地处理分支方案。分支是一种非常有用的
技术，允许你限制项目中的合并冲突的数量，项目中可能有许多人在开发不同的特性。SVN
中的分支是如此荒谬，大多数开发人员尽量避免使用它。相反，大多数集中式 VCS 提供了
一些文件锁定原语，应该被视为任何版本控制系统的反模式。每个版本控制工具的悲哀的
真相是，如果它包含一个危险的选择，你的团队中的人最终将开始每天都会使用它。锁定
是一个这样的功能，用于减少合并冲突，但是它会大大降低整个团队的生产力。通过选择
一个版本控制系统，可以避免这样糟糕的工作流，你正在改善这种情况，这使得你的开发
人员更加高效的使用它。
尽可能使用 Git
Git 是目前最流行的分布式版本控制系统。在 Linux 核心开发人员需要放弃之前使用的
专有的 BitKeeper 的时候，Linus Torvalds 创建 Git，用于维护 Linux 内核版本。
如果你没有使用过任何版本控制系统，那么你应该从 Git 开始。如果你已经使用过一
些其他的版本控制工具，无论如何，都应该学习 Git。你绝对应该这样做，即使你的组织在不久的将来也不愿意切换到 Git，否则你有可能成为一个活化石。
我不是说 Git 是终极的和最好的 DVCS 版本控制系统。它肯定有一些缺点。最重要的
是，它不是一个易于使用的工具，对新来者来说是非常具有挑战性的。Git 的陡峭的学习曲
线已经是许多在线笑话的来源。可能有一些版本控制系统可以满足许多项目的需要，但是
开源的 Git 竞争者的完整列表更长。总之，Git 是目前最流行的 DVCS，所以网络效应真的
有利于它。
简而言之，正是由于其高人气（这是 VHS 击败 Betamax 的原因），网络效应导致使用
流行工具的整体好处大于使用其他一些，即使稍微更好的工具。你组织中的精通 Git 的人
员，以及新员工，集成这种 DVCS 的成本可能会低于尝试不太流行的东西。
总之，了解更多的东西总是好的，让自己熟悉其他 DVCS 并不会对你有任何害处。Git
最受欢迎的开源竞争对手是 Mercurial，Bazaar 和 Fossil。第一个是特别优雅的，因为它是
用 Python 编写的，是 CPython 源码的官方版本控制系统。有一些迹象表明，在不久的将来
它可能改变，在你读这本书的时候，CPython 开发人员可能已经在使用 Git 了。但它真的没
有关系。这两个系统是伟大的。如果没有 Git，或者它不受欢迎，我一定会推荐 Mercurial。
它的设计非常好。它绝对没有 Git 那么强大，但是对于初学者来说更容易掌握。
Git 工作流程与 GitHub 工作流程
非常流行并且标准化的使用 Git 的方法简称为 Git 工作流程（Git flow）。下面简要描述
该流程的主要规则。
● 有一个主要的工作分支，通常称为开发（develop）分支，在该分支上进行最新版
本的应用程序的所有开发。
● 新项目特性在独立的分支中实现，这些分支称为特性分支（feature branches），始
终从开发分支开始。当一个特性的工作完成并且代码测试通过时，这个分支被合并
回开发分支。
● 当开发分支中的代码稳定（没有已知的错误）并且需要新的应用程序发布时，创建
一个新的发布分支（release branch）。这个发布分支通常需要额外的测试（大量的
QA 测试，集成测试，等等），所以肯定会找到新的 bug。如果发布分支中包含其他
更改（如 bug 修复），则最终需要将它们合并回开发分支。
● 当发布分支（release branch）上的代码准备好被部署/发布时，它被合并到主分支
（master），并且主分支上的最新提交被标记上适当的版本标签。只有发布分支可以
合并到主分支。唯一的例外是需要立即部署或发布的热修复程序。
● 需要紧急发布的热修复程序始终在在单独分支上实现，这个分支是从主分支开始
的。修复完成后，它将合并到开发分支和主分支上。热修复分支的合并像普通发布分支一样完成，因此必须对其进行正确标记，并相应地修改应用程序的版本标
识符。
对于那些从未以这种方式工作，或者从未使
用过分布式版本控制系统的人来说，这可能有点难以理解。无论如何，如果你没有任何
正式的工作流，它是真的值得在你的组织中尝试。它有很多好处，也解决了实际的问题。
它对于开发很多独立特性并且需要提供多个发行版的持续支持的拥有多个程序员的团队
特别有用。
如果你希望使用持续部署过程来实现持续交付，这种方法也很方便，因为它在你的组
织中始终是明确的，哪个版本的代码代表你的应用程序或服务是可交付版本。它也是开源
项目的一个很好的工具，因为它为用户和主动贡献者提供了极大的透明度。
所以，如果你认为这个 Git 工作流的简短的小结有点作用，并且它没有吓到你，那么你应
该深入了解关于该主题的在线资源。真的很难说谁是前面工作流的原作者，但大多数在线资源
指向 Vincent Driessen。因此，了解 Git 工作流的最好的起始材料是他的在线文章，标题为一个
成功的 Git 分支模型（参考 http://nvie.com/posts/a-successful-git-branching-model/）。
像所有其他流行的方法，Git 工作流在互联网上得到了很多从不喜欢它的程序员批评。
Vincent Driessen 的文章评论最多的事情是这个规则（严格技术），说每个合并应该创建一个
新的人造的提交代表合并。Git 有一个选项进行快进合并，Vincent 不鼓励使用这个选项。
这当然是一个无法解决的问题，因为执行合并的最佳方式是 Git 用户的完全主观的事情。
总之，Git 工作流的真正问题是它明显的复杂。完整的规则是很长的，所以很容易犯一些错
误。你很可能想选择更简单的东西。
GitHub 使用这样一个工作流，Scott Chacon 在他的博客上对它进行了描述 （参考
http://scottchacon.com/2011/08/31/github-flow.html）。它被称为 GitHub 工作流（GitHub flow），
并且非常类似于 Git 工作流。
● 主分支中的任何内容都是可部署的。
● 新特性在单独的分支上实现。
与 Git 工作流的主要区别是它很简单。只有一个主要的开发分支（主分支），它总是稳
定的（与 Git 流中的开发分支相反）。没有发布分支，并且非常强调标记代码。GitHub 没有
这样的需要，因为，如他们所说，当一些东西被合并到主分支，它通常会被立即部署到生
产环境。图 8-6 显示了 GitHub 流的示例。
GitHub 工作流对于想要对项目进行持续部署过程的团队来说似乎是一个很好的并且
轻量级的工作流。当然，这样的工作流对于具有强的发布概念（具有严格的版本号）的任
何项目是不可行的——至少没有任何修改。重要的是要知道，主要的假设是主分支总是可
部署的，如果没有适当的自动化测试和构建过程，就无法保证主分支的质量。这是持续集
成系统所关注的，稍后我们将讨论。
注意，Git 工作流和 GitHub 工作流都不过是分支策略，所以尽管在名称中有 Git，但它
们不限于单个 DVCS 解决方案。这是真的，描述 Git 工作流的官方文章提到了应该在执行合
并时使用的特定 git 命令参数，但这个常规的想法可以很容易地应用于几乎任何其他分布式
版本控制系统。事实上，由于建议的处理合并的方式，Mercurial 似乎是一个更好的工具，用
于这个特定的分支策略！这同样适用于 GitHub 工作流。这是唯一的带有一些特定的开发文
化的分支策略，因此它可以在任何版本控制系统中使用，允许你轻松创建和合并代码的分支。
作为最后一个评论，请记住，没有一种方法论会永恒，也没有人强迫你使用它。它们
是为了解决一些存在的问题而创建的，并让你不会犯常见的错误。你可以采取它们所有的
规则或根据你自己的需求修改其中一些。新手通常容易陷入一些常见的陷阱，而它们是初学者很好的工具。如果你不熟悉任何版本控制系统，你应该以一个轻量级的方法开始，如
GitHub 工作流，没有任何自定义修改。只有当你获得足够的 Git 使用经验，或着你想选择
其他工具时，你才应该开始考虑更复杂的工作流程。总之，随着你越来熟练，你最终会意
识到，没有完美的工作流程能够适合每个项目。在一个组织中行之有效的工作流程，并不
一定适合其他组织。