代码分支管理

分⽀种类
主分⽀（master）
开发分⽀（dev)
预发布分⽀（release）
功能分⽀（feature)
修复分⽀（hotfix）

Master：主分⽀，创建 Repository 时默认会⽣成⼀个 master 分⽀。通常情况下 master 分⽀是受保护的（Protected）。master 分⽀保存的是稳定的已发布到线上的代码，会使⽤ tag 来记录发布的版本（tag命名为：tag + “-” + “版本号”）。master 分⽀是不允许提交代码的，只能将代码合并（merge）到 master。

dev：开发分⽀，从 master 创建。需要注意的是，dev分⽀的代码是通过feature分⽀合并⽽来的。通常情况下我们是不会在 dev 上开发的，因为你不能确定这些是否需要上线（或者说⽆法确定在哪次迭代上线）。

Feature：功能分⽀，从 dev 创建。feature 分⽀是⽤来开发新功能的，通常情况下新功能开发完毕后会合并的 dev。

Release：预发布分⽀ 从 dev 创建。当⼀次迭代的功能开发并⾃测完成后，就可以创建发布分⽀。该分⽀通常⽤于测试，我们不能在该分⽀上完成除Bug 修复外的其他⼯作。测试完成后，我们需要将 release分⽀合并到 master 进⾏发布。发布完成后在 master 打上 tag 记录此次发布的版本。

Hotfix：修复分⽀，从 master 创建。当我们发现线上 Bug 时，会从 master 分⽀上对应的 tag 处创建新的 hotfix 分⽀，⽤来修复 bug。通常情况下，紧急修复的发布相对简单，在 Bug 修复并测试完成后，可直接合并到 master 进⾏发布（注意：如果在蓝绿部署的情况下，需要将bug修复之后的代码重新打包，并部署到蓝⾊环境下等待测试通过后，再将代码合并到master上）。发布完成后在 master打上 tag 记录此次发布的版本，并将 hotfix 合并到 dev。

分⽀命名规范
主分⽀（master）
预发布分⽀（release）：release-版本号
开发分⽀（dev)
修复分⽀（hotfix）： hotfix-禅道bug号(当前解决了的bug号)-⽇期(YYYYMMDD)
功能分⽀（feature)： feature-版本号 （ 暂不启⽤）

多⼈协作开发分⽀使⽤流程
在多⼈协作开发的情况下，所有分⽀需要全部上传到云仓库。
Master分⽀⽤来部署⽣产环境，release分⽀⽤来部署预发布环境。
Maste、release分⽀上严禁提交代码,只⽀持代码合并。
当⽣产环境发⽣紧急bug时，需要通过hotfix分⽀进⾏bug修复。 bug修复后将hotfix分⽀打包发布到预
发布环境，待测试通过后再将代码合并到master与dev分⽀上。
当预发布环境产⽣bug时，代表当前开发的功能版本存在缺陷。 bug修复在原dev分⽀上修复即可。
Bug修复后将代码依次合并到dev和release分⽀上。
Release⾄少要多保存⼀个版本。例如：当前Release分⽀在开发1.2功能需求，既当前Release分⽀名
称为Release-1.2，那么git仓库中release分⽀⾄少要留存release-1.1版本的分⽀。

Tag说明
tag是git版本库的⼀个标记，指向某个commit的指针，也就是说?tag是⼀些提交记录（commmit）
的集合。主要⽤于发布版本的管理，⼀个版本发布之后，我们可以为git打上 v.1.0 v.1.2 这样的标
签，按规范⼀般在master主分⽀打tag

分⽀管理应⽤场景
本地分⽀同远程分⽀进⾏关联
情形1：本地已经创建了分⽀dev（以dev为例），⽽远程没有(建议研发云上⾯直接操作，
同步添加分⽀权限)

⽅法1： git push -u origin dev 1
⽅法2： git push --set-upstream origin dev 

情形2：远程已经创建了分⽀dev,⽽本地没有

git pull origin dev //先将远程分⽀pull到本地
git checkout -b dev origin/dev //在本地创建分⽀并与之关联

分⽀合并
情形1: 将dev分⽀合并到master分⽀
假如我们现在在dev分⽀上，刚开发完项⽬，执⾏了下列命令：

git add .
git commit -m '提交的备注信息'
git push -u origin dev

合并操作如下：

git checkout master //先切换到master分⽀
git pull origin master //先pull再合并，以免冲突
git merge dev //把dev分⽀的代码合并到master上
git status //可选操作，查看状态
git push origin master //push到远程master上

冲突解决
情形⼀：未提交更新的时候发现冲突:pull→commit→push

1、本地修改量⼩

git revert -n 版本号
git pull
git commit → push //新代码后修改后提交推送

2、本地修改量⼤，冲突较多

git stash 先将本地修改存储起来
git pull 再次拉取代码
git stash pop 弹出本地修改修改，准备解决冲突
git pull → commit → push 解决冲突后提交

情形⼆：已提交更新的时候发现冲突（ push也报错，pull也报错，本地库和线上库的冲突 ）
1、修改量⼩，直接回退到未提交的版本

git reset --hard 版本号
git pull
git pull → commit → push

2、修改量⼤，直接merge，再提交（⽬前常⽤）

⼿动merge解决冲突
git commit -> push

代码回退
情景⼀：回退到某⼀版本

git log//查看HEAD⽇志
git reset --hard[⽬标版本号]//⽬标版本号为HEAD编号，⼀般输前⼏位就可
git push -f//将代码强制推送到远程仓库中

情景⼆：回退某⼀版本代码

git log //查看HEAD⽇志
git revert [要回退的版本号] //回退该版本代码并⽣成新的版本号
git status //查看本地变化的⽂件，是回退那个版本变化的⽂件，将其改回来了
git add . //提交代码到暂存区
git commit -m “” //提交代码到本地仓库
git push //上传到远程分⽀

代码库⾓⾊及分⼯


开发经理或代码管理员 ●
a. 创建新分⽀（创建代码库及默认仓库，新增功能分⽀及补丁分⽀等）
b. 确认合并请求是否合规，赋予开发⼈员release分⽀合并权限
c. 合并release分⽀代码到master分⽀分⽀
d. 对master分⽀创建Tag(⼀般对主分⽀进⾏打tag标记，区别应⽤程序版本)
e. 对master分⽀创建hotfix分⽀，赋予bug修复⼈分⽀权限，测试完成后合并代码到
master/dev分⽀
开发⼈员 ●
a. 提交代码到dev/hotfix分⽀
b. 发起合并到release分⽀请求
c. 合并代码到release分⽀

研发云代码仓库使⽤介绍(研发云使⽤说明)
1. 代码仓库新建，默认分⽀设置
2. 代码克隆
3. 代码分⽀新建
4. 仓库tag新建
5. 代码分⽀权限配置
6. 合并请求发起
7. 代码评审(⽬前情况下不建议使⽤此功能)补充操作说明*
git参考命令(待补充)
1. 本地分⽀对应哪个远程分⽀ git branch -vv