准备工作
学会向上游推送补丁是成为一个上游开发者最基础的一环, 只要你具备一些Git使用的基础知识向上游推送补丁并不是一件难事
推送上游补丁首先我们要尊重社区上游文化, 按照社区习惯进行代码编写
一些比较完善的开源项目往往会注明项目的开发标准, 比如代码命名风格多个单词是用大驼峰, 小驼峰, 下划线; 用几个空格缩进还是制表符缩进等; 注释用什么风格; 提交代码时的注释要如何编写等(一般这类说明会写在自述README.md中的Contributing模块或者单独写一个贡献CONTRIBUTING.md文件中, 少部分例外一般都可以在自述或项目根目录里找到线索)
如果项目没有提供贡献说明, 那我们可以直接看现有的源码, 我们主要需要关注代码的命名、缩进、注释、提交， 然后模仿现有风格编写新的代码
Git仓库通用操作
使用Github作为标准, 其他如Gitee、Gitea、Gogs、Gitlab等操作都大同小异
- 推送第一步是你需要对现有代码进行一个
派生(forks)
备注: 这里中文补丁直译的复刻并不合适, 但更准确的应该是派生
- 拉去派生仓库, 在派生的仓库中进行代码修改并提交, 提交时务必遵守项目提交规范
备注: 如果相让上游快速接受你的代码, 除了遵守他们的代码风格外, 还尽量缩小合并请求(PR\Pull Requests\pulls), 相比一个大补丁(pacth)审查者更喜欢看到你将其拆散为多个小补丁, 这样能让其在审查的时候不用长时间被此补丁占用所有注意力(拆散成小补丁后相当于你给审查者打了多个"断点", 方便其"断点续传")
- 进行
合并请求(PR\Pull Requests\pulls), Github中可以直接在仓库的代码页面中看到贡献按钮, 点击此按钮即可创建拉去请求, 如果你使用的Git仓库没有此贡献按钮, 在合并请求中
后续只需要关注合并请求(PR\Pull Requests\pulls)页面, 在审查者同意相关修改后即会自动将代码合入项目主线中