Go 那个看起来好 svn。至于提交消息，我觉得还好吧，Rust 的开发比 Go 开放很多，所以消息格式没有那么一致。（你去比较一下 Contributors 数量，差一倍呢。）

个人非常不喜欢把 git 用成 svn 的方式。看上去清晰的单线历史不过是把复杂性隐藏起来了。我一般会进行 git pull --rebase，但是合并的时候不会去 rebase、squash 使得历史被改写（除非太多 fix typo 这种提交）。

go 基本是集中式管理（集权），虽为开源软件，前期很少接受外部代码。而 rust 很早就交给社区了。

仔细比较之后还是觉得go的提交流程更加规范，commit message写得简直像文档而且没有那么多零散的小改动。rust零散的小改动多，可能是rust核心团队人少导致的吧，希望更多专家加入核心团队

因为多分支并行开发才是git的分布式开发模式，全在master上开发，那是svn的集中式模式。

你可以看作go是google系的大仓库习惯遗留。

rust采用的是rfc和社区驱动的方式，一旦一个rfc提出，感兴趣的成员就可以先行实施，只要不依赖于尚未实现的rfc。所以rust才有多个分支并行开发的情况。

另外在合作git上rebase是一个风险行为，合作开发的时候是禁止的；在自己还没push的本地记录上rebase倒是无所谓，只要不要影响已经合并到主干的历史就行。

要不要 Rebase 这是一个项目习惯的问题……有些项目会要求提交时 rebase ，像 rustc 就没这要求咯

这就不知道了，说明人多呗，参与提交的人多。

那个，不是很懂这个情况。但那个，你用的图床在墙内貌似没办法访问，我这边是这样的...

猜想：是不是和RFC这个制度有关系？ 嘛，对社区了解不多，rust本身就让我有点头疼....表示菜鸟路过

往下翻rust的提交历史，有时候几十个分支在并行提交，这些人提交的时候为啥不照着master先rebase一下