Git实战（五）| 让工作更高效，搞定Git的分支管理

原副标题：Git两栖作战（五）| 让组织工作更高效率，搞掂Git的组成部分管理组织工作

上一则说到Git的组成部分管理组织工作Jalgaon，新浪网分拆和邻近地区分拆都展开了Jalgaon。即便：收歛是假把式。而只练不重新整理，根本无法是傻把式了。组成部分管理组织工作究竟怎样展开管理组织工作呢？

先以GitLab上的两张经典之作的图aes，做为两个整体概要，也方便快捷认知组成部分的管理组织工作和迈向：

情景默认

现假定子公司有名叫Hogwarts_Online2的合作开发工程项目，当中包涵了上架组成部分master，合作开发组成部分develop，试验组成部分release，和对个人合作开发的优点组成部分<feature branch>

优点组成部分与develop组成部分

1.1）与远距库房创建相连，在邻近地区创建他们的组成部分，并拉取develop组成部分的文档：

1.2）在现阶段组成部分中创建捷伊文档gitflowDemo.txt，输出文本“study git”；接着add,commit

#修正组成部分

vi gitflowDemo.txt

#提交修正

git add gitflowDemo.txt

git commit -m “add demo”

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.

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

1.4) git push将修正推至远距优点组成部分origin gitflowDemo：

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

add,commit,push

git add gitflowDemo.txt

git commit -m “update gitflowDemo.txt”

git push -u origin gitflowDemo

切换到邻近地区develop组成部分，pull最新代码，merge邻近地区gitflowDemo组成部分代码，push进远距develop组成部分

git checkout develop

git pull origin develop

git merge gitflowDemo

git push -u origin develop

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

release组成部分

develop组成部分变动频繁，master组成部分属于上限版本，因此需要两个内测的组成部分版本，这个就是release组成部分了

具体的提交操作根据权限范围，和1中develop的操作一致。

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

3.2) 这个时候检查GitLab，会发现多了一条从master组成部分拉出来的修正bug02的组成部分：