Git

如何提交一个有效的PR

1.fork项目

项目会到自己名下仓库

2.clone到本地

3.修改分支

4.修改提交代码

本地修改代码后，提交commit

commit_message格式： [commit_type][module] message

commit_type:

feat：表示是一个新功能（feature)

hotfix：hotfix，修补bug

docs：改动、增加文档

opt：修改代码风格及opt imports这些，不改动原有执行的代码

test：增加测试

eg:[hotfix-12345][mysql] Fix mysql time type loses precision.

rebase远程分支

这一步很重要，因为我们仓库中的chunjun代码很有可能已经落后于社区，所以我们 push commit前需要rebase，保证我们的commit是基于社区最新的代码，很多小伙伴没有这一步导致提交的pr当中包含了其他人的commit

rebase后有可能出现代码冲突，一般是由于多人编辑同一个文件引起的，只需要根据提示打开冲突文件对冲突部分进行修改，将提示的冲突文件的冲突都解决后，执行

依此往复，直至屏幕出现类似rebase successful字样即可

rebase之后代码可能无法正常推送，需要git push -f 强制推送，强制推送是一个有风险的操作，操作前请仔细检查以避免出现无关代码被强制覆盖的问题

push到github仓库

5.提交pr

Pull Request页面选择自己的提交

选择head仓库和base仓库以及相应的分支

填写pr信息，pr信息应该尽量概括清楚问题的前因后果，如果存在对应Issue要附加Issue地址，保证问题是可追溯的

pr提交成功后需要一段时间代码review。

pr review

● pr review

• 如果是简单的代码或者文档改动，review 结束可以直接合并

• 如果是较大的内容改动，需要对应模块owner review

• 如果是功能分支，需要pr中提供设计思路，有必要的情况下，提供设计文档

• pr 回复时间不能超过一周

• 不符合规范的pr 在回复提示过后仍未改动，不予合并，一周之后关闭



● review pr 的要求

• 在pr里备注修复的issue

• pr commit 模版[hotfix-#issueID][#fix-module] #fix-commit.

• 修改内容尽量保持与issue内容一致，如果出现无关修改，在pr中备注出来

• review 代码时注意代码格式化

Plain Text

如何正确提出一个Issue

issue 大致分为几种：

• 反馈错误 (Bug Reports)

• 提交新需求 (Feature Requests)

• 常规问题 (General Questions)

• 性能问题 (Performance Questions)

Plain Text

详细描述存在问题+问题截图，提交到ChunJun的Issue，以便迅速定位问题并作出回应。

提交的Issue 最好带上详细的复现问题的步骤，这样可以减少其他同步复现问题的时间，更快更有效地解决问题。

如果能定位到源码的问题，建议提交一个pr来修复它，而不是等待其他同学。