手把手教你，细说向开源项目递交代码的流程
系列文章目录
手把手教你安装Git，萌新迈向专业的必备一步
GIT命令只会抄却不理解？看完原理才能事半功倍！
常用GIT命令详解，手把手让你登堂入室
GIT实战篇，教你如何使用GIT可视化工具
GIT使用需知，哪些操作会导致本地代码变动
文章目录
- 系列文章目录
- 一、选择开源项目
- 二、两个操作
-
- 1. fork
- 2. pull request
- 三、实操
-
- 1. fork 并 clone
- 2. 修改内容并推送
- 3. 创建PR
- 4. 管理者评审
- 5. 合并
- 四、答疑与总结
经过前面的学习，相信大家对GIT的已经基本熟悉了。但是笔者也知道，很多同学对向开源项目做贡献感兴趣，开源项目的魅力在于它们能够吸引来自世界各地的开发者协同工作，共同创造出更为强大的代码库。如果你想为一个开源项目作出贡献，那么递交代码就是必须掌握的技能。在这篇博客中，我将会手把手地教你如何向开源项目递交代码
作者简介：战斧，从事金融IT行业，有着多年一线开发、架构经验；爱好广泛，乐于分享，致力于创作更多高质量内容
本文收录于 GIT 专栏，有需要者，可直接订阅专栏实时获取更新
高质量专栏 云原生、RabbitMQ、Spring全家桶 等仍在更新，欢迎指导
Zookeeper Redis kafka docker netty等诸多框架，以及架构与分布式专题即将上线，敬请期待
一、选择开源项目
首先，你需要选择一个你想要为其作出贡献的开源项目。你可以在GitHub等代码托管平台上查找符合你兴趣和能力的项目，了解它们的目的、代码等级、许可证、开发人员和社区等信息。
在选择一个项目之前，你应该首先了解它的需求，并检查它们是否与你的专业技能相符合。你还应该考虑项目的长期规划，以便你的工作能够持续地为项目做贡献。
二、两个操作
我们之前的内容，一般都是开发者自己维护的仓库，拥有着诸多权限，可以让开发者随意更改。但是别人的开源项目，你并不会拥有直接更改的权限。所以在代码平台上提供了两个操作
1. fork
fork的定义是指的是将一个开源项目复制到自己的 GitHub 账户下的操作。当你 fork 一个项目时，你就拥有了该项目在你的 GitHub 账户下的一份完整拷贝，可以在此基础上进行修改、测试和实验等。
如 github上的fork位置：
或者是 gitee 上的也是一样的：
如果你前面对Git的学习比较认真的话，比较容易想起来一个类似的命令，即git clone。该命令可以帮助你获取代码库，但它们之间有很大的区别
简单来说，fork 是把开源仓库的内容复制到你的远程仓库，clone 是把你的远程仓库复制到本地仓库。另外需要说明的是，fork 并不是GIT自带的功能，而是像github、gitee 这样的代码托管平台提供的功能，主要作用是在平台上进行协作
2. pull request
与fork相对的，当我们完成一些内容后，需要把我们的内容推送至开源项目中，但是我们并没有推送的权限，所以有了PR（Pull Request），Pull Request是指在GitHub或GitLab等代码托管平台上，开发者把自己修改后的代码提交给项目的管理者，请求他们审核并合并自己的代码的过程
我们在托管平台上能看到这些 pull requests，如下：
当我们点进去后，能看见其他开发者修改的内容及信息
三、实操
上面已经讲解了两个基本操作，那么现在我们开始手把手教各位如何实际操作。因为是演示，所以笔者自己在gitee上维护一个项目，然后使用小号来进行模拟操作。
1. fork 并 clone
我们先使用小号打开项目页面，然后点击 fork，目标空间当然是小号自己的空间
等待一会后，我们就能在小号的空间中，看到复制过来的开源项目
然后我们进行工程的url复制，并将其clone至本地，这里懒得敲命令，使用的是 GIT实战篇，教你如何使用GIT可视化工具 中安装过的 TortoiseGit 工具
2. 修改内容并推送
我们对 README 文件进行修改
然后我们把修改的内容进行提交和推送
此时我们可以看到提交已经到了远程上
3. 创建PR
然后我们就可以点击 PR 了
因为是fork过来的项目，当我们点击PR的时候，源分支和目标分支gitee会自动帮我们填好，如下图，我们只需要填一下PR的标题和描述。
一般来讲，PR的标题应该简洁明了地概括你所做的修改，可以使用动词+名词的形式描述你的修改操作，例如 “修复某个bug” 或 “添加某个新功能”。
而PR的描述则是详细说明你的修改内容和目的，包括解决了什么问题、采取了什么处理方式，以及对代码或用户的影响等方面。同时，你还可以在描述区域中提供一些相关链接或截图，以便审核者更好地理解你的修改内容
当我们创建了PR以后，就会看到这个页面，提示我们还在评审状态
4. 管理者评审
此时，如果我们是开源项目的管理者，当我们打开项目主页面时，就能看到这一次的PR了
当我们点开这个PR进行查看，就可以看到提交的内容
管理者可以对此次PR进行代码审核，及多种维度的检测。然后点击上面的 “审查通过” 和 “测试通过”。
5. 合并
在对PR进行检测通过后，管理者就可以进行代码合并了，我们因为是演示，所以并没有产生冲突。
如果PR出现合并冲突时，一般来说有两种做法，一种是管理员来解决冲突。另外一种就是取消当前PR的合并，并要求提交者重新修改，在这种情况下，管理员应该在PR评论中明确指出冲突并提供建议，以便提交者可以重新修改。
如果选择合并，那么恭喜你，你已经完成了一次递交，成为了该开源项目的贡献者
四、答疑与总结
本次我们以gitee为平台，详细讲解了向开源项目贡献代码的全流程，github也是一样的操作，当然笔者也总结了目前互联网上的一些疑问，在这里也做一个答疑
- 为什么叫PR（pull request）
如果用过gitLab的同学，可能对另一个类似的词汇有印象。即merge request，一般就是我在 B 分支开发，开发完成后想把 B 的代码合到 A 分支，但我并没有A分支的权限，就发起这样一个请求。其实PR也是一样的，虽然名称不一样，但实际含义相同。我们发起PR的意思就是，请求管理者拉取我们写的代码，然后合并到他们的项目中，最终合并与否是管理者来决定，我们只是请求。
- 为什么一定要fork，能不能直接clone开源项目，修改后提交并推送？
你没有权限进行push。另外即使你有权限，作为一个社区，我们应该遵循开源协作的标准流程，包括 fork 该项目、clone 代码到本地、在本地修改并提交到 GitHub，最后通过 Pull Request 向原项目管理者申请合并。这样的流程保证了你的身份和代码的原始性，也方便了其他人对你的修改进行审查和协作。
- 我想成为开源项目贡献者，我能做些什么？
其实能做的还是挺多的，最直接的就是代码方面的优化、bug的修复。如果你觉得这样太难，也可以选择为项目翻译文档或用户界面，或者编写项目的手册之类的