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