Git的分支

本文是基于Github Desktop来进行一些演示以及处理的，首先力推Github Desktop的原因是它操作简单，对使用者十分友好。如果对这款软件不熟悉的话建议先看一下这篇博客：
GitHub Desktop图文教程
里面有相当详细的操作介绍。而本文主要介绍的是对Git项目管理策略中分支的理解。

分支的概念

如上图所示，这是一个软件构造过程中分支的示例。有5条横线，每条横线代表一个分支。

实行分支策略的原因

当多人进行开发时，不同的模块可能由不同的负责团队进行开发，如果大家使用的是同一个分支的话（即不是用多分支构建的话），各个团队的工作可能会混淆在一起难以区分，甚至还会影响彼此的工作。而分支的出现就解决了这个问题，它相当于给两个团队（假设只有两个）两份独立的备份，也就是说团队1在进行更改的时候，不会对团队2的工作造成任何影响，当然如果团队2不把他们的工作提交上去，团队1也看不到团队2的工作内容。

常用的分支

1. master分支
   又称为主分支。我们在进行软件开发的时候有且只能有一个主分支，这个分支上一般只发布正式的版本。从示例图中可以看到，上面的每个点都是带了版本号的。
2. devlop分支
   又叫做开发分支，这个分支是我们进行开发的主要阵地。
3. release分支
   预发布分支，一些正式的软件在正式版本上线前会有预发布版本，提供给用户进行一些试用测试。
4. feature分支
   功能分支。尽管开发分支是我们进行开发的主要分支，但是细化到具体功能的实现时，要使用不同的功能分支来进行开发。这个过程在上图也有体现。

分支的具体理解

我们在进行开发时，每进行一步都要进行一次代码的存储。就像一个一个的节点一样。如果我们没有进行新分支的创建，就会一直在master分支上进行保存。如下图所示：

可以看到上图中除了有一个master指针以外，还有一个head指针，这个head指针代表的就是当前所处的分支。下面我们如果创建一个新的分支：

就会出现一个新的指针，同样指向当前的位置。如果我们在develop分支上进行开发的话，develop指针就会后移，而master指针却停留在远处不动。

有的人可能会问如果我改变develop的话，master分支之前的3个节点会改变吗。答案是不会。这里的每一个节点代表的是整个软件系统中的所有文件。每一个节点都囊括了之前所有的工程。我们所说的版本回滚实际上就是在节点上的回滚。
隐藏关卡：另外，每个节点实际上是有若干个指向的，指向各种不同的程序文件。在库中，不会有完全相同的两个文件，即我们所说的备份实际上是指向了之前上传的文件A。在我们做改动之前，他一直都会指向之前的文件A。如果我们对这个A改变成了B文件，此时库中就会多出一个文件B,哪怕A与B文件之间的差别仅有一个字节（当然你是把B文件commit了，所以我们一般都是在作出一定的改进之后才会commit一次，否则库中文件所占的空间就会增大）。下图的红色圈中看出有两个指针只想了同一个文件。

如果我们想要将develop的改变同步到master分支上的话，只需要将develop合并到master上。合并之后，就变成了下面的状态：

另外如果我们在两个分支中同时更改了一个文件A并commit了这个改动，一个分支把它改为文件B，另一个把它改成文件C，在合并到一起的过程中就会出现异常，因为当前的节点不清楚应该指向哪一个文件。此时就需要手动审视这两个改动，选择要留下的改动，并重新提交改动。