有关合作者向项目创建提交的新规则的讨论

[Happy2018new]

我注意到最近产生了很多拉取请求，但大多数拉取请求的改动都不大，但这些提交都以拉取请求的方式被合并到了主分支，这显然形成了对拉取请求这一工具的滥用行为。

很多的提交都可以直接提交到存储库的，又不是什么大的更改，完全没必要开 PR 处理问题。

我认为我们应该重视这件事？

[SuperScript-PRC]

已解决：仅在 dev 分支 commit，每次合并到主分支的时候pr和bump version

[SuperScript-PRC]

main分支仅在需要大版本更新时再提交PR

[SuperScript-PRC]

已解决：仅在 dev 分支 commit，每次合并到主分支的时候pr和bump version

或许该作为一条不成文的规定？

[xingchentye]

已解决：仅在 dev 分支 commit，每次合并到主分支的时候pr和bump version

啊?我已经提交了部分代码到main,我会在以后提交时直接提交到dev分支

[Happy2018new]

此议题仍需要进一步讨论。

我个人对 dev 分支的相关规则仍然持保留态度，具体为

• 非大型更改，拥有可写权限的项目协作者应该可以直接提交到主分支
• Dev 分支对于 ToolDelta 这种只有 3 个项目合作者的项目是否严格需要还有待讨论
• 个人认为 Pull Request 应该专注于一个模块或功能，或者围绕一个中心主题进行创建，而目前是把所有的东西都提交到 Dev，然后再通过 Pull Request 进行合并，这导致每次合并时都会包含对于各种各样功能的提交，变成了一个大杂烩，个人认为这样不算一个优雅的做法

[Happy2018new]

总之我觉得这种处理办法还是抽象了点

---

[Happy2018new]

如果确实要使用这样的方法进行开发，那么由于 PR 的东西肯定是一个包含了各种功能改动的大杂烩，那么我们应该写个摘要描述变动，并且附上对应的提交，比如这样。
但我得说这样做很麻烦，我不推荐这么做。

---

[Happy2018new]

如果不对大杂烩 PR 进行摘要概述，而是直接开一个什么都不写就给合并了，那么每个这种 PR 除了包含的文件变动外，基本上都是千篇一律的，没什么区分度，那这会让 PR 显得苍白无力，甚至失去它作为 PR 的作用。

这种情况下还不如直接提交来的好。

不是为了合并而合并。

[Happy2018new]

如果是因为希望减少 BUG 而实施的这样一系列规则，那么我得说这解决不了什么问题，因为协作者本身就不多，如果还要等审核，这个效率就不好说了。

而且人为审查也很可能存在遗漏，我们或许还得添加测试用例，然后每次合并前跑一遍。
写并且维护测试用例没有想象中的那么简单，而且我个人也认为，目前项目的体量还没有大到必须用测试用例的情况。

这里不得不说项目贡献者和项目协作者的区别，正是因为对方是项目协作者，所以才可以在无需项目主导者审核的情况下直接进行提交——我们人并不多，数出来也就三四个人，完全没必要限制的这么死，而且这么操作起来，我认为一点也不优雅。

[Happy2018new]

另外一个观点是，我觉得各位用 GitHub 都不是很熟，因此 Dev 这种想法太超前了，对于我们这个体量的项目也是如此。