记录开发过程中，提交代码仓库的一些经验总结（持续更新……）
仓库中各分支的职责
master分支：master分支是存放发布上线的代码的默认位置。当某个功能经过验证和测试后，将develop分支合并到master分支，并为该版本打上相应的标签（例如x.0.0，表示某个大版本的编号）。master分支应该是稳定且经过充分测试的代码。
develop分支：develop分支是整体开发功能的主要分支。在开发阶段，所有功能的开发工作都应提交到develop分支。在功能开发完成后，通过测试和验证后，将develop分支合并到master分支，使功能正式上线。
扩展：
- 除了master和develop分支外，还可以存在其他类型的分支，如feature分支、bugfix分支等。这些分支可以用于并行开发不同的功能或修复bug，并在开发完成后合并到develop分支。
- 开发团队通常采用分支策略，例如Git Flow或GitHub Flow，来管理不同分支之间的合并和发布流程，以确保代码质量和版本控制的有效管理。
- 主分支（如master或main）通常用于存放稳定的、可发布的代码，而开发分支（如develop）则用于整体功能的开发和集成。
- 通过使用不同的分支，可以实现并行开发、合理管理代码版本、隔离功能开发和修复等，从而提高团队的协作效率和代码质量。
- 重要的是，分支之间的合并应该经过适当的测试和验证，以确保代码的稳定性和功能的正确性。
清晰的Commit
- 使用明确的动词：在提交信息的开头使用明确的动词来描述你的更改。例如，使用 “添加”、”修复”、”更新”、”重构” 等词语，以便其他人可以快速了解你的更改类型。
- 保持简洁：提交信息应该简洁明了，尽量避免冗长的描述。使用简洁的语句来概括你的更改，并在需要时提供详细信息。
- 提供相关上下文：除了简洁的概述外，确保提交信息提供足够的上下文信息，以便其他人能够理解你的更改原因和意图。如果有相关的问题、需求或讨论，可以引用相关的编号或链接。
- 遵循团队或项目规范：根据你所在的团队或项目的规范，使用统一的提交格式和命名约定。这样可以帮助整个团队保持一致的提交信息风格，便于阅读和管理。
- 避免无意义的提交信息：提交信息应该有实际的意义，避免使用模糊或不相关的描述。确保你的提交信息传达了有用的信息，而不仅仅是表明你进行了一次提交。
- 使用标准的提交类型：参考常见的提交类型（如前面所示），选择最适合你更改类型的提交类型。这有助于其他人快速了解你的更改类型，并且在版本控制工具中进行过滤和分类。
- 审查和校对：在提交之前，花一些时间审查和校对你的提交信息。确保拼写正确、语法清晰，并且信息准确传达你的更改。
常见的提交格式实例：
当然，以下是一些常见的提交格式示例：
feat: 添加新功能或特性
1
feat: 添加用户注册功能
fix: 修复 bug
1
fix: 修复登录页面样式错位的 bug
docs: 更新文档
1
docs: 更新用户手册中的安装说明
style: 代码样式、格式调整
1
style: 格式化整个项目的代码风格
refactor: 重构代码，既不修复 bug 也不添加新功能
1
refactor: 重构用户管理模块的代码结构
test: 添加或修改测试代码
1
test: 添加用户注册页面的单元测试
chore: 构建过程或辅助工具的变动
1
chore: 更新构建脚本以支持新的依赖库
这一切的目的是为了让团队其他成员明确该提交所做的工作，同时也让自己回顾代码的时候明确自己的工作内容。