了解PR
-
PR(pull request)，一种重要的协作机制，在开源项目中，PR被广泛用于社区贡献。
-
对个人开发的开源项目来说，独力难支，如果能动员社区的开发者一起推动和修改项目就可以事半功倍。而对于团队开发的项目，每个人的代码风格和技术参差不齐，上述的情况如果将所有人的提交都采纳将会变得十分混乱，而PR则可以解决这个问题。
创建PR
前提条件
-
GitHub 账户：确保你有一个 GitHub 账户并已登录。
-
项目 Fork：在你想贡献的项目页面，点击“Fork”按钮，将项目复制到你的 GitHub 账户中。
-
本地克隆：将 Fork 的项目克隆到你的本地计算机。
git clone https://github.com/你的用户名/项目名.git -
创建分支：在本地仓库中创建一个新的分支来进行你的更改。
git checkout -b feature/你的功能名
步骤
对于开源项目，我们应该先将项目fork到个人的仓库，以后的修改都会基于个人仓库的版本修改
将项目clone到本地
git clone git@repo.repo.git在本地对你认为可以修改或可以添加的部分进行编辑，编辑完成后使用git提交并推送到远程仓库
git checkout -b your_branch
git add .
git commit -m "说明"
git push origin your_branch检查没有问题后，就可以在项目中向管理者发起PR申请，等待提交的内容被合并到项目中
git其余操作可见Week6_Git与GitHub
PR的使用
- 对于项目所有者而言，PR可以进行项目管理/收集社区贡献
- 收集到PR后，是否采纳修改/功能增加需要进行审查和讨论
- 在GitHub中的一个PR中，开发者和项目所有者可以交换意见，进行讨论，修改PR，最后达成一致
作为一个社区开发者/代码贡献者，PR时可以参考以下准则：
- 编写小型PR：尽量创建目的单一、重点明确的小型PR，小型PR的审查和合并的难度低，速度快，引入bug的可能性也低
- 进行自审：提交前先自行审查、生存和测试自己的PR
关于这一点，我深有体会，push后发现修改错了再revert，不仅增加了审查的工作量，也浪费了自己的时间，因此一定要自审！！！
- 详细的PR说明：在提交申请时可以尽量简短详实地阐述PR的目的、内容或者与PR有关的讨论或Issue
而对于项目维护者，GitHub给出的建议是
- 使用PR模版：使用PR模版以规范化PR
- 定义代码所有者：指定某人审查
docs中的更改，详见地址 - 使用受保护的分支：使用受保护分支来防止在满足某些条件之前将拉取请求合并到重要分支
- 使用推送规则集：可以阻止对专用或内部存储库的推送，以及对此存储库整个分支网络的推送（这看起来似乎会对贡献产生比较大的约束）
- 使用自动化工具进行审查：可以使用自动化工具对代码格式进行审查和规范，或者使用AI进行总结
此外，在PR中与维护者保持沟通也是重要的一环
merge考虑的因素
- 代码质量：确保提交的代码具有良好的代码风格，遵循源项目的规范，并且确保不会引入bug
- 接受审查：PR通常都会经过代码审查，及时关注审查者的评论，作出必要的修改，这是merge的重要步骤
- 尽量明确的PR：提交PR的目的尽量小而明确，这样方便进行测试和审查，也避免在一次PR引发多种错误
- 保持更新：当社区贡献者为项目编写PR时，有可能其他的开发者已经推送了当前进行的任务到项目，保持项目的更新可以避免和其他人重复PR
- 测试：有些项目包含自动化测试，确保为改动增加或修改相应的测试，这不仅能验证功能正确实现，还能防止未来的代码更改/破坏现有功能
注意事项
- 保持分支更新：在等待审查期间，保持你的分支与主分支同步，以减少合并冲突。
- 测试更改：确保你的更改经过充分测试，避免引入新的 bug。
- 遵循项目贡献指南：每个项目可能有特定的贡献指南，请务必阅读并遵循。