让我们回到2005年,Bitkeeper,当时托管着Linux内核项目,在改变它关于价格的核心策略后引发了一系列的事情。在被Andrew Tridgell创建的免费Bitkeeper复制后,内核的协议变得令人痛苦——这在开源社区是一个重要的事情。Linus Torvalds不喜欢整件事的发展(至少说起来是这样),于是开始着手构建自己的分布式版本管理系统,即Git(英国称坏人的俚语)。
他对此有名的说法是:“我是个傲慢的混蛋,所以我以己之名命名我所有的项目。第一个是Linux,现在是Git。”Mercurial是另一个为了Linux内核而开发的值得关注的替代品,Matt Mackall以相似的目的开发。Git最终获得流行,3年后Bitbucket和Github诞生了。如果存在的话,我很乐意花钱来看下整个故事的文档。
但现在这段短暂的关于repo的历史已经过去了,我们还是深入挖掘下各个服务今天能给我提供什么样的服务,并分享下我们以往收集的使用buckets和octocats的经验。
Bitbucket和Github对于私人和公开项目采用了不同的方法。这是他们售价模型的核心,或者你可能会说是他们的处事哲学。我们将在下面更多的讨论这些不同。Bitbucket提供无限的免费私人仓库,而Github对此是收费的。在两家服务里,公开仓库是无限且免费的,并且不限制贡献者的数量。
结果:不,你在Bitbucket上可以得到免费的私人仓库,却在Github上为此付费。
GitHub在流行度上已经完爆Bitbucket,GitHub拥有超过4百万的用户数。不过Bitbucket也不算输,它依然提供了良好的使用体验,成为了Atlassian产品套件的一部分。GitHub和Bitbucket都有漂亮的前端,提供了问题单跟踪、wiki、简单易用的REST API以及rich GUI和各种操作系统上命令行工具(Windows/Mac/Linux甚至移动端)
你可能不服,GitHub已经遥遥领先了啊? 我想说的是,其实这只是个人口味的问题而已。 就特性维度而言,Gist是GitHub相对于Bitbucket的一个杀手锏,通过gist能够能够便捷地分享代码片段,并实现有效的版本管理。这个特性在Bitbucket是否要实现,一直是一个热议的问题,不过近期内看答案应该是不会。双向认证是另一个评价颇高的GitHub特性,Bitbucket也没有实现。但是请不要忘了,Bitbucket有spoon功能,GitHub上可没有哦。
结果:这只是个人口味的差异而已。
两家服务的一个很赞的特性是页面——托管简单的HTML页面,向那些不一定是开发者的用户展示项目。你也许会说这个特性对于开发者来说是个地狱,会花费掉一些有用的时间去玩2048和它们的复制品。。。
两家的这个特性基本上是一样的。你可以创建一个username.bitbucket.com或github.io,得到一个你自己的漂亮的URL。github.io URL正在变成大量开源库和项目的半义务性质的服务,一般会和相关的“Fork me onGithub”标语相配合。但要注意,如果你使用的是自定义域名,它可能会花费你一些珍贵的载入时间。
结论:相当棒的特性,两家服务都支持。
在Stackoverflow上随便瞟一眼最新的问题,你会发现每隔几分钟就会有关于GitHub的问题出现,然而关于Bitbucket的问题要一两个小时才能碰到。你能在Stackoverflow找到几乎所有你可能遇到问题的答案。 当然各自的主页上也有很多资源和在线社区的支持,但是很明显,GitHub是遥遥领先的。你统计一下最流行的开发库,无论是Java、Ruby还是JS,毫无疑问他们都是在GitHub上。更为重要的是,GitHub的开源本质也为他赢得了良好的声誉。
结论: GitHub, GitHub 还是GitHub.
虽然有点偏题,但是在讨论Bitbucket和GitHub时,这个问题确实绕不过的。Bitbucket是基于Mercurial实现,直到2011年才开始支持Git。与此相反,GitHub从一开始就是围绕着Git来构建。当然没有绝对正确的决策,实际上Git和Mercurial也非常相像,这里有详细的对比。权衡点在于,Mercurial更注重易用性,而Git更注重操控性。如果你是刚从cvs或者svn迁移到分布式版本管理系统的话,那你通常会发现Mercurial更容易用。
结论:Mercurial更好上手,而Git 提供了更为丰富的操控细节。
评论删除后,数据将无法恢复
评论(25)
引用来自“NicholasXu”的评论
osc 无法接收上传的 800MB 的大项目。引用来自“polly”的评论
这么大,当网盘用呢 :)引用来自“NicholasXu”的评论
osc 无法接收上传的 800MB 的大项目。主要是访问/提交速度上的……