在 github 上为他人项目贡献代码要注意些什么呢

[eloah]

最近在 github 上为一个项目贡献代码(其实也就是帮忙改改 bug 加点小功能),然后每次都被作者 if you ...... I will be happy to merge

问题包括
命名规范和代码规范(驼峰命名,私有方法命名,换行问题)
一个 issue 里面提了很多问题(作者说要尽量分开)
无意义修改(只是把一些代码位置调整)

感觉作者都快被我弄烦了

想请教一下各位,作为贡献者,你们平时是怎么做的,有哪里需要注意的;作为项目的拥有者,你们比较反感什么样的 pull request 或者 issue 呢?

[Return2legacy]

其实最烦的是只开一个分支，然后一个 PR 就推一堆上去，而且可能还在不断更新，然后还叫你自己看着用。

[sox]

代码风格这个只能靠 linter 解决吧

[clino]

你自己多注意一下原作者用的编程规范吧
其实经验越多一般对这些方面会更注意
我曾经对一个 patch 做 code review 做了快 20 次才过

[fcicq]

有耐心慢慢改就好, 但是不要触及对方的耐心极限(提交讨论的次数 /频率可能有不成文的限制), 能一次改好的不要改两次. 多人管理的项目可能需要私下先疏通征求意见避免彻底失去 merge 的希望. 而对大型的项目做贡献有折腾好几年的准备也就可以了.

[raincious]

如果你要修 Bug 的话，为了整洁应该一个 Bug 一个 Bug 的修复，不要一次改动太多代码，否则 Review 起来别人也头疼。

[eloah]

@Return2legacy 我都有好好说明改动和为什么改动的,这样的话可以吗

[eloah]

@sox 你是说这个吗 http://www.sublimelinter.com/en/latest/about.html

[eloah]

@clino 可能也是自己经验不足......平时代码很多都是写给自己看的,不太注意

[eloah]

@fcicq @raincious 非常感谢

[airyland]

1.看 contribution 规范(其中也包含了代码规范)
2.先沟通再 PR ，这个很重要，不要浪费彼此时间
3.先 rebase 不要多个 commit 甚至 conflict
4.commit 写有意义的，不要写 "update index.html", 要写英文
5.新特性请补充 demo(如果有的话)，补充 test(如果有的话)
6.修改的话不要重开 PR ，不要重开 PR ， 不要重开 PR ！！！自行 squash
7.作者提出修改意见时，请及时更新

暂时想到就这么多。。

[kn007]

用英文，作者要是有对 PR 什么建议，合理照做就是了。

[Return2legacy]

@eloah 每个 commit 有必要说明这是提高效率，如你所说的第二条和 5 楼所说的，每条 commit 尽量针对单一问题，或者说单一特性，精炼但不繁复，因为要顾及到后期维护， revert 也好什么也好，能易操作的。每个 PR 要有条理，然后就是代码质量问题了。

[sox]

@eloah eslint 什么的

[JamesRuan]

哈哈，我的 github 项目就见过一次 PR ，把我激动地不行了。
然后我依然是： If you ...... I will be happy to merge 。

实在是发 PR 的人的代码质量和我的要求差别太大，两个来回后我就受不了了，直接在他的基础上自己手动改了 merge 了完事。

[eloah]

@airyland @kn007
非常感谢

[eloah]

@sox 好的,我去查查
顺便,你的 id......

[eloah]

@Return2legacy 好的,明白啦,非常感谢

[eloah]

@JamesRuan 这样不太好吧,对于我这样的萌新来说被 merge 了还是很兴奋很有成就感的啦,噗

[kn007]

@eloah 哈，主要是曾经一次，作者说：
Thanks! Can we change it to this:
```
code
```

我看了是更加规范的代码，然后就照改了。。。