Jonathan Bedard 在周三的文章上写道:6 月 23 日,WebKit 项目冻结了 Subversion 树,并将源码的管理与交互迁移到了 GitHub 上。之所以这么做,是因为 WebKit 社区意识到了 git 分布式特性的重要性 —— 不仅仅涉及多个开发人员、而是能够让多个组织在单个项目上轻松展开协作。 (来自:WebKit.org) git 作者与提交者模型,很好地呈现了像 WebKit 这样的大型软件项目,其在代码编写和管理工作上到底有复杂。 得益于本地变更记录,git 可让项目在各分支之间的移动提交 / 撤销都变得更加便捷。 同时 git log 将提交历史限制到存储库某些部分的能力,意味着大型项目不再需要于每次提交时签入过时的 ChangeLog 文件。 另外它在软件工程中的普遍性,意味着 WebKit 项目的大多数新贡献者,都会发现自己的 git-svn、更倾向于从 WebKit 项目的镜像中着手。 所以 WebKit 决定将项目转变为纯 git 模式,并且能够很好地配合现有工具 / 工作流程。 至于 GitHub 为何如此受青睐,Jonathan Bedard 解释称: 首先,WebKit 项目组对来自世界各地的开发者的贡献和反馈都深感兴趣,而 GitHub 正好拥有一个非常庞大的开发者社区 —— 尤其是 Web 开发人员。 通过与他们密切合作,WebKit 引擎可以得到充分的改进,并将这些开发人员的创作传递到世界各地的用户手中。 其次,我们发现 GitHub 的 API 让我们可以通过对现有基础架构施加较小的修改、来构建高级的提交前后的自动化体验。 以及提供一个现代且安全的平台,来审查并提供有关新代码更改的反馈。 当然 git 也不是那样完美无缺,比它的哈希不是自然排序的。 WebKit 团队发现,轻松推断存储库中提交顺序的能力,对于我们的零容忍性能回归策略至关重要。 于是我们在决定需要二分的工作流程中,使用了所谓的‘提交标识符’方案。 在主分支上,commit identifiers 特指提交拥有的祖数量(ancestors)计数,而分支还得结合两者。 至于确切的提交标识符,可分别通过git rev-list --count <ref>或git rev-list --count main..<ref>来计算。 为此,WebKit 团队开发了一些简单的工具来处理 commit identifiers 。 值得一提的有 Tools/Scripts/git-webkit(提供 git 与标识符兼容的命令), 以及 commits.webkit.org(用于在不同提交表示之间进行转换的简单 Web 服务)。 此外所有提交提交都通过commits.webkit.org链接,将标识符嵌入到各自的提交消息中。 感兴趣的朋友,可移步至 GitHub wiki /Source Control页面以了解详情。