目前这套流程目前已经在github上测试过数次，目前我个人没有遇到什么问题，算是比较完善的流程。
本文面向有一定git基础知识的朋友，完全不懂git的朋友，最好先学习一下git的基础知识，不用太多，如下列所示，够用就行。
- 明白git他人仓库和自己仓库的区别
- 使用git进行项目的下载和提交
- 明白git分支及如何操作分支合并
好，话不多说，我们直接开始。
分支管理
目前项目处于开荒期，很多地方并不完善，开发的人手也不稳定，所以分支不会开发太多。
如果您像参与合作，推荐fork本项目后，跨复刻的PR提交到feature-1.0，此分支专门用于整理外部提交的特性和修复。
分支说明
以下就主项目：taozhi1010/nest-admin: nest全栈快速开发平台的分支，做个简单的表格说明
| 分支名称 | 作用 | 是否允许提交 |
|---|---|---|
| master | 主分支，用来发布合成所有的稳定版本， | |
| dev | 开发分支，目前是项目主导者自己的开发分支 | |
| feature-1.0 | 1.0版本特性分支，用来整合外部其他人提交的特性。 | √ |
提交信息
Git 提交类型的常见分类 为了更好地管理和追踪代码变更，通常会在提交信息中明确指出提交的类型。
以下是一些常用的Git提交类型，请各位PR用户，根据自己提交的内容，自行归类整理，便于我们进行代码合并。
| 类型 | 说明 |
|---|---|
| feat (feature) | 新增功能 |
| fix (bug fix) | 修复错误 |
| docs (documentation) | 仅修改文档，不涉及代码逻辑变化 |
| style (styles) | 代码格式调整，不影响代码运行结果（如空格、缩进、分号等） |
| refactor (refactoring) | 重构代码，既不增加新功能也不修复错误 |
| perf (performance) | 优化性能 |
| test (tests) | 增加或修改测试用例 |
| chore (chores) | 构建过程或辅助工具的变动，如依赖升级、配置文件修改等 |
| ci (continuous integration) | 持续集成相关配置的修改 |
| revert (revert) | 回滚之前的提交 |
目前项目的功能不多，主要包括三大块
| 模块名 | 功能 | 文件夹 |
|---|---|---|
| server | nest-admin的服务端 | server |
| admin-vue3 | vue3的项目文件 | admin-vue3 |
| admin | vue2的项目文件 | admin |
| doc | 用vitepress写的项目文档，用来说明珍整个项目的使用方式 | doc |
示例
我这里提交了一份vue3相关的代码修改，那么，我的提交信息如下。
refactor(admin-vue3): 重构数据字典页面
将数据字典组和数据字典内容整合，用左树右表的模式，优化用户的操作体验。
优化登录页面原先的注册按钮的问题
1，重构字典管理页面，优化交互方式，以左树右表为基础
2，配合后端，修复数据字典按钮的所有问题，并完成相关功能的自测
3，登录页添加注册按钮，并优化登录页面
4，优化 RightToolbar 组件，修复右侧放大镜不展示的问题
5，优化配置页面 tooltip 样式，把样式全局化
6，移除不必要的静态路由文件，保证打包正常同样的，如果我这里又修改了服务端相关的内容，那么，我要提交的信息如下。
fix(server): 修复数据字典接口相关错误
修复数据字典接口相关的错误，并添加相关注释
1，批量删除数据字典内容（原先只能单个删除）
2，新增导出数据字典内容（原先只能导出数据字典组，没有数据字典内容的导出接口）
3，修复数据字典cssClass字段无法新增和修改的问题当然，如果您觉得填写信息很麻烦，也可以用AI大概代替写一下提交信息（个人推荐通义千问），之后稍作修改，便于我们排查功能即可。
操作方式
以上的信息是针对有开源项目开发经验的人，如果您是第一次进行开源项目的开发，也请不要着急。
我们这里梳理了一些开源项目的合作流程，制作了如下的提交方式，如果您有兴趣，欢迎按照如下的方式进行合作。
fork项目
“fork”，是指创建一个现有仓库的副本到自己的git账户下。
这个副本通常是在你自己的账户或组织下创建的，这样你就有了原始项目的个人副本，可以在其中自由地进行修改而不会影响到原项目。
当你“fork”一个项目时，会发生以下几件事情：
- 你会得到一个与原始仓库完全相同的仓库副本。
- 这个副本位于你自己的GitHub、GitLab等代码托管服务的账户下。
- 你可以在这个副本上进行任何修改而不影响到原始仓库。
本地开发
在fork了项目之后，我们需要将这个副本下载到本地进行开发，然后在这个副本的基础上进行修改。
这里要注意，我们需要clone的，是已经fork到自己名下的项目仓库，而不是这个原始项目的仓库。
创建分支
我们在clone下来的项目基础上，签出一个分支，为接下来的开发做准备。
同步分支
这里要注意，我们fork过来，默认应该是master或main分支，我们并没有fork过来其他分支。
因此，我们需要关联原有项目，将源项目的其他分支也同步到自己的库中。
这里以我为例，比如，我这里要提交的项目是taozhi1010/nest-admin这个项目（这是源项目）。
那么，现在将源项目（taozhi1010/nest-admin）同步到自己的fork的项目仓库中（CrazyStudent13/nest-admin）。
# git remote add 源项目别名（自己随便命名） git提供的ssh地址
git remote add upstream git@github.com:taozhi1010/nest-admin.git执行这条命令后，你就可以通过名称upstream来引用这个远程仓库了。
例如，如果你想从这个远程仓库拉取更新，可以使用git fetch upstream或git pull upstream命令；
如果你要推送更改到该仓库，则可以使用git push upstream命令（前提是拥有相应的权限）。
我们这里不做其他操作，先将远端的分支更新到本地。
git fetch upstream将远程仓库（在这里别名为 upstream）的 master 分支合并到你当前所在的分支。
git merge upstream/master提交更改
根据项目的贡献指南，我们开始本地修改代码或文档，这里确保遵循项目的代码规范和风格指南。
在完成修改之后，我们可以使用命令或者图形化的git管理工具，提交内容。
总之，就是如下两个步骤。
- 添加更改：使用
git add .来将所有更改标记为准备提交。 - 提交更改：使用
git commit -m "Your commit message"提交更改，并附上描述性的提交信息。
推送更改到远程仓库
这里注意，推送不是推送到他人的仓库，而是推送到自己的远端仓库。
如之前一样，使用图形化工具或命令，将本地的commit推送到远端仓库。
创建Pull Request (PR)
这时候，我以github为例，你登录到github的界面，打开那个同步过来的项目，你会发现有个非常明显的对比。
这里你点击一下，他会让你推送到源项目，是否要创建一个PR（pull request）。
这里，我们按照要求，填写PR描述，说明所做的更改及其原因。
然后，指定要合并的目标分支，通常是开发分支（dev），也可能主分支（如master或main）。
等待审查
提交后，项目的维护者或其他贡献者会审查你的PR。
他们会决定是否合并你的PR到自己的分支内。
解决反馈
如果收到反馈需要解决某些问题，那我们重新修改代码，再次推送。
合并
一旦你的PR被批准，它会被合并到主分支中。此时，你可以删除自己的功能分支（可选）。
以上就是给开源项目添加PR的一般流程。
不同的项目可能有不同的具体要求，所以请务必阅读项目的贡献指南以获得更详细的说明。
结语
走完上述流程，我们就算是完成一个PR了，如此，我们也算是参与开源项目了。
社区活跃度应该一些面试官比较喜欢的指标，多参与社区内的活跃项目，不仅能见识他人代码的精妙，也能让自己的努力被社区所见证。
因此，我很是推荐大家在开源社区中做出自己的贡献，哪怕只是一点点，都会让社区感到欣喜。
另外，本文由通义千问辅助编写，在一些命令的具体解释上，AI比人强了不少，比搜索引擎更是好用了太多。
不得不感叹，时代的伟力，能赶上AI风靡的大时代，不知道是幸运还是不幸。
当然，AI虽然辅助解释了部分命令，整体流程依然是我亲自把关的。
目前我已经根据这个流程提交了数次开源项目的PR，其中有些已经通过审核，确认整个流程无误，大家可以按照流程放心食用。