Linuxeden开源社区
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 页面以了解详情。