开源之旅：初次贡献与PR提交流程

背景

作为一名程序员，一直在公司项目上写代码，却从来没有参与过开源项目。虽然早之前了解过开源项目是什么？如何参加？但由于开源项目的规范要求严格和一些代码检查工具只是耳闻目睹，促使我望而却步。加上自己工作项目较忙、休息的时候也犯懒（主要是因为懒） 这件事就变成了只是想想，然后就搁置了。

最近看到了 我们正在开发一套组件库，欢迎你的加入~
这篇文章后，我下决心打算真正的参与进来。

俗话说万事开头难，但只要有了开始的心就算迈出一大步了。

由于第一次参加开源项目加上平常git用的较少（公司一直在用 svn），一些具体流程让我很迷 😭，于是我很多问题请教了项目中的 大飞同学，真的很棒，帮我解惑。还有些问题也有询问过作者、以及群里的部分同学，大家也积极帮助解决，十分感谢！这种氛围真的很不错！

于是我打算梳理下开源流程，记录自己第一次开源经历，也希望能帮助到其他同学。

项目地址

yike-design-dev: Vue3+Ts+Less 开发的前端 UI 框架 (github.com)
欢迎大家积极参与

fork 项目到自己仓库

第一步的话就是找到你要参与的开源项目 github仓库地址（我们叫它上游仓库）然后点击 fork 后，就会在自己仓库下看到一个与上游仓库一样的仓库，之后我们就要基于这个仓库去写代码。

• 克隆 fork 的仓库到本地
  git clone xxx

• 查看关联的远程仓库

  git remote -v

• 添加主仓库为远程仓库之一（只需操作一次）

  git remote add upstream xxx上游仓库地址

创建需求分支规范

建议一个分支处理一个需求。

格式： ${type}/${component}/${feat}
例子：

• feature/base/add-markdown-pure
• feature/button/add-style
• fix/icon/alignment-issue
• docs/upload/add-picture-demo
• refactor/base/refactor-router

git 创建并切换分支：
git checkout -b feature/progress/init

commit 提交规范

commmit 包含三部分内容 与分支规范类似： ${type}(${component}): ${commit-word}

例子：

• feat(button): add styles for button component

• fix(icon): resolve alignment issue in icon component

• docs(upload): update README file

• refactor(base): refactor router module

• feat(merge code): merge the upstream to update code

git 操作：
git commit -m 'feat(merge): 合并上游仓库代码'

ps：其中符号都是英文格式，冒号后面必须有空格，因为项目有 commit 校验，不符合规范提交时是校验失败、提交失败的。

我遇到的 commit 失败问题

commit 时直接报错： npm ERR! Unexpected token '.'
打开日志文件也看不到啥有价值的信息，这个报错是在 win10 机器上出现的，然而在另外一台机器上就很正常。

请教大飞同学得知是因为执行 husky 脚本失败了、感觉 npx 有问题。但是切换了不同版本 node也没能解决。很是头疼，我是使用 nvm 管理的 node 环境，最后我卸载了 nvm，重装了较新版本后问题解决。有遇到这个问题的同学可以试试。

写代码

当你认领好你想开发的任务，或者想解决的问题，创建好需求分支后，这一步没什么好说的就是写代码了。但需要注意的开源项目一般都有代码规范，使用了一些代码检查工具，如：eslint、stylelint等，写的时候需要注意下。

与上游仓库同步（重点）

因为当你 fork 完项目后此时你的代码和上游仓库是同步的，但是当你再进行自己的需求开发时，会有其他同学陆续提交 pr，更新上游仓库。此时你就需要让你的代码和上游仓库保持同步。

1、更新上游仓库代码

git fetch upstream

upstream 就代表上游仓库，开始新需求开发时先更新。

2、合并上游仓库代码

git merge upstream/monorepo-dev

此步骤将更新到的上游代码合并到你当前本地仓库monorepo-dev主分支上（其他分支是不会一起合并的！）如果此时更新到的上游仓库代码和你本地代码有冲突就需要先在编辑器中手动解决冲突、合并代码后再提交（见步骤 3）

更新遇到冲突暂存代码

如果文件冲突可以一一解决，如果没有冲突可以选择暂存你本地的代码，再合并，合并完后再取出暂存代码继续开发。

• 暂存代码
  git stash

• 查看暂存
  git stash list

• 取出暂存的代码
  git stash pop

3、更新同步自己 fork 后的仓库

当完成第 1、2 步时，此时只是你本地代码和上游仓库保持了一致，但你 fork 后的远程仓库还没有同步，需要将本地代码提交（如果有冲突需要先解决才能提交）

提交本地代码到自己 fork 后到远程仓库：
git push

这一步操作没问题后，此时你本地代码和 fork 后的远程仓库的代码都和上游仓库代码保持同步了。

4、需求分支注意

如果在同步上游代码之前你已经创建了新的需求分支进行开发了，这时候你的需求分支代码和你主分支（monorepo-dev）是不同步的！

需要先切换到需求分支git checkout xxx需求分支 然后把本地主分支代码再合并到需求分支保持同步：git merge xxx主分支

这样你的主分支、需求分支代码也都同步了，可以继续你的新需求开发，然后提交更新 fork 后远程仓库的需求分支代码。

ps：
如果项目涉及到的多人修改同一文件情况较少、冲突就会少，这种情况就建议先在自己的需求分支开发，等完全开发完毕了再一次性的去拉取更新上游仓库代码、然后合并（有冲突解决）同步自己本地仓库、然后提交同步自己 fork 的远程仓库。

提交 pr

当你负责的一个需求开发完毕后，此时就可以去 github 中提交 PR（pull request）

PR 将由具备权限的贡献者 CR（Code Review） 后进行 merge，如果有问题也会给你提意见，然后你可以修改好再提交。

如果没问题，恭喜你，你的 PR 就会被合并到上游仓库，此刻就完成了开源项目的一次贡献流程。

总结

这个项目对于没参加过开源的同学很友好，虽然刚开始完成的都是一些基础组件，且这些基础组件已经在业界内有实现 如：element-ui、ant design 等。

但等你真正的参与到项目中去开发实现的时候就会发现一个看上去简单的组件是需要考虑到很多细节问题的。

项目计划后期也会从基础组件出发，开始封装功能性组件、封装前后端组件。是一个很好的循序渐进的过程。

我相信如果能坚持开源这件事，日积月累编码和阅读源码的能力都会有很大的提升。

如果文章对你有帮助，可以点击链接关注我的掘金社区账号 更多技术分享请移步我的掘金哦~ 😀😀😀

点击链接 学习交流群(前端微信群) - 掘金 (juejin.cn) 加 vx 拉你进 前端学习交流群 让我们一起 好好学习（🐟🐟🐟）吧 😎😎😎