分布式版本控制系统 Git 的分支漫谈

红薯
 红薯
发布于 2010年07月18日
收藏 0

Git是Linux之父 Linus Torvalds 编写的分布式版本控制系统。它最初是用来取代商业软件 BitKeeper 管理 Linux 内核开发的。与其他版本控制系统相比,Git 有很多优势,具体内容可以参照不久前我,chunzi以及其它几位译者翻译的「Pro Git」 http://github.danmarner.com/ 。

本文着重讨论 Git 的杀手锏:分支特性。

Git 储存版本历史的方式是为每一次 commit 时的整个目录储存一个快照。而一个 Git 分支实质上是一个可以在不同版本快照之间移动的指针。所以创建和储存分支在 Git 管理过程中是异常的轻便。

轻便的分支结构意味着开 发时更频繁的使用分支。而实际上 Git 社区正是使用分支最泛滥的。Git 鼓励用户创建分支:所有的代码最好都在分支里写成,最后合并到主干代码中。一个分支可以是一个实现思路的实验场所,或者一个修复补丁。分支存在的时间可以 很短,可能只包含一两次提交,而一旦合并到主干就被立刻删除。Git 的分支是给开发者享受用的,而不是...等等,也是为项目管理代码用的!

说 到这我们其实遇到了 Git 的分支哲学为人垢病的一面。传统上在类似Subversion 这样的集中式版本控制系统里,分支基本上有三种使命:1 同时维护不同版本;2,进行重大特性的开发;3,控制特定开发者的提交权限。无论是履行哪一种使命,传统分支一定是为了"长期"存在而建立的。这里的长期 当然是相对多数 Git 分支的寿命而言,即使某个分支停止使用了,一般也会转移到 attic 下面作为历史的一部分永久保存。

当 然,Git 的分支完全可以,并且在实践中也经常完成相同的任务。但是 Git 本身并没有对「协助开发的分支」和「用于管理的分支」这二者进行区分。这对于刚加入项目开发的新人理解版本控制的流程非常不利。

另一方 面,这个两种功能一种实现的设计也打破了个人 hack 和传统上分支中央集权的界限:当分支成了每天的家常便饭的时候,开发者的心理负担也少了,从而提高了他们为项目作贡献的积极性。这和 Git 植根于开源社区是紧密相联的。

所以 Git 没有解决这个问题,可以看作是一种缺失,也可以看作是一项特性。

怎样使 用分支归根结底是人的问题,人的问题再好的工具也没法彻底解决。当有人问 Django 的核心为什么 Django 还在使用 svn 而不是 Git 或者 hg 时,他们是这样回答的:"更换到其它的 VCS 不会为 Django 开发流程带来丝毫的改变,官方仓库还是那个唯一的仓库,提交权限仍将限制在核心成员手中,无论那是个git,svn 还是hg仓库。"DaNmarner 觉得这一席话是以上观点的最佳表述。

本文作者 DaNmarner, 原自其博客 http://blog.danmarner.com/
本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:分布式版本控制系统 Git 的分支漫谈
加载中
返回顶部
顶部