一、主要分支介绍
master：正式版本；线上运行版本；
dev：最新的下次发布状态，包含测试中的新功能，可能存在bug；
feature：该分支一般用来表示开发新功能；一般情况下feature生命周期不超过一周。
bugfix：该分支主要用于修补master分支上出现的问题，即线上突发问题。
二、常用操作步骤
1. 开发新功能
- 基于
dev分支创建一个新的feature分支，在feature分支上进行开发 - 开发完成后，合并
featrue分支到dev分支上，测试人员开始测试。
* 此处合并feature到dev分支上，建议提交 Pull Request 并指定reviews进行Code Review后，使用Github平台能力进行合并
* Code Review的原则：主要review代码规范，业务逻辑次要
- 测试完成后，合并
dev分支到master分支，并删除feature分支。
* 向master分支合并代码，原则上必须有Teambition对应的迭代版本号；
* 向master分支合并代码，添加标签，例如[Ver1.1.1.5 登录功能改造]
* 向master分支合并代码，依然建议采用 Pull Request 的形式，而不是直接分支合并的方式。
2. 修复线上BUG
- 基于
master分支创建bugfix分支，在bugfix分支上排查并修复bug； - 修复完成后，合并bugfix到master分支上，开始测试；
* 若此时dev和master完全一致，则先合并到dev分支验证无误后合并到master
* 若此时dev有更超前的功能在验证中，为了避免因为修复bug而把其他暂不需要上线或暂不满足上线条件的功能一起上线，
因此bugfix直接合并到master分支，通过本地模拟或正式环境验证等方式，进行测试
- 测试无误后，
dev拉取master代码，修复dev上的同个问题，继续其他功能开发，最终删除bugfix分支。
3. 合并冲突
- 当
feature合并到dev遇到冲突时，首先将dev合并到本地feature分支
* Github平台执行Pull Request时，会先检测是否满足合并条件，若有冲突也会给予提醒
* 该冲突产生的原因大概率为：其他开发人员更早地提交了其他feature功能，且两者都存在对共同文件的修改。
- 在本地将冲突文件人工合并后，再次提交解决冲突后的文件（此时该文件已包含该
feature最新功能和dev最新功能） - 此时feature已满足合并dev的条件（Pull Request中也会显示为绿色按钮可合并）
三、实操
约有三种方式执行上述流程，推荐指数为 3 > 2 > 1
1. 人工操作
- 创建feature和bugfix分支均为人工命名、人工创建。
- 从dev和master向下合并均人为控制合并
- 向dev和master合并均采用Pull Request形式
2. git-flow命令行
Mac系统安装git-flow
brew install git-flow
//先将远程仓库克隆到本地。
git clone <project_url>
//初始化Gitflow配置
git flow init
//新功能开始开发前，需准备好开发分支。
git flow feature start <feature_name>
实质上等价于 git checkout -b feature/<feature_name> develop
在本地开发完成新功能并commit后，需要将本地代码push到远程仓库。
git flow feature publish <feature_name>
如果已经执行过publish后又有新的代码需push，再次执行将报错，因为它始终会试图创建一个远程分支。
此时需执行正常的push命令git push origin
当功能开发完毕后就将进入测试阶段，此时需将一个或多个feature分支统一合并到develop分支。
git flow feature finish <feature_name>
这行指令做了三件事。
①切换到develop分支；②合并代码到develop分支；③删除本地feature/<feature_name>分支。
此步骤也可采用人工提交Pull Request的方式执行，便于Code Review
3. SourceTree可视化工具
此种方式最为推荐，操作简单明了。
- 初始化仓库，顶部菜单栏仓库，选择git flow
- 开发新功能 / 修复Bug
- 完成功能开发
- 发布release版本
四、其他规范
- 原则上，禁止在
dev分支和master分支上直接修改代码； - feature 分支命名一般为 功能名称，此处约定为feature/功能姓名日期，例如feature/login_xt_20210130
- commit message尽可能通俗地描述功能，不允许出现过于简短或无意义的描述，例如”update”、“部分更新”、”暂时提交”等。
五、待改善方面
release分支的使用，目前dev担任了测试版本和发布版本的2个角色。fork的形式，为了避免多人对主仓库的直接操作，每个开发人员可将主仓库fork到个人仓库一份，然后将单独将主仓库添加为源。（此时该仓库拥有2个源），主仓库源只能向下拉取，向主仓库合并代码采用Pull Request形式。- 标签签名的使用，即为标签添加详细的修改内容介绍，类似备注信息。
