如需引用请注明出处 WeiFong
1.总则
本文件用于确认技术部门Gitlab分支规范。
2.说明
本文件主要参考gitflow规范
3 分支说明
工作流使用2个分支来记录项目的历史：master，develop。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。feature-*分支用于不同项目的开发。
3.1 master分支：
存储了正式发布的历史。（所有提交分配版本号）。master分支上的所有提交均分配一个版本号。
3.2 develop分支：
作为功能的集成分支，集中feature-，hotfix-相关更新。也从develop分出新的feature分支。
3.3 feature分支（功能开发分支）
每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。
新功能提交应该从不直接与master分支交互。
3.4 Release分支
develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上。这个分支只应该做Bug修复、文档生成和其它面向发布任务。
一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。另外，这些从新建发布分支以来的做的修改要合并回develop分支。
使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。
这也打造定义良好的开发阶段（比如，可以很轻松地说，“这周我们要做准备发布版本4.0”，并且在仓库的目录结构中可以实际看到）。
3.5 维护分支或说是热修复（hotfix）
用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
4 操作：
4.1 创建开发分支（仅首次）
第一步为master分支配套一个develop分支。简单来做可以本地创建一个空的develop分支，push到服务器上：
git branch develop # 创建一个develop分支
git push -u origin develop # 将本地的develop分支推送到origin主机
以后这个分支将会包含了项目的全部历史，而master分支将只包含了部分历史。
4.2 Clone代码
其它开发者这时应该克隆中央仓库，建好develop分支的跟踪分支：
git clone ssh://user@host/path/to/repo.git # clone gitlab代码
git checkout -b develop origin/develop
现在每个开发都有了这些历史分支的本地拷贝。
4.3 新功能开发
开始开发新功能
- image.png
示例中，开发人员负责0.0.1和0.1.0功能的开发。需要为各自的功能创建相应的分支。新分支不是基于master分支，而是应该基于develop分支：
git checkout -b feature-0.0.1 develop # 从develop切出feature-0.0.1分支，并进入新分支
他们用老套路添加提交到各自功能分支上：编辑、暂存、提交：
git status # 查看当前git状态
git add # 将文件从工作区提交到暂存区
git commit # 将本地暂存区的文件提交到本地版本库
4.4 代码feature-0.0.1功能开发
- image.png
git pull origin develop # 拉取代码库代码，确保develop分支是最新
git checkout develop # 切换到develop分支
git merge feature-0.0.1 # 将feature-0.0.1合并到当前分支（develop）
git push # 将代码推动到代码仓库
git branch -d feature-0.0.1 # 删除feature-0.0.1分支
注意，功能决不应该直接合并到master分支。
4.5 版本0.0.1准备发布
- image.png
这个时候0.1.0正在继续开发，0.0.1开始准备项目正式发布。像功能开发一样，用一个新的分支来做发布准备。这一步也确定了发布的版本号：
git checkout -b release-0.0.1 develop # 从develop切出 release-0.0.1 分支，并进入新分支
这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，像是一个专门用于改善发布的功能分支。
根据测试需要，在该分支上打出AT1的tag，用以标识第1次测试。如果需要进行bug修复，则通过hotfix进行修复后，打出AT2的tag。
4.6 完成版本0.0.1功能发布
- image.png
一旦准备好了对外发布，合并release-0.0.1及其修改到master分支和develop分支上，删除release-0.0.1分支。合并回develop分支很重要，因为在发布分支中已经提交的更新需要在后面的新功能中也要是可用的。
如果团队要进行Code Review，这是发起Pull Request的理想时机。
git checkout master # 切换到master分支
git merge release-0.1 # 将release-0.0.1合并到当前分支（master）
git push # 将代码推动到代码仓库
git checkout develop # 切换到develop分支
git merge release-0.1 # 将release-0.0.1合并到当前分支（develop）
git push # 将代码推动到代码仓库
发布分支是作为功能开发（develop分支）和对外发布（master分支）间的缓冲。只要有合并到master分支，就应该打好Tag以方便跟踪。
git tag -a 0.0.1 -m "Version 0.0.1 publish" master # 给master打上0.0.1的标签，并加上标签说明`
git push –tags # 将本地标签推动到代码仓库
Git有提供各种勾子（hook），即仓库有事件发生时触发执行的脚本。可以配置一个勾子，在你push中央仓库的master分支时，自动构建好对外发布。
4.7 用户发现0.0.1版本Bug
- image.png
对外发布后，用户提出当前版本的一个Bug。为了立即处理Bug，从master分支上拉出了一个hotfix维护分支，提交修改以解决问题，然后直接合并回master分支：
git checkout -b hotfix-0.0.1 master # 从develop切出 release-0.0.1 分支，并进入新分支
- Bug修复后
git checkout master # 切换到master分支
git merge hotfix-0.0.1 # 将hotfix-0.0.1合并到当前分支（master）
git push # 将代码推动到代码仓库
- bug修复后的修改需要合并到develop分支中
git checkout develop # 切换到develop分支
git merge hotfix-0.0.1 # 将hotfix-0.0.1合并到当前分支（develop）
git push # 将代码推动到代码仓库
git branch -d hotfix-0.0.1 # 删除hotfix-0.0.1分支
- bug修复后，master需要增加tag标签（版本号第三位数字+1）
git tag -a 0.0.2 -m "Version 0.0.1 bug repair" master # 给master打上0.0.2的标签，并加上标签说明`
git push –tags # 将本地标签推动到代码仓库
补充
1.原dev_*分支逐步改为feature-*分支
2.原test分支逐步改为release-*分支
3.项目版本信息在项目初始阶段提供
