Git 分支策略

分支策略

本文所写的分支策略是作者在学习和工作中总结而来的，仅供学习使用，具体的实施要根据开发项目组的规定执行。

一.分支类型

不同项目组使用的分支策略和命名是不同的，大多数情况都是简写的命名。

master
  dev
  	hotfix-bug ID
    dev-test
    feat-xxx功能

主分支（Master/Main）

主分支通常是项目的主要分支，包含了稳定、可发布的代码。在很多项目中，主分支的名字可能是master或main。
在一些开源项目中，主分支上的代码通常是可发布的版本，任何时候都应该是稳定和可用的。
主分支即生产使用的分支，对应生产环境

开发分支（Develop Branch）

开发分支是一个集成所有特性的分支，用于整个团队协同开发。在一些工作流程中，开发分支也被称为集成分支（Integration Branch）。
特性分支合并到开发分支，而开发分支最终合并到主分支。
有些项目组会使用 dev 的预生产环境。

特性分支（Feature Branch）

特性分支用于开发新功能或者进行某个特定任务。当你要添加一个新功能时，最好在一个独立的分支上进行开发，而不是直接在开发分支上修改。
特性开发完成并通过测试，可以将特性分支合并回开发分支。
一旦开发分支发版到主分支上，特性分支需要删除。

发布分支（Release Branch）

发布分支用于准备发布新的版本。在发布前，你可能需要进行一些版本号的更新、文档的整理、构建和测试等工作，这些工作可以在发布分支上完成。
一旦准备好发布，可以将发布分支合并回主分支，并且可以在发布分支上打上版本标签。

修复分支（Hotfix Branch）

修复分支用于快速修复生产环境中的紧急问题，比如某个严重的 Bug。它允许你在修复问题的同时继续开发新的特性。
修复分支通常是从主分支中切出来的/预生产的开发分支切出，修复完成后需要将其合并回主分支/开发分支。

二.实际使用

下图是以6月发布两版（月中和月末）为例绘制的 git 分支策略示意图。

dev-test 测试分支，只允许做为目标分支合入，不允许任何一个分支拉取测试分支代码

三.语法规范

commit 语意

重点关注 feat、fix

值	描述
feat	写了一个新功能
fix	修复一个 Bug
docs	文档变更
style	代码格式修改
refactor	代码重构
perf	改善性能
test	测试
build	变更项目构建或外部依赖
ci	持续集成相关文件修改
chore	变更构建流程或辅助工具
revert	代码回退

feat,fix 示例

feat 规范

feat:[空格]功能描述
换行
对功能的具体描述
换行
对上线功能写的一些备注

feat: 用户签到功能

1.将用户签到的经纬度存入数据库
2.判断签到位置是否满足签到条件

当前功能后期可能整合到其他模块

fix 规范

fix(bug 的作用域):[空格] bug 任务名称 / bug ID

全局

fix(global): 用户提交表单后返回乱码

局部，可以作用域写修改的文件路径或 bug 编号

fix(MJYT-xxx): 用户提交表单后返回乱码

可以不写作用域

fix: 用户提交表单后返回乱码

好的分支策略和代码规范可以让程序员在维护自己代码时事半功倍。