Appearance
Git 工作流程
前言
网上有许多不同的 Git 工作流方案，但是实际上它们大多数也都从Gitflow逐步演化而来。所以本文将介绍的 Git 工作流当然也是基于Gitflow的，但也是我结合过去几年的工作经验总结与优化后的实践。
Gitflow相关文章
Git之GitFlow工作流: https://blog.csdn.net/sunyctf/article/details/130587970
使用 git-flow 自动化你的 git 分支工作流程: https://jeffkreeftmeijer.com/git-flow/
为什么要规范Git工作流？
规范 Git 工作流的主要目的是提高团队协作的效率，避免多人合作时候发生分支合并冲突，以及代码库的可维护性。具体原因包括：
1.减少冲突
规范的 Git 工作流能帮助团队成员明确地了解如何进行代码提交、分支管理等操作，避免多人同时修改同一部分代码导致冲突。通过分支管理策略，每个人的工作在各自的分支上进行，减少了对主分支的干扰，降低冲突风险。
2.提升协作效率
有了明确的分支策略和合并流程，团队成员可以平行开发，减少对他人工作的依赖。各自的功能开发可以在独立的分支上进行，不会干扰到其他人，开发和发布周期更加高效。
3.应对紧急修复
在规范的工作流下，紧急修复Bug分支（也叫Hotfix/补丁分支）可以在独立的分支上进行，快速处理线上问题，不会影响其他功能开发，同时保证修复后的代码可以安全地合并回主分支。
总结来说，规范 Git 工作流是为了保障团队开发过程中代码的质量、协作效率和项目可维护性，减少混乱，确保代码库的稳定性和清晰性。
分支管理
主分支
也叫生产分支，该分支意指保存已发布的稳定代码，任何代码合并到主分支都应经过严格测试。
1.分支命名规则
main或者master
2.作用
主分支版本发布时，一般由已经经过严格测试的开发分支或者严格测试后的bug分支进行合并而更新的，开发分支和bug分支一般都是从主分支上切出去的。
重要提示
任何时间，任何时候都不能直接修改主分支的代码。
发布分支
该分支的第一次创建应该是由第一个版本的开发分支派生而来。
1.分支命名规则
release
2.作用
用于发布前的准备和修正，也就是发布前的提测阶段，会以release分支代码为基准提测。一般由开发分支合并更新
重要提示
任何时间，任何时候严禁将release合并至主分支。因为release主要就是用来测试开发分支的，假如当有两个版本的开发分支dev_1和dev_2都已经开发好了并且合并在了release分支里也发起了测试，此时dev_1你测试好了并合并到了主分支，那dev_2怎么办？
开发分支
一般开发的新版本时，开发分支都是基于主分支下创建的
1.分支命名规则
针对中小型项目的开发分支命名规则为：pre_(master/main)_项目版本号_dev，pre是preliminary（准备阶段）的缩写，表示该分支为合并到主分支之前的过渡分支。
大型项目
一般项目比较大的时候，项目可能会产生多个大型模块和多个产品经理，每个大模块都有自己的版本号，所以这里可以进行区分：pre_(master/main)_模块名_版本号
2.作用 保存由功能分支完成的最新的开发代码，功能完成后，合并到该分支。优点就是可以基于该分支创建多个功能分支提供给团队里的其他成员一起共同协作。
警告提示
这个分支一般由主分支切出，该分支始终保持最新完成以及bug修复后的代码。因为一旦在release分支上测试完成，是要合并到主分支的。
功能分支
具体的功能开发，从开发分支上创建而来
1.分支命名规则
pre_master_模块名_版本号_功能名_开发者姓名简写
2.作用 主要是用来开发一个新的功能，一旦开发完成，我们合并回开发分支，然后提交合并请求到 release 分支进行提测，当有bug时再切回到该分支修改，完成后再合并再测试。
Bug/Hotfix 分支
修改bug，从主分支上创建而来。
1.分支命名规则
(master/main)_bugfix_模块名/功能名_开发者姓名简写
⭐️ bugfix 就是漏洞修复的意思。bug和Hotfix的结合名称。
2.作用
当我们在生产环境发现新的Bug时候，我们需要基于主分支创建一个bug分支，然后在bug分支上修复bug，完成后经测试再合并至主分支重新发版
合并提示
当完成这一套流程时，也不要忘记将bug分支修改的commit遴选出来合并至合适的开发分支。
详细解释： 假设main分支上已经发布了1.0版本，现在你还有一个2.0版本的开发分支在做迭代，然后线上的1.0版本出现了bug，你在bug分支修改完以后合并到了主分支上，但是你自己切出来的2.0开发分支依然还存在这个旧bug，为了解决这个问题就应该将修改的commit遴选出来合并到现在的2.0开发分支上。
但是切记不要将bug分支直接合并到开发分支。
Git工作流程图
提交规范
在代码提交时，统一的提交规范能够提高团队协作效率，帮助快速定位和追踪问题，形成可读的提交记录历史。请遵循以下标准：
1.Commit 信息格式
使用 type(scope): subject 结构进行提交，类型和作用域用来明确提交的内容和范围。 例：
feat: 添加了什么功能
fix: 解决了什么bug2.常见提交类型
- ✨ feat: 新功能
- 🐞 fix: 修复 Bug
- 📃 docs: 文档修改
- 🎨 style: 代码格式化调整（无逻辑修改）
- 🦄 refactor: 重构代码（非新增功能或修复）
- ✅ test: 添加或修改测试
- 🔧 build: 修改构建流程、依赖等
- 🚀 perf: 性能优化
- ⏪ revert: 回滚提交
Commit Type 参考内容
建议
提交信息简明扼要，内容最好限制在 50 个字符以内。
每次提交应该解决一个问题或功能。
请求合并
分支合并的时候应该严格按照Git工作流来进行，其中有可能会产生分支合并冲突的问题。比如pre_master_xx_dev请求合并至master时发生了冲突。那这种情况下应该怎么做？
INFO
第一步
从master分支切出一个分支命名为 conflict_源分支名_merge_目标分支名
命名示例 conflict_master_merge_pre_master_xx_dev
第二步
在新创建的 conflict 分支中，拉取并合并 pre_master_xx_dev 分支，并解决好冲突以后，再将该分支合并至主分支。
第三步
一旦合并完成并确认无误，就删除 conflict 分支，确保持分支结构简洁。
重要提示
严禁将pre_master_xx_dev分支作为源分支拉取master分支的代码处理合并冲突。这会导致pre_master_xx_dev分支上出现其他版本的代码。
版本控制
在版本控制中，大小版本号通常采用语义化版本号（Semantic Versioning）的方式来命名，通常遵循 Major.Minor.Patch 的格式，即 主版本号.次版本号.补丁版本号。这个结构有助于开发者和用户清楚地了解每个版本的变化性质和影响。
版本号结构
- 主版本号（Major）
表示重大变更，不向后兼容的更新。例如，添加了新的功能或对现有功能进行了较大的重构，可能会导致旧版本的代码无法正常运行。
- 次版本号（Minor）
表示向后兼容的新增功能。例如，添加了新的功能或特性，但不会影响现有功能的运行。
- 补丁版本号（Patch）
表示向后兼容的 bug 修复。通常用于修复发现的问题，而不会对功能做出重大调整。
其他标记
先行版本号（Pre-release）
表示这个版本是一个不稳定的版本，尚未正式发布。例如：1.0.0-alpha 或 1.0.0-beta。
版本标签（Build Metadata）
表示构建信息，一般用于标识某个构建或修订版。例如：1.0.0+build20
大版本号是否应向后兼容？
关于大版本号（Major Version）是否向后兼容，确实应当根据项目的实际要求来决定。按照 语义化版本控制（Semantic Versioning）的标准，大版本号的变化通常意味着不兼容的 API 变化，也就是项目或库的接口发生了与之前版本不兼容的更改。
然而，在实际项目中，是否严格遵守这个规则，取决于团队和项目的具体情况。有些项目在发布大版本时可能会进行较为全面的改动，而另一些项目，即使发布了大版本，也可能选择在一定程度上保持向后兼容，以减少对已有用户的影响。
Git Tag标签
在主分支发布新版本时，务必遵循规范创建版本 Tag 标签，以确保版本管理的清晰和可追溯性。
参考文章
语义化版本控制的权威参考：https://semver.org/
其他注意事项
代码提交频率
保持频繁的代码提交，避免一次性提交大量代码，这样子方便追踪问题。
遵循 “小步提交，大步合并” 的原则。
保持代码库干净
严禁提交未经测试或有问题的代码，任何时间都不应将有问题的代码直接合并至 master 分支。
分支清理
功能分支或 Bug 分支合并后应及时删除，以保持仓库整洁。