合并请求 PR/MR

1. PR：Pull requests
2. MR：Merge Request
3. PR、MR 均代表合并请求，只是每个代码托管平台的叫法不同而已，如：
   1. 使用 PR 平台：
      1. GitHub：https://github.com/actions/checkout/pulls
      2. Gitee：https://gitee.com/gitee-community/opensource-guide/pulls
   2. 使用 MR 平台：
      1. GitLab：https://gitlab.com/gitlab-org/gitlab/-/merge_requests
4. 合并请求：开发者将代码变更请求合并到目标分支的过程。在合并请求的过程中：
   1. 合并的来源仓库和目标仓库可以是同一个仓库，例如：
      1. 基于某个 分支 A 开发一个新功能时、修复一个 bug 时，在此分支的基础上新建一个 分支 A1，用于提交响应的代码，在完成后， 创建一个从 分支 A1 到 分支 A 的合并，管理员（拥有 分支 A 合并权限的人员）审核并批准合并，这样就完成了一个合并请求了， 分支 A 就有了 分支 A1 新增的功能、修复的 bug 的代码了
      2. 开发下一个新功能、修复下一个 bug 时，创建 分支 A2 重复上述过程，周而复始
      3. 来源仓库和目标仓库相同：一般用于拥有原仓库部分（全部）权限的人员使用
   2. 合并的来源仓库和目标仓库也可以是不同的仓库，例如：

      1. 如果想要给一个没有权限的仓库提交推送代码，先 fork 仓库，即：克隆一份仓库到自己的账户下，需要注意的是， GitHub 为了节省磁盘空间，现已启用 fork 时默认只 fork 仓库的主分支

      2. 由于是修改别人的仓库代码并进行合并，需要按照仓库的规则进行操作， 要求一般写在 README.md、index.md、CONTRIBUTING.md 等内容中，注意阅读，比如内容包含：

         1. 非项目成员只能合并到 xxx 分支
         2. 合并时提交注释的前缀需要根据不同类型使用对应的前缀
         3. 合并前需要执行 xxx 命令 进行验证功能
         4. 最简单的做法就是克隆代码之后，看一下历史提交记录，或者在代码托管平台看一下已经通过的历史合并的规则
         5. 很多代码仓库设置了合并的规则，即：在创建合并时有固定的模板，请按照模板操作
         6. 代码合适要求，比如：java 项目可能使用了 spring-javaformat 格式，node 项目可能使用了自定义的 eslint 格式， 提交代码前记得格式化，不要等到提交了好几遍之后再进行和格式化（污染代码提交记录）

      3. 如果存在多次提交，建议合并时整理一个提交内容（手动整理或使用压缩合并，使用压缩合并时， 建议在合并时将核心提交内容填一份在合并请求中）

      4. 提交内容标题简介易懂，更多内容可以从第二三行开始写（提交的首行为提交标题）

         1. 标题开头个人建议使用 gitmoji.md： git emoji 是大家约定俗成的内容，各大代码托管平台都支持，用法示例：

            修复一个 bug

            :bug: 修正由于xxx情况下的xxx异常

            升级一个 依赖

            :arrow_up: mysql 从 8.0.33 升级到 8.3.0
            
            mysql 新坐标从 mysql:mysql-connector-java 修改为 com.mysql:mysql-connector-j

            修改错别字

            :pencil2: 修正文档中关于xxx的错别字

            上述提交内容中，提交标题使用两个英文 : 中加上一个单词（词组）组成，后面跟着一个空格，
            其中 :bug: 会被识别为一个虫子，:arrow_up: 会被识别为一个向上的箭头，:pencil2: 会被识别为一支笔，
            更多内容参见：https://gitee.com/xuxiaowei-com-cn/xuxiaowei-com-cn/raw/main/gitmoji.md

      5. 提交内容建议携带相关 议题 issues 的链接，代码托管仓库会自动识别，并在相关议题下方出现提交的链接（前人种树后人乘凉）

         1. 如果有多个链接，建议每行一个链接
         2. 考虑到代码可能被上传到多个代码托管平台，个人建议议题使用完整链接

      6. 每次合并的分支，只修改本次合并需要修改的内容，只添加本次合并添加的内容，多余的内容，一个空格都不要改，这样更容易通过。 不同的主题使用不同的合并处理，不要做大杂烩一锅炖

   3. 每次开发功能、修复 bug 时，均需要从要修改的分支创建一个新分支：因为合并请求只关心合并的起始分支和目标分支，不关心创建时间
      1. 如果创建合并的来源分支是 分支 A1，目标分支是 分支 A
      2. 创建合并时 分支 A1 提交了 2 次，如果这时合并，则有两个提交被合并到了 分支 A
      3. 在合并还未完成时，又向 分支 A1 提交了 3 次与此合并无关的代码，这时查看合并请求时，则存在 5 次提交， 且提交内容涉及多个功能或bug，造成合并请求内容混乱，要合并的提交记录存在于合并请求无关的内容， 造成审核困难、管理困难、回滚代码困难
      4. 即使合并完成后，下一次开发功能、修复 bug 也要新建一个分支：
         1. 合并请求的来源分支的名字会记录在合并的记录中
         2. 如果你要修复 bug-236，创建了一个分支 fix-bug-236，已经合并完成了，现在要修复 bug-244， 代码提交到 fix-bug-236 分支并合并，显然是不合适的
   4. 如果在创建合并时、或在创建合并后的目标分支代码有变动，出现了冲突，这时还请创建合并的作者及时解决冲突，避免管理员工作负担， 因为这次的合并的内容合并的作者最清楚
   5. 允许管理人员编辑来源分支：
      1. 有利于快速审核通过合并，如果存在部分代码存在格式问题、或有小范围的警告或错误，管理员可以修改合并来源分支，用于快速通过合并
   6. 如果条件允许，可以添加本次合并内容的测试代码，可用于快速验证该提交内容，可用于避免重复出现此 bug，可用于快速通过审核
   7. 如果不是修正源码中的注释、修改文档中的错别字 等问题，建议新建议题用于大家讨论，并在提交时加上此议题的链接
   8. 如果 fork 时间过久，你的仓库代码可能过时太久，请不要以过时太久的代码创建分支提交代码后进行 PR， 可能目标分支已经修改或容易出现冲突
      1. 如果自己 fork 的仓库没有自己的重要代码可以考虑删除后重新 fork
      2. 如果自己 fork 的仓库有自己的重要代码，可以将目标仓库的代码重新同步给自己 fork 的仓库，有些代码托管平台有此功能
         1. 手动操作：克隆目标仓库，切换到要修改的分支，修改仓库地址为自己 fork 的仓库地址，推送代码， 然后再自己仓库的对应分支新建一个分支提交代码
   9. 删除合并源分支：根据自身情况决定合并来源分支是否删除