218 lines
8.4 KiB
Markdown
218 lines
8.4 KiB
Markdown
---
|
|
page-title: "聊聊开源的一些感受以及如何参与开源，目前正在维护一个前端脚手架，感兴趣的可以参与进来！ - V2EX"
|
|
url: https://www.v2ex.com/t/1030165#reply14
|
|
web-message:
|
|
web-badge-color: ""
|
|
web-badge-message:
|
|
date: "2024-04-07 16:21:49"
|
|
---
|
|
|
|
> ## 如何参与开源项目
|
|
>
|
|
> 一般开源项目代码库根目录都会有一个 [CONTRIBUTING.md](http://contributing.md/) 或者其他类似名字的文档来介绍如何开始贡献，像这样：
|
|
>
|
|
> 
|
|
>
|
|
> ## 第一步：Fork 项目仓库
|
|
>
|
|
> GitHub 上的项目都有一个 Fork 按钮，我们需要先将开源项目 fork 到自己的账号下，以 create-neat 为例：
|
|
>
|
|
> 
|
|
>
|
|
> 点一下 Fork 按钮，然后回到自己账号下，可以找到 fork 到的项目了：
|
|
>
|
|
> 
|
|
>
|
|
> 记得把单选框取消掉，不然你只能 fork 到 main 分支。
|
|
>
|
|
> 这个项目在你自己的账号下，也就意味着你有任意修改的权限了。我们后面要做的事情，就是将代码变更提到自己 fork 出来的代码库里，然后再通过 Pull Request 的方式将 commits 合入上游项目。
|
|
>
|
|
> ## 第二步：克隆项目仓库到本地
|
|
>
|
|
> 对于任意一个开源项目，流程几乎都是一样的。我直接写了一些命令，大家可以复制粘贴直接执行。当然，命令里的一些变量还是需要根据你自己的实际需求修改。
|
|
>
|
|
> 这里拉取自己刚才克隆下来的代码就不讲了。
|
|
>
|
|
> ## 第三步：更新本地分支代码
|
|
>
|
|
> 如果你刚刚完成 fork 和 clone 操作，那么你本地的代码肯定是新的。但是“刚刚”只存在一次，接着每一次准备开始写代码之前，你都需要确认本地分支的代码是新的，因为基于老代码开发你会陷入无限的冲突困境之中。
|
|
>
|
|
> 例如，我要更新本地 main 分支代码：
|
|
>
|
|
> ```
|
|
> git remote add upstream <原始仓库的 URL>
|
|
> git fetch upstream
|
|
> git checkout main
|
|
> git rebase upstream/main
|
|
> ```
|
|
>
|
|
> 当然，我不建议你直接在 main 分支写代码，虽然你的第一个 PR 从 main 提交完全没有问题，但是如果你需要同时提交 2 个 PR 呢？总之鼓励新增一个 feat-xxx 或者 fix-xxx 等更可读的分支来完成开发工作。最好是每个功能点一个分支。
|
|
>
|
|
> 创建分支：
|
|
>
|
|
> ```
|
|
> git checkout -b feat-xxx
|
|
> ```
|
|
>
|
|
> 这样，我们就得到了一个和上游 main 分支代码一样的特性分支 feat-xxx 了，接着可以开始愉快地写代码啦！
|
|
>
|
|
> ### feat&fix
|
|
>
|
|
> feat 和 fix 是在许多开发团队中使用的常见提交消息前缀，特别是那些遵循语义化提交（ Semantic Commit Messages ）或是 Angular 提交准则的项目。这些前缀帮助开发者快速理解一个提交的性质，增强了代码库的可读性和可维护性。
|
|
>
|
|
> 下面是对这些以及其他相关前缀的详细解释：
|
|
>
|
|
> #### feat
|
|
>
|
|
> feat 前缀用于标记新增功能（ feature ）的提交。它表示该提交引入了一个新的特性或扩展了项目的功能。使用 feat 可以快速识别出项目功能的增长点。
|
|
>
|
|
> ```
|
|
> feat: add user login functionality
|
|
> ```
|
|
>
|
|
> 这个提交消息表明添加了用户登录功能。
|
|
>
|
|
> #### fix
|
|
>
|
|
> fix 前缀用于标记修复 bug 的提交。它说明该提交解决了项目中的一个或多个已知问题。
|
|
>
|
|
> ```
|
|
> fix: correct minor typos in code
|
|
> ```
|
|
>
|
|
> 这个示例说明提交中修正了代码中的小型拼写错误。
|
|
>
|
|
> #### docs
|
|
>
|
|
> 用于标记文档相关的改动（如 README 、API 文档等）。
|
|
>
|
|
> ```
|
|
> docs: update README with API reference section
|
|
> ```
|
|
>
|
|
> #### style
|
|
>
|
|
> 用于不影响代码含义的改动（例如格式化、缺少分号等）。
|
|
>
|
|
> ```
|
|
> style: format all JavaScript files with Prettier
|
|
> ```
|
|
>
|
|
> #### refactor
|
|
>
|
|
> 用于标记代码重构的提交，即既不修复错误也不添加功能的代码更改。
|
|
>
|
|
> #### test
|
|
>
|
|
> 用于添加或修改测试代码。
|
|
>
|
|
> ```
|
|
> test: add unit tests for user service
|
|
> ```
|
|
>
|
|
> #### chore
|
|
>
|
|
> 对构建过程或辅助工具和库的更改（例如更新依赖版本）。
|
|
>
|
|
> ```
|
|
> chore: update lodash to latest version
|
|
> ```
|
|
>
|
|
> #### perf
|
|
>
|
|
> 用于改善性能的提交。
|
|
>
|
|
> ```
|
|
> perf: improve query efficiency by adding index to user_id
|
|
> ```
|
|
>
|
|
> #### ci
|
|
>
|
|
> 用于持续集成配置文件和脚本的改动（如 GitHub Actions, GitLab CI/CD 配置）。
|
|
>
|
|
> ```
|
|
> ci: add Node.js 14 to testing matrix
|
|
> ```
|
|
>
|
|
> #### build
|
|
>
|
|
> 用于影响构建系统或外部依赖关系的更改（如 gulp 、webpack 、npm ）。
|
|
>
|
|
> ```
|
|
> build: upgrade webpack to version 5
|
|
> ```
|
|
>
|
|
> 使用这些前缀可以使提交历史更加清晰、结构化，便于团队成员理解每次提交的目的和范围，同时也有助于自动化工具生成更加语义化的版本记录和发布说明。
|
|
>
|
|
> ## 第四步：写代码
|
|
>
|
|
> 写代码之前首先要启动项目，在 create-neat 中，首先要执行：
|
|
>
|
|
> ```
|
|
> pnpm install
|
|
> ```
|
|
>
|
|
> 依赖安装完成之后，执行：
|
|
>
|
|
> ```
|
|
> pnpm dev
|
|
> ```
|
|
>
|
|
> 来启动项目。之后没啥好说的，写就是了。
|
|
>
|
|
> ## 第五步：Commit 和 Push
|
|
>
|
|
> ```
|
|
> git add .
|
|
> pnpm run commit
|
|
> git push origin feat/xxx
|
|
> ```
|
|
>
|
|
> `pnpm run commit` 是使用 commitlint 来代码进行提交，比较规范。
|
|
>
|
|
> ## 第六步：开一个 PR
|
|
>
|
|
> 在完成 push 操作后，我们打开 GitHub ，可以看到一个黄色的提示框，告诉我们可以开一个 Pull Request 了：
|
|
>
|
|
> 
|
|
>
|
|
> 这里我们需要填写一个合适的标题（默认和 commit message 一样），然后按照模板填写 PR 描述。PR 模板其实在每个开源项目里都不太一样，我们需要仔细阅读上面的内容，避免犯低级错误。
|
|
>
|
|
> 比如 create-neat 的模板里目前分为 4 个部分：
|
|
>
|
|
> 1. Pre-Checklist：这里列了 3 个前置检查项，提醒 PR 提交者要先阅读 Contributing 文档，然后代码要有完善的注释或者文档，尽可能添加测试用例等；
|
|
>
|
|
> 2. PR Type: pr 提交的类型，和上面的一样，feat 或者 fix 或者 ci 这种。
|
|
>
|
|
> 3. What is the new behavior：这里填写的是 PR 的描述信息，也就是介绍你的 PR 内容的，你可以在这里描述这个 PR 解决了什么问题等；
|
|
>
|
|
> 4. What is the current behavior：记得吗？我们在开始写代码之前其实是需要认领 issue 的，这里要填写的也就是对应 issue 的 id ，issue 通过你这个 PR 的修改后就完成了，可以关闭了，这时候可以在 Related Issues 下面写 `Closes #36`。
|
|
>
|
|
>
|
|
> 
|
|
>
|
|
> 1. Does this PR introduce a breaking change：这个 pr 是否有发生破坏性变更。
|
|
>
|
|
> 这个模板并不复杂，我们直接对着之前代码的 pr 信息跟着写就行了，例如参考这个 [https://github.com/xun082/create-neat/pull/83](https://github.com/xun082/create-neat/pull/83)
|
|
>
|
|
> 这样我们就可以开启了我们的第一个 pr 提交了，如果有什么改动，别乱取消，很多都是可以在上面修改的：
|
|
>
|
|
> 
|
|
>
|
|
> 如果是代码有问题的话，也都可以直接编写，提交到你自己刚才编写的分支上的，这里会自动更新的。
|
|
>
|
|
> 开启了第一个 pr 之后，慢慢地，你可能后面就会成为一个知名的开源贡献者了。
|
|
>
|
|
> ## 最后
|
|
>
|
|
> 如果你对该项目或者另外一个项目感兴趣，可以加入我们，如果你想获取更多信息，你可以添加我微信 `yunmz777`，我拉你进群进行交流。
|
|
>
|
|
> 最后分享两个我的两个开源项目,它们分别是:
|
|
>
|
|
> - [前端脚手架 create-neat](https://github.com/xun082/create-neat)
|
|
> - [在线代码协同编辑器](https://github.com/xun082/online-edit)
|
|
>
|
|
> 如果你想提升技术，参与开源项目是一个非常好的方法。
|
|
>
|
|
> 如果你想学习前端工程化，那么参与这个前端脚手架也是一个非常不错的项目，因为这里基本涵盖了一些常见的内容。
|