 | 1 Return2legacy Aug 7, 2016 via Android  1 其实最烦的是只开一个分支，然后一个 PR 就推一堆上去，而且可能还在不断更新，然后还叫你自己看着用。 |
 | 2 sox Aug 7, 2016 via Android 1 代码风格这个只能靠 linter 解决吧 |
 | 3 clino Aug 7, 2016 via Android 1 你自己多注意一下原作者用的编程规范吧 其实经验越多一般对这些方面会更注意 我曾经对一个 patch 做 code review 做了快 20 次才过 |
 | 4 fcicq Aug 7, 2016 1 有耐心慢慢改就好, 但是不要触及对方的耐心极限(提交讨论的次数 /频率可能有不成文的限制), 能一次改好的不要改两次. 多人管理的项目可能需要私下先疏通征求意见避免彻底失去 merge 的希望. 而对大型的项目做贡献有折腾好几年的准备也就可以了. |
 | 5 raincious Aug 7, 2016 1 如果你要修 Bug 的话，为了整洁应该一个 Bug 一个 Bug 的修复，不要一次改动太多代码，否则 Review 起来别人也头疼。 |
 | 6 eloah OP @Return2legacy 我都有好好说明改动和为什么改动的,这样的话可以吗 |
| 7 |
 | 10 airyland Aug 7, 2016 1 1.看 contribution 规范(其中也包含了代码规范) 2.先沟通再 PR ，这个很重要，不要浪费彼此时间 3.先 rebase 不要多个 commit 甚至 conflict 4.commit 写有意义的，不要写 "update index.html", 要写英文 5.新特性请补充 demo(如果有的话)，补充 test(如果有的话) 6.修改的话不要重开 PR ，不要重开 PR ， 不要重开 PR ！！！自行 squash 7.作者提出修改意见时，请及时更新 暂时想到就这么多。。 |
 | 11 kn007 Aug 7, 2016 1 用英文，作者要是有对 PR 什么建议，合理照做就是了。 |
| 12 Return2legacy Aug 7, 2016 via Android @eloah 每个 commit 有必要说明这是提高效率，如你所说的第二条和 5 楼所说的，每条 commit 尽量针对单一问题，或者说单一特性，精炼但不繁复，因为要顾及到后期维护， revert 也好什么也好，能易操作的。每个 PR 要有条理，然后就是代码质量问题了。 |
 | 14 JamesRuan Aug 7, 2016 1 哈哈，我的 github 项目就见过一次 PR ，把我激动地不行了。 然后我依然是： If you ...... I will be happy to merge 。 实在是发 PR 的人的代码质量和我的要求差别太大，两个来回后我就受不了了，直接在他的基础上自己手动改了 merge 了完事。 |
| 17 eloah OP @Return2legacy 好的,明白啦,非常感谢 |
Select Language