正在学习GIT和gitHub的使用，了解到一些git历史，这里来八卦一下Bitkeeper做错了什么 ？ 话说当年大神林纳斯在带着一帮哥们做Linux的时候，这么多高人分布在世界各地，而且这些高人水平也参差不齐， 提交的代码不能随便就加到master吖，这就需要版本控制，当时做的好是BitKeeper,不过BitKeeper不开源， 是收费的，出于友情敬仰或是名声什么，bitkeeper老板说我免费给你用，但是别给我破解了，哥们还需要赚钱给你侄子买奶粉呢， 但是程序员是什么人种，求知探索精神爆棚的人类， 必须破解了吖，结果BitKepp不干了，收回免费，开始收费，然后大神林纳斯就两周写出了Git, 然后BitKeeper就淹没在历史的尘埃里。。。

这里粘贴一点 原文链接http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot Why Bitkeeper Isn't Right For Free Softwareby Greg Hudson-------------------------------------------Much has been written about the use of Bitkeeper in free software,particularly in relation to the Linux kernel.  Most of the discussionhas focused on the restrictive licensing terms of the free-beerversion (no source, can't be used by Bitmover competitors, terminationclauses).  But licensing-related arguments against Bitkeeper aren'tvery compelling because non-Bitkeeper users haven't been penalized: aslong as Bitkeeper use isn't required for Linux kernel development, thefree software world is hardly "in crisis" as some have argued, anymore than it would be if many Linux developers preferred to use fancyproprietary text editors.  (However, this article does assume that youhave a certain level of background distaste for proprietary software,and would only adopt Bitkeeper if you believe you really need it.)There is another reason why Bitkeeper is wrong for the free softwareworld: it targets the wrong development model.  From the beginning,Bitkeeper has been aimed at making it easier to do development the wayLinux kernel development is done.  As Larry McVoy put it: "BK makes itreally easy to do what Linus is doing." [1]What is this development model?  Unlike just about any other largefree software project, the Linux kernel relies on a single integratorfor each line of development.  As of this writing, the integrators areLinus Torvalds for the mainline, Alan Cox for the bleeding-edgedevelopment branch, and Marcelo Tosatti for the stable 2.4 branch.Outside contributions are generally filtered through area-specificmaintainers (e.g. Remy Card for the ext2 filesystem), forming atwo-level hierarchy.Because of this model, the area maintainers--and particularly thebranch maintainers--need tools which can handle very high integrationthroughput.  CVS, the mainstay of other free software projects, doesnot perform well for this purpose: its tagging and status operationsare slow; it does not have atomic changesets; its command set is notstreamlined for change integration.To meet the Linux kernel developers' needs, Bitkeeper focuses ondecentralized development and communication of changesets betweendevelopers.  Bitkeeper supports a hierarchy of repositories, withchanges propagated from lower-level repositories to upper-levelrepositories through a variety of channels.Although a changeset-oriented source control tool is useful in manycontexts (offline development on a laptop and private branches of aproject, to name two), the pyramid development model which motivatesit is a fundamentally poor way to run a project.  Although it isdifficult to argue with Linux's numerical success, the pyramid modelhas important limitations:  * Limited development speed: even with the best tools, a single    integrator can only achieve a certain level of throughput.  * Single point of failure: if the single integrator of a branch    suffers an accident, goes on vacation, or simply burns out,    development is disrupted until a new integrator can be selected    and comes up to speed.  * Opinionated maintainers: it is a rare individual who is always    right.  For instance, the mainline Linux kernel does not contain a    kernel debugger because Linus won't allow it.  "I don't think    kernel development should be 'easy'.  I do not condone    single-stepping through code to find the bug." [2]  * Limited filtering: work done by (or approved by) an area    maintainer is only subject to review by the branch integrator, and    such review may be cursory or nonexistent.  Of course, anyone can    review all the changes that go into a branch, but only two people    are in a position to say "no, this change does not meet our    standards; it cannot go in" and make it stick.For Linux, the consequences of these limitations have been slow andunpredictable release schedules, poor stability of release branches,and a lack of important standards (for instance, no consistent kernelmodule ABI or even API within a release branch).Other large free software projects (the *BSDs, Mozilla, Apache) have apool of committers with write access to the development mainline.  Howcommitters are chosen and how conflicts are handled varies fromproject to project [3], but the fundamental organization is constant.These projects are able to use CVS productively because no singleindividual is required to integrate a large volume of outside changes.To be fair, not all of these projects have achieved perfectlypredictable or stable releases or adherence to important standards,but they have performed better in those respects than Linux has, onbalance.Of course, Bitkeeper can still work with centralized projectmanagement, and carries some advantages over CVS in that context, suchas easy file renaming and offline development.  But free softwaredevelopers are unlikely to consider Bitkeeper unless they aregenuinely unable to muddle through with CVS--that is, if they areusing pyramid management.In conclusion: Bitkeeper is wrong for free software because itencourages a development model with bad results.  Developers would bebetter off managing their projects in a centralized manner withmultiple committers.[1] linux-kernel, 2002-10-05 23:28:52 GMT    http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.0/1804.html    Also see the end of    http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/0315.html[2] linux-kernel, 2002-09-06 19:52:29 GMT    http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.0/1148.html[3] For example, see http://httpd.apache.org/dev/guidelines.htmlThanks to Carl Alexander and Joseph Sokol-Margolis for valuableediting assistance.