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

[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 这种想法太超前了，对于我们这个体量的项目也是如此。

[Happy2018new]

综上所述，我不赞同强制实施 Dev 有关规则的政策，此议题仍需进一步讨论。

[wling-art]

还是有争议，因为我们还需要解决新的插件如要使用新的接口但用户可以获取到新接口插件的问题
或许我们真的应该把插件市场独立化？或者换另一个解决办法？

[Happy2018new]

这是导致需要使用 Dev 分支的重要原因吗？

[wling-art]

解决力，不需要dev了，已经独立了

[Happy2018new]

ok