< 返回版块

xcaptain 发表于 2019-04-01 00:24

如图: https://i.imgur.com/mJxyx6C.png

左边是golang的提交历史,右边是rust的提交历史,明显可以看出go的项目提交历史很清晰,似乎都是在主干上改的,而rust中各种分支纠缠在一起,有的分支几个月之前就创建了但是过了几个月才合并,同样是社区贡献的项目为啥差别这么大

评论区

写评论
lilydjwg 2019-04-06 18:53

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

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

Mike Tang 2019-04-01 22:49

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

作者 xcaptain 2019-04-01 21:19

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

jonirrings 2019-04-01 14:27

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

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

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

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

mzji 2019-04-01 12:40

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

Mike Tang 2019-04-01 10:29

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

iPixelOldC 2019-04-01 00:49

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

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

作者 xcaptain 2019-04-01 00:27

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

1 共 8 条评论, 1 页