最近这段时间比较忙，好久没有更新博客了。趁着今天项目阶段性的完成，更新一篇。
在开发项目的时候，为了对我们的项目进行管理，就需要使用版本控制系统，版本控制系统就是在我们系统开发的过程中，项目每次版本的变更都会给我们保存下来。确保将来的某一个时间我们可以回退到之前的版本。本篇博文主要讲解目前使用广泛的 GIT。
一、为什么需要merge、rebase
GIT的基本操作比较简单，这里就不花时间将这些了。在多人共同开发过程中，往往会涉及到 merge操作和rebase操作，这段时间在开发过程中就遇到了这一问题，查看了网上的一些教程，感觉讲的云里雾里的。在学习了这方面的内容之后决定整理一下方便大家学习理解。
讲解这两个操作之前，需要先了解下为什么需要这两个操作。在做一些小的项目的时候，通常开发人员比较少。假如开发人员只有一个人的话，利用git管理就相当的方便。只有要将每次的修改使用git add添加到暂存区，git commit 提交到本地仓库，然后在使用git push推送到远程仓库。整个流程是一条没有分支的时间线。
但是随着项目慢慢复杂起来，开发项目的人员变为多个，为了方便项目的管理。开发人员就不应该在主分支上进行开发，master分支应该是我们项目的稳定版本。因此需要先将远程的代码pull下来，然后在本地建立自己的dev分支。在这个dev上进行开发，开发完成之后，在push到远程的dev上，请求合并到master分支。
下图为远程pull下来的代码，然后创建本地dev分支
现在问题来了，因为我们实现dev分支上进行开发的，最后我们代码开发完成之后，是需要合并到本地的主分支上的，然后在推送到远程的主分支上。==注意：实际公司开发过程并不是这样，远程的master分支一般开发人员没有权限进行推送，不然人人都能提交到master分支，那还得了。==这时候就需要merge操作了，它可以将本地的dev分支合并到master分支上。
还有一个问题，在我们进行上述操作的时候，很有其他的开发人员已经完成自己负责的功能，并将其推送到远程仓库合并到主分支，那么就会出现下图这种情况。这个时候你会发现，你本地的dev分支是基于版本三进行开发的，而在你开发的过程中，版本三已经需要更新为版本四了，你想让你的dev分支基于最新的master分支，此时就需要rebase操作。
#### 二、merge实例
- 切换dev分支
- dev分支下开发新功能，蓝色圈起来的为新加内容
- 切换到本地master分支，这时候发现time.txt文件中并没有dev分支中添加的内容
- 进行git merge融合
现在已经融合成功了，在master分支中的time.txt文件中已经可以看到dev中添加的内容了。如果远程master分支这段时间内没人提交，我们就可以直接将本地的master提交到远程的master分支。
三、rebase操作
关于rebase何时使用，上面已经讲解过了，下面通过一个案列来说明rebase的用法。假设我们现在的项目需要两个人开发，两人分别从远程仓库push到自己本地，然后基于push下来的这个分支进行开发。下图的time_Lc_dev和time_dev就代表两个不同的开发人员。
这两个开发人员基于相同的master分支进行开发
-
现在在time_Lc_dev开发人员开发还未完成的情况下，time_dev完成了自己的功能（添加了add.txt文件），并合并到本地的master，push到远程的仓库。
-
此时对于开发人员time_Lc_dev来说，他所开发的分支并不是基于最新的分支，并没有远程master仓库的add.txt文件。现在我们有两种选择，一个就是继续在我们的分支上继续开发，最后在合并到本地的master分支上，然后推送到远程master分支上，不出意外的话，应该会出现问题。另外一个选择就是进行rebase操作，对我们当前开发的分支（time_Lc_dev）进行变基，随后在进行开发，开发完成后，合并到本地master，然后push到远程仓库就可以。
下图为现在分支的状况，可以看出time_Lc_dev分支比master分支晚一个版本。
-
此时，如果我们不去理会目前的这种情况，继续在我们的分支上开发，开发完成之后，添加到本地master，然后向远程master分支提交的时候就会发生如下问题。这就是我们之前说的没有变基的后果，其实这个也简单，按照提示，先git pull下来，然后在进行git push提交就可以了。
至此，就完成了由于开发人员提交到远程分支时间不同而引起的冲突。但是这样会带来一个问题，就是会是我们的master时间线不在是一条单一的时间线，而是会出现分支。如下图所示，这样特别不方便项目后期的查看和管理。
- 不过这里我们有第二种选择，就是rebase操作，首先我们可以在我们本地的master分支下，利用git pull 命令，来确保我们本地的master保持最新，==注意：进行这个操作的时候千万不要使用git merge 将time_Lc_dev分支融合，那就没有意义了。==这一步并不会产生冲突，因为time_dev也是基于这个相同的master分支开发的。如下图所示，这是我们本地的master已经是最新了。
此时，我们本地的master分支和time_Lc_dev分支的关系如下
接下来，就是rebase操作了，将time_Lc_dev切换到最新的master分支下，这里需要注意的是：颐一定要切换到time_Lc_dev分支下进行操作。
现在就完成了变基操作，如下图所示：
然后time_Lc_dev开发人员开发完成之后，在切换到主分支，合并time_Lc_dev分支在进行提交。就会发现master并没有产生分支的情况。蓝色的线是之前融合产生的。
