05 Git的分支管理策略-Gitflow，基于GitLab演示feature、develop、release、hotfixes branch_git feature branch

总体概览

先以GitLab上的一张经典的图打头，作为一个总体概览，也方便理解分支的管理和走向：

场景预设

现假设公司有名为Hogwarts_Online2的开发项目，其中包含了上线分支master，开发分支develop，测试分支release，和个人开发的特性分支<feature branch>

1、特性分支与develop分支

• 1.1）与远程仓库建立连接，在本地创建自己的分支，并拉取develop分支的文件：

#与远程仓库建立连接
git remote add origin ssh://git@47.95.xxx.xx:10022/root/hogwarts_online2.git
#拉取develop分支的文件
git clone -b develop ssh://git@47.95.xxx.xx:10022/root/hogwarts_online2.git
#创建自己的分支
cd hogwarts_online2/
git checkout -b gitflowDemo
1
2
3
4
5
6
7

• 1.2）在当前分支中创建新的文件gitflowDemo.txt，输入内容“study git”；然后add,commit

#修改分支
vi gitflowDemo.txt
#提交修改
git add gitflowDemo.txt
git commit -m "add demo"
1
2
3
4
5

• 1.3） 通过git pull命令检查远程develop分支是否和当前分支有冲突：

$ git pull origin develop
From ssh://47.95.238.18:10022/root/hogwarts_online2
 * branch            develop    -> FETCH_HEAD
Already up to date.
1
2
3
4

注： push之前先拉去远程代码，以防在开发过程中，远程被别人更新过新版本代码。如有代码冲突，两人协商冲突解决办法。多人开发的时候，冲突是不可避免的。

• 1.4) git push将修改推至远程特性分支origin gitflowDemo：

$ git push origin gitflowDemo
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 274 bytes | 274.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote:
remote: To create a merge request for gitflowDemo, visit:
remote:   http://47.95.xxx.xx/root/hogwarts_online2/merge_requests/new?merge_request%5Bsource_branch%5D=gitflowDemo
remote:
To ssh://47.95.xxx.xx:10022/root/hogwarts_online2.git
 * [new branch]      gitflowDemo -> gitflowDemo
1
2
3
4
5
6
7
8
9
10
11
12
13

• 1.5) 在GitLab上进行merge request，并在develop分支上进行merge：
  如果想要撤回这次merge可用`git merge --abort`
  create merge request:
  
  选择develop分支：
  
  没有冲突，可直接merge：
  
  最终我们可以看到成功merge进develop分支中：
  
  我们还可以在graph中查看分支的走向：
  

这样，特性分支和develop分支的代码拉取与合并就完成了

另外，工作中develop分支可能是权限比较开放的，允许push的，这时候我们就可以在本地直接修改merge然后push到远程develop中

修改gitflowDemo.txt文件为

study git
update
1
2

add,commit,push

git add gitflowDemo.txt
git commit -m "update gitflowDemo.txt"
git push -u origin gitflowDemo
1
2
3

切换到本地develop分支，pull最新代码，merge本地gitflowDemo分支代码，push进远程develop分支

git checkout develop
git pull origin develop
git merge gitflowDemo
git push -u origin develop
1
2
3
4

这个是在GitLab上检查更新情况：

2、release分支

develop分支变动频繁，master分支属于上限版本，因此需要一个内测的分支版本，这个就是release分支了
具体的提交操作根据权限范围，和1中develop的操作一致。

3、hotfixes

有的时候出现的非常紧急的bug，需要立即修改上线，来不及在各个分支上进行merge测试了；这个就是就需要用hotfixes模式，建立一个bugfix分支，直接绕开其他分支，修改合并到master中。

注： 这种未经测试就上线的情况很危险，本人就遇见过；之前驻场在华为里工作的时候，组内一位开发同事修改了一两行的代码，觉得不会有问题就直接跳过了我们测试，通过别人直接上线发布了，当时我所在的组是GNSS组；结果直接导致一千多万台手机的定位功能有失效的风险，受到了很多投诉，影响很大；最终相关开发人员被紧急停止休假，我们测试组也十一加了七天班，为了这个小小的改动付出了不小的后果~

• 3.1) 建立bugfix分支，并修改文件push到远程分支：

git checkout master
git checkout -b bug_02fix

vi bugfix02.txt
fix bug02

git commit -a -m "bug_01 fix"
git push -u origin bug_01fix

git add bugfix02.txt
git commit -m "fix bug02"
git push origin bug_02fix
1
2
3
4
5
6
7
8
9
10
11
12

• 3.2) 这个时候检查GitLab，会发现多了一条从master分支拉出来的修改bug02的分支：
  
• 3.3）最后由最终的master权限拥有者来进行合并。
  
• 3.4）修改了bug直接上线master后，很有可能让master分支的修改已经领先其他分支了；这个时候就需要将其他分支更新，对master分支进行合并；同时将bugfix分支删除，尽量保证分支的整洁度。

4、补充

git log

git log --graph --all --decorate=short
git grep "pattern"  $(git rev-list --all)
git log f13297
1
2
3

rebase

变基，合并分支后可以将分支走向的基准线变更，在分支很多的时候，可以简化分支的展示，合并分支走向使流程看起来简洁一点

git checkout feature
git rebase master
1
2

与merge后的分支走向对比：

git checkout feature
git merge master
#或者写在一行
git merge feature master
1
2
3
4

此外，rebase还可以对提交的历史进行修改（不常用也不建议使用）

git rebase -i HEAD~2
1

注意： rebase的使用规则
1、不要在公用的分支上执行rebase
2、主要的分支进行保护

git diff

git diff
git diff HEAD~3
git diff master develop
1
2
3

常见diff工具：

• diff ——仅展示某一行的增加（+）或减少（-）
• vimdiff ——比diff看起来要更直接
• IDE ——强大的工具，展示清晰，使用方便

vimdiff bugfix01.txt bugfix02.txt
1

参考链接：

• git的基本使用流程 https://www.atlassian.com/git/tutorials/setting-up-a-repository
• 特性分支工作流 https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
• gitlab工作流 https://docs.gitlab.com/ee/workflow/gitlab_flow.html
• 多种工作流对比 https://www.atlassian.com/git/tutorials/comparing-workflows
• gitlab私服搭建 https://docs.gitlab.com/omnibus/docker/