bitkeeper

本文作者：francisk84 git的诞生历史 -- 摘选自《Pro git》 Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标： 1. 速度 2. 简单的设计 3. 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） 4. 完全分布式 5. 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量） git push时的refs/for/[branch_name]和refs/head/[branch_name] 谈到git push时的refs/for/[branch_name]指令，其实它是 Gerrit 工具的一种机制。简单的说，Gerrit为了保证每次代码提交都强制开启代码评审

8 月初，当 Linux 5.8 RC 版本开放测试时，大多数的新闻都聚焦于它的 大小 ，称其为“史上最大的内核版本”。正如 Linus Torvalds 本人 指出的那样 ，“尽管没有任何一件事情能脱颖而出……但 5.8 似乎是我们有史以来最大的发行版之一。” 确实，刚刚发布的 Linux 内核 5.8 RC 具有超过 14,000 个 commit，约 80 万行新代码以及大约 100 名新贡献者。要知道，距离 5.7 正式版发布才仅仅过去了约 2 个月的时间。Linux 内核维护者 Steven Rostedt 认为，5.8 之所以变得如此之大，很有可能是因为 COVID-19 疫情让很多人难以出门旅行，所有人都因此能够在这期间完成比平时更多的工作。 Rostedt 表示，从一个经验丰富的 Linux 内核贡献者和维护者的角度来看，5.8 RC 发行版特别令人震惊的并不是它的大小， 而是它的空前规模对于那些正在维护它的人来说却没有造成困扰 ，“我认为这是因为 Linux 具有比世界上任何软件项目都好的工作流程。” 拥有最佳的工作流程意味着什么？对 Rostedt 而言，这归结为 Linux 内核开发人员随着时间的推移建立的一系列基本规则，以使他们能够持续不断地大规模、可靠地发展 Linux 内核项目。Rostedt 站在一个 Linux 内核资深维护者的角度

8 月初，当 Linux 5.8 RC 版本开放测试时，大多数的新闻都聚焦于它的大小，称其为“史上最大的内核版本”。正如 Linus Torvalds 本人指出的那样，“尽管没有任何一件事情能脱颖而出……但 5.8 似乎是我们有史以来最大的发行版之一。” 确实，刚刚发布的 Linux 内核 5.8 RC 具有超过 14,000 个 commit，约 80 万行新代码以及大约 100 名新贡献者。要知道，距离 5.7 正式版发布才仅仅过去了约 2 个月的时间。Linux 内核维护者 Steven Rostedt 认为，5.8 之所以变得如此之大，很有可能是因为 COVID-19 疫情让很多人难以出门旅行，所有人都因此能够在这期间完成比平时更多的工作。 Rostedt 表示，从一个经验丰富的 Linux 内核贡献者和维护者的角度来看，5.8 RC 发行版特别令人震惊的并不是它的大小，而是它的空前规模对于那些正在维护它的人来说却没有造成困扰，“我认为这是因为 Linux 具有比世界上任何软件项目都好的工作流程。” 拥有最佳的工作流程意味着什么？对 Rostedt 而言，这归结为 Linux 内核开发人员随着时间的推移建立的一系列基本规则，以使他们能够持续不断地大规模、可靠地发展 Linux 内核项目。Rostedt 站在一个 Linux 内核资深维护者的角度，为我们分享了庞大的

4 月 7 日，全球最主流的版本控制系统 —— Git 迎来 15 周年纪念日，项目主要维护者 Junio C Hamano（滨野 纯） 先生 发邮件庆祝 了这一日子。 我们知道，所有的软件项目在整个生命周期中都要经过不断迭代，在一个又一个的新版本中完善自己的功能。开源项目更是如此，一个健康的开源项目，在“集市”模式下接受来自世界各地开发者提交的代码 ，版本更新频率通常更高。如何管理项目的版本更新，是项目开发、维护过程中必须考虑的问题。 什么是版本控制工具 在开始我们的故事之前，首先让我们来认识一下版本控制工具。版本控制的核心述求是历史纪录查询和实现协同开发。以开源项目来说，在多人协作开发的模式下，每个人都向服务器提交自己的文件，就可能存在着代码被多次修改、替换的风险，但是版本控制能够在每次更新操作后进行相应的记录。一旦发生误操作，开发者能够根据服务器中的版本记录，将项目恢复到出现问题之前的其他版本。因此，借助版本控制技术，软件开发项目可以被分割为若干模块，每个模块并行地进行开发工作，从而有效地提高了整体编程效率。 主流的版本控制工具主要分为两种，即集中式与分布式。 集中式版本控制工具类似网吧的管理系统，所有项目的历史文件与版本信息都存放在服务器上，而客户端就只能保存当前的状态信息。这种所有鸡蛋装在一个篮子里的模式缺点非常明显，一旦服务器损坏，项目所有的历史数据就会丢失

本文作者：francisk84 git的诞生历史 -- 摘选自《Pro git》 Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标： 1. 速度 2. 简单的设计 3. 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） 4. 完全分布式 5. 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量） git push时的refs/for/[branch_name]和refs/head/[branch_name] 谈到git push时的refs/for/[branch_name]指令，其实它是 Gerrit 工具的一种机制。简单的说，Gerrit为了保证每次代码提交都强制开启代码评审