给Next提交代码

写这篇文章的主要目的就是用来给next主题的开源社区用户一个参考的地方,最近发现很多提交pr的用户不太“正确”,这里的正确是指我这边方便操作,并不是说大家提交的pr是错误的,那么为什么要按照我的要求来提交pr呢?既然都是给项目提交代码,何必要弄这么多麻烦的事情呢?其实这个一个是规范,另一个也是想不辜负大家的心意。

PR

要想贡献代码,首先就是提交pr,那么第一个开刀的就是规范pr了。下面开始说正题,为什么要按照要求来提交pr?首先就是方便管理,其次就是我想尽可能的合并大家的写的代码,如果大家提交的代码有问题的话,我这边是不会合并的,所以也请大家能够理解,本来就是抽时间维护这个项目,我们更应该提交效率。

命名

pr的命名最好按照fix,feat,doc这种固定的前缀要求来,这样的话,我在收到邮件的时候就能第一时间注意到pr可能会涉及到哪些东西,会根据优先级来合并。名称格式:${prefix}/名字 ,对于名字部分可以随意,只要意思明确就行,最好能对应到某个issue。一般命名的前缀有以下几个:

  • fix:修复bug
  • docs:添加项目文档
  • feat:新功能(feature)
  • refactor:重构(即不是新增功能,也不是修改bug的代码变动)
  • pref:优化(样式、性能、代码等优化)

commit

一般建议一个pr需要有针对性的目的,不要一个pr有多个操作,如:在一个pr里既修复bug,又添加新功能,这样的话不太好。试想,如果你修复的那个bug比较紧急,然后添加的新功能又要经过测试,这个时候是不是就麻烦了,到底是先合并还是先测试呢?所以后期对于这种pr我会直接忽略的,请大家理解。

操作规范

操作规范主要是说在提交pr的时候以及fork后进行开发的操作,这里我强烈“要求”大家在fork完项目之后,不要直接在master上修改代码,需要创建一个新的分支,然后在分支上进行开发。这样的主要目的是有些时候大家提交了pr,我需要测试一下,但是我又不能先合并到master,如果先合并就会造成master污染了。所以我就要先clone大家的项目,然后在本地测试,这样一个两个我还能操作过来,但是后期一旦pr过多,那就麻烦了;还有一个问题就是如果我只想合并大家pr中的某个commit,而不是所有,那这个只能使用git cherry-pick命令挑选重要的commit合并,但是如果直接在master修改的话那我是无法做到这点的。
接下来弄个简单的教程,希望大家能明白具体怎么操作的:

  1. fork项目:直接点fork,没有什么好解释的
  2. clone自己fork的项目到本地
  3. 使用git checkout -b newBranch 命令创建新分支
  4. 修改代码,commit
  5. git push origin newBranch

最后在提交pr的时候可以这样提交

一句话:就是不要直接在master上直接修改代码,在自己fork的项目上新建分支,然后将分支合并到原项目的主分支上。

贡献

目前对于贡献代码,我建议大家首先从bug、或者那些不需要修改页面样式的需求开始。主要原因就是每个人的审美标准不一致,所以这里我就一个人安排了,希望大家理解,也感谢各位的贡献

感谢

感谢以下Contributors辛勤付出:
@01f
@ame1973
@tcitry