引言
版本控制是开发中不可或缺的一部分，他允许多人同时协作，通过记录每一次代码的变更，帮助开发者理解何时、为什么以及谁做了修改。这不仅有助于错误追踪和功能回溯，还使得团队能够并行工作，通过分支管理实现功能的增加和问题的修复。此外，也允许开发者在出现问题时回滚到之前的状态，确保项目的稳定发展。
1. 分支命名策略
主要分支命名
main或master：项目的主分支，存放正式发布的版本。develop：开发分支，用于日常开发阶段验证新功能，此分支不会推送至生产环境；且由于脏代码的堆积，偶尔需要重建下。
功能性分支命名
以一种结构化的方法命名，如<类型>/<版本>/<描述>，例如：fix/v1.0.0/authentication。这里的版本可根据实际情况决定，可以是 v1.0.0，也可以是 v1.0、v1、1.0.0 等。
feature/<版本>/<功能>：用于开发新功能的分支，例如：feature/v1.0.0/authentication。fix/<版本>/<问题描述>：修复特定版本中的错误，例如：fix/v1.0.0/login。
其他类型名：docs、refactor、test 等。
这样命名的好处是，面对 SourceTree 这样的图形化客户端时，可以清晰的看清项目的版本迭代记录。
注：由于不同的规范和风格，这里的分隔符也常使用下划线，例如：feature_v1.0.0_authentication。
特定目的或临时性分支命名
release/<版本>：用于准备发布的版本，允许进行最后的调整，例如：release/v1.0.0。hotfix/<版本>/<问题描述>：用于紧急修复生产环境中的问题，例如：hotfix/v1.0.0/payment。
个人或团队工作分支命名
<用户>/<类型>/<版本>/<描述>：个人工作分支，明确指出负责人和工作内容，例如：john/fix/v1.0.0/login-issue。team/<团队>/<类型>/<版本>/<描述>：团队工作分支，有助于区分不同团队的工作，例如：team/account/feature/v1.0.0/add-nickname。
分支命名策略的重要性
- 清晰性：良好的命名策略可以快速告诉其他人这个分支的目的和内容。
- 组织性：有助于在大型项目中管理和维护众多的分支。
- 自动化：一些自动化工具和 CI/CD 流程可以根据分支命名模式自动执行特定任务。
案例项目：https://github.com/mazeyqian/mazey/actions
2. 代码提交规范
一个良好的提交信息能够让其他人快速理解这次提交的目的，以及它对项目产生的影响。以下是一个推荐的代码提交规范格式：
():
fix）、添加新功能（feature）还是文档变更（docs）等；login、userModel、docs等；
类型（type）
常见的提交类型包括：
feat：新增功能（feature）；fix：修补 Bug；docs：文档变更；style： 格式（不影响代码运行的变动）；refactor：重构（即不是新增功能，也不是修改 Bug 的代码变动）；test：增加测试；chore：构建过程或辅助工具的变动。
主题（subject）
主题是对 Commit 目的的简短描述，不超过 50 个字符，建议使用现在时态和小写字母，并且不以句号结尾，例如：
feat(login): add captcha to login formfix(userModel): correct age calculation logicdocs(readme): update installation instructions
案例项目：https://github.com/mazeyqian/mazey
3. Merge Request（MR）的实践
Merge Request（MR）或 Pull Request（PR）是代码审查和合并的重要环节。它不仅涉及代码的合并，还可以帮助团队成员之间进行沟通、提供反馈和确保代码质量。
清晰明确的标题
- 明确模块或功能：如果可能，指明 MR 影响的具体模块或功能，使得标题更加具体，例如：
feat(user): 添加用户登录功能或fix(database): 解决并发访问时的数据不一致问题。 - 关联 Issue：如果 MR 与特定的 Issue 相关，可以在标题中直接提及该 Issue，例如使用
Close #1表示此次 MR 旨在解决编号为 1 的 Issue。这不仅能够提供更多上下文信息，还可以在某些平台上自动关闭相关的 Issue。 - 使用标签：在标题中使用标签（例如：
feat、fix、docs等）来标明 MR 的类型，这有助于快速了解 MR 的性质。
案例项目：https://github.com/tzfqh/gmdtable
详细的描述
对 MR 进行详细说明的部分，应该包含所有必要的信息，以便理解这次提交的背景、目的和具体实现。
- 背景和目的：首先简要说明为什么需要这次改动，他解决了什么问题或带来了哪些新功能。
- 完成的任务清单：提供一个清单，列出了此次 MR 完成了哪些具体任务。这有助于跟踪 MR 的进度和范围。
- 变更说明：详细描述代码变更的内容，包括新增、修改或删除了哪些功能或模块。
- 测试和验证：说明已经进行了哪些测试或验证步骤来确保代码的质量和功能的正确性。
- 额外信息：如有必要，可以添加如何配置新功能、影响的用户或系统部分、未来规划等额外信息。
例如：
Title: feat(login): 添加验证码功能 (Close #1)
Description:
实现了在用户登录流程中添加验证码功能，旨在增强系统安全性。
已完成的任务：
- 设计并实现验证码生成逻辑
- 在登录表单中集成验证码输入字段
- 实现验证码验证逻辑
- 更新相关文档和测试用例
此次改动通过了所有单元测试，并在本地环境中进行了手动测试验证，确保新加入的验证码功能正常工作。
关联 Issue：#1
4. 打标签
打标签（Tagging）是一种标记特定版本的方法，他允许在项目的历史中快速定位到某个点。
打轻量标签
轻量标签（Lightweight Tag）是指向某个提交对象的引用，他就像一个不会改变的分支。创建轻量标签不会存储额外的信息（如标签创建者、邮箱、创建日期等）。如果只是为了快速记住某个提交点，可以使用轻量标签。
git tag
示例：
git tag v1.0.0 abc1234
打注释标签
注释标签（Annotated Tag）会存储额外的信息，比如创建者的名字、电子邮件地址、日期和标签信息。
git tag -a -m ""
-a：表示创建一个注释标签；-m：后面跟随的是这个标签的信息；
示例：
git tag -a v1.0.1 -m "Release version 1.0.1 with minor bug fixes" abc1234
推送标签到远程仓库
默认情况下，git push 命令不会将标签推送到远程仓库，需要显式地推送标签。
推送特定标签：
git push origin
示例：
git push origin v1.0.0
推送所有本地标签：
git push origin --tags
5. 遇到问题使用 git revert 回滚
git revert 是用于撤销之前提交的变更的命令，git revert 的操作是通过创建一个新的提交来实现的，这个新提交是对旧提交的直接反转，即他会引入与旧提交相反的变更。这样做的好处是它不会改变项目历史。
命令语法
git revert
这里
操作流程
- 找到你想要撤销的提交的哈希值，可以通过
git log查看提交历史； - 执行
git revert命令并指定相应的哈希值； - Git 会创建一个新的提交，这个提交会撤销指定提交所做的所有变更；
- 如果有冲突，解决完冲突才能完成
revert操作。
使用场景
git revert 是在不打乱项目历史的情况下撤销变更的安全方式。例如，如果一个已经发布到生产环境中的提交引入了一个严重错误，使用 git revert 可以快速地撤销这个提交带来的影响，同时保留了完整的项目历史。
与 git reset 的区别
git reset 也可以用来撤销变更，但他通过移动分支指针到旧的提交来实现，这会改变项目历史。
总结
版本控制是软件开发的核心，促进团队协作与项目管理。通过制定明确的分支命名策略（例如：main、develop、feature/<版本>/<功能> 等），遵循一致的代码提交规范，如指明提交类型和简短描述，增强了历史记录的可读性，可以清晰地组织和理解项目的结构与进展。
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者后除和本文原始地址：https://blog.mazey.net/4581.html
（完）