Git提交规范与合并提交规范背景：在使用 Git 进行提交时，遵循一定的提交规则有助于保持项目的整洁和可维护性。提交

提交规范

背景：在使用 Git 进行提交时，遵循一定的提交规则有助于保持项目的整洁和可维护性。

提交信息的格式
```
<类型>(<可选范围>): <简短的描述>

<可选的详细描述>

<可选的任务编号>
```
1.1. 提交信息的部分解释：
- 类型（type）：用于标识这次提交的目的，常见的类型有：
- feat：新增功能
- fix：修复问题
- docs：仅仅修改了文档
- style：代码格式修改，未改变代码逻辑
- refactor：代码重构
- test：添加测试
- chore：不修改 src 或测试文件的其他修改，比如构建流程、依赖管理
- perf：提升性能
- ci：CI 配置相关的修改
  - 范围（scope）：可选，用于说明影响的模块或文件。
    - 简短描述：尽量不超过 50 个字符，简明扼要地说明改动。
    - 详细描述：可选部分，用于更详细地说明改动。
    - 任务编号：可选，用于关联某个任务或 Issue 编号。
1.2. 示例提交信息：
```
feat(登录): 新增登录页面和登录的逻辑实现

创建了登录页面，实现了登录的业务逻辑，并且关联了路由守卫，加入了白名单

Issue #100
```
单次提交的粒度
- 确保每次提交都有明确的目的：避免提交过于庞大，每次提交应尽量解决单一问题或实现一个小功能。
- 小而频繁的提交：这样在追踪和回溯问题时更容易理解每次改动的意图。
避免提交敏感信息
- 确保提交中没有包含密码、API 密钥等敏感信息。如果不小心提交了，可以使用 git rebase 或 git reset 进行修改，但要注意同步团队的变动。
提交前的检查
- 确保代码能正常运行：提交前编译/构建代码并运行测试，确保功能正常。
- 代码格式检查：使用代码格式化工具确保代码风格统一。
Commitizen/Conventional Commits 规范
- 你可以使用工具如 Commitizen来自动生成符合 Conventional Commits规范的提交信息。这种工具可以帮助你在团队合作时保持一致的提交信息格式。
分支命名规则
- 分支命名同样有助于保持代码的清晰和可维护性，常见的命名方式：
  - feature/YYYYMMDD_<功能名称>：开发新功能
  - bugfix/YYYYMMDD_<bug描述>：修复特定 bug
  - hotfix/YYYYMMDD_<紧急修复>：紧急修复生产问题
  - release/YYYYMMDD_<版本号>：准备发布的分支

总结来说，遵循这些 Git 提交规则能够提高代码可读性、协作效率，以及后期维护的便捷性。

提交合并

查看当前状态
```
git status
```
在提交之前，首先查看你当前的工作区状态，确保没有未跟踪的文件或未提交的更改。
提交本地更改

如果有本地修改的代码，首先需要将这些更改提交到你的本地分支：
```
git add .
git commit -m "feat(登录页面):新增登录页面"
```
拉取远程分支的最新代码

在提交本地更改后，拉取远程分支的代码，确保本地分支是最新的。可以使用 git fetch 获取更新的代码，然后使用 git merge 合并：
```
git fetch origin
git merge origin/<远程分支名>
```

解决冲突（如有）

如果在合并过程中发生冲突，Git 会提示你。你需要手动解决这些冲突，打开冲突文件并修改，然后标记为已解决，完成后，使用以下命令提交合并结果：

git add <解决冲突的文件>
git commit -m "fix: resolve merge conflict between <分支A> and <分支B>

- 解决了以下文件的冲突：
  - <文件1>
  - <文件2>

相关更改：<描述冲突的原因和背景>"

推送到远程仓库

最后，将你的本地分支推送到远程仓库：
```
git push origin <你的本地分支>
```

总结

使用 git status 检查状态。
提交本地更改 (git add . 和 git commit -m ""fix: 信息")。
拉取并合并远程分支 (git fetch 和 git merge）。
解决冲突（如有），并提交合并结果。
推送到远程仓库。