Git：实际项目中如何使用Git做分支管理

前言：
一直都听说Git作为一个强大的版本管理工具，功能强大，但是实际开发的时候只是使用了其中的一些基本的功能，同时，其分支管理、合并策略等并不了解。借此机会，学习一番：

1.分支的作用
分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。
2.创建与合并分支
2.1原理介绍

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支

真是太神奇了，你看得出来有些提交是通过分支完成的吗？

======================================================
在实际开发中如何使用Git没有一个标准答案，使用方式也是各式各样，很多基本上都是把Git当SVN来用。下面介绍的是一种经过实践的运行比较良好的管理方式。
主分支

实际开发中，一个仓库（通常只放一个项目）主要存在两条主分支：master与develop分支。这个两个分支的生命周期是整个项目周期。就是说，自创建出来就不会删除，会随着项目的不断开发不断的往里面添加代码。master分支是创建git仓库时自动生成的，随即我们就会从master分支创建develop分支，如下图所示。

master：这个分支最为稳定，这个分支代表项目处于可发布的状态。

例如王二狗向master分支合并了代码，那就意味着王二狗完成了此项目的一个待发布的版本，项目经理可以认为，此项目已经准备好发布新版本了。所以master分支不是随随便便就可以签入代码的地方，只有计划发布的版本功能在develop分支上全部完成，而且测试没有问题了才会合并到master上。

develop：作为开发的分支，平行于master分支。

例如王二狗要开发一个注册功能，那么他就会从develop分支上创建一个feature分支 fb-register（后面讲），在fb-register分支上将注册功能完成后，将代码合并到develop分支上。这个fb-register就完成了它的使命，可以删除了。项目经理看王二狗效率很高啊，于是：“二狗你顺带把登录功能也做了吧”。二狗心中暗暗骂道：日了个狗的，但是任务还的正常做，二狗就会重复上面的步骤：从develop分支上新创建一个名为fb-login的分支，喝杯咖啡继续开发，1个小时后登录功能写好了，二狗又会将这个分支的代码合并回develop分支后将其删除。

通过以上分析可以发现，我们可以使用Git hook 脚本自动发布发布新的版本，具体就是每当有代码从develop分支合并到master分支的时候，脚本就会自动触发，编译发布新的版本。

支持分支

这些分支都是为了程序员协同开发，以及应对项目的各种需求而存在的。这些分支都是为了解决某一个具体的问题而设立，当这个问题解决后，代码会合并回主分支develop或者master后删除，一般我们会人为分出三种分支。

Feature branches：这种分支和我们程序员日常开发最为密切，称作功能分支。

必须从develop分支创建，完成后合并回develop分支

如下图所示。

具体事例可以参考上面王二狗完成登录注册功能时的做法。

Release branches：这个分支用来分布新版本。

从develop分支创建，完成后合并回develop与master分支。

这个分支上可以做一些非常小的bug修复，当然，你也可以禁止在这个分支做任何bug的修复工作，而只做版本发布的相关操作，例如设置版本号等操作，那样的话那些发现的小bug就必须放到下一个版本修复了。如果在这个分支上发现了大bug，那么也绝对不能在这个分支上改，需要Featrue分支上改，走正常的流程。

实例：王二狗开发完了登录注册功能后决定发一个版本V0.1，那么他先从develop分支上创建一个Release 分支release-v0.1，然后二狗在这个分支上把版本号等做了修改。正准备编译发布了，项目经理说：“二狗啊，你那个登录框好像向右偏移量1个像素，你可以调一下吗？”二狗心中有暗暗骂道：日了个狗，但是。。。你们懂得，功能还的正常改。不过二狗发现这个bug特别小，对项目其他部分不造成不可预知的问题，所以直接在release分支上改了，然后愉快的发布了版本1.0.版本上线后，二狗将这个分支分别合并回了develop与master分支，然后删除了这个分支。

Hotfix branches：这个分支主要为修复线上特别紧急的bug准备的。

必须从master分支创建，完成后合并回develop与master分支。

如下图所示：

这个分支主要是解决线上版本的紧急bug修复的，例如突然版本V0.1上有一个致命bug，必须修复。那么我们就可以从master 分支上发布这个版本那个时间点 例如 tag v0.1（一般代码发布后会及时在master上打tag），来创建一个 hotfix-v0.1.1的分支，然后在这个分支上改bug，然后发布新的版本。最后将代码合并回develop与master分支。

实例：某天夜里二狗正在和女朋友嘿咻呢，突然项目经理打来电话：“二狗啊，线上出了个大问题，大量用户无法登录，客服电话已经被打爆了，你紧急处理一下”。二狗心中默默骂道：日了个狗，然后就爬起来去改代码了。二狗先找到master分支上tag v0.1 的地方，然后新建了hotfix-v0.1.1 分支，默默的修bug去了。经过一个多小时的奋战，终于修复了，然后二狗改了版本号，发布了新版本。二狗将这个分支分别合并回了develop与master分支后删除了这个分支。终于搞定了，回头看看床上的女票已经进入了梦乡，二狗贼心不死，上前挑逗，此刻女票将满腹怨气集于一点，使出凌空一脚将其登于床下，随后甩一枕于二狗，二狗会意，趋客厅，抱枕卧于沙发。。。

总结图

上面的讲解最后汇成一张图

小结：
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：

转载地址：
https://blog.csdn.net/shufac/article/details/51778158
https://blog.csdn.net/shusheng0007/article/details/80791849