前言

一直使用svn版本管理，现在大多数公司都在用git作为版本管理工具。因此有必要简单了解一下git的常规使用，在以后用到git时，不至于盲目抓瞎，一脸懵逼。

一、对于分布式版本管理的理解

之前用的svn是集中式版本管理。代码中央仓库在某个服务器上，开发人员在自己电脑上拉取代码，进行开发，然后提交到中央仓库服务器。提交记录都保存在中央仓库服务器上。一旦中央仓库服务器挂掉了，就无法进行提交操作和提交记录的查看。

所谓的分布式版本管理就是，在每个开发人员的本地，存放着一个本地仓库，本地仓库里存放着历次提交的代码和提交记录等等信息。当一个开发人员的电脑挂了之后，完全不影响其他人员的开发，因为其他人员电脑上都有一个本地中央仓库。

起初，对上面这种分布式版本管理的说法，一直持有怀疑态度。因为每个人电脑上都有一个本地的中央仓库，那么不同人之间的代码交换，肯定得有一个远程的中央服务器吧，在git中，一般使用github、gitee或者自己搭建的gitlab作为远程中央仓库。既然有了远程中央仓库的概念，那不还是集中式管理吗，谈何分布式管理呢？

可以这样理解：远程中央仓库是用来进行不同开发者之间代码交换的。在远程仓库拉取代码时，不仅仅拉取代码信息，会把历次的提交记录等等信息，都会拉取到本地仓库中。此时本地仓库和中央仓库就是完全同步的。当中央仓库挂了之后，本地仓库照样可以进行提交，使用。所以，分布式版本控制，是对每个开发者个人而言，不受远程仓库的影响，可以继续开发自己的功能。但是对于不同开发者之间交换代码，远程仓库挂了之后，还是有影响的。

有博客写不通过远程仓库，不同电脑之间直接相互交换代码也可以。这种操作没有试过，而且如果一个项目开发人员多的话，两两之间交换代码也不现实。

二、git相关设置

用户名邮箱配置

安装好git后，首先要设置git的用户名和邮箱，这个相当于是账号信息，每次提交代码的时候，显示用户名来区分谁提交的代码。

SSH免密设置

可以用Git Bash命令工具生成公钥和私钥，生成在C/Users/当前用户/.ssh文件夹中，带有.pub后缀的是公钥，另一个文件是私钥。
在远程代码仓库中(github、gitee、gitlab)配置公钥，这样，在通过SSH方式拉取代码，提交代码，都是免密，直接操作的。每个开发都要生成自己的公钥和私钥，并把公钥配置到远程仓库中。

HTTP方式拉取代码无法设置成免密的。如果用HTTP方式拉取代码，每次拉取和提交代码，都需要输入远程仓库的用户名和密码才行。对于多人开发项目而言，把远程管理仓库的用户名和密码告诉每个开发显然是不合适的。因此推荐使用每个人自己的公钥私钥进行免密操作。

远程仓库

国外的github,国内的gitee(码云)都是git代码托管中心可供选择。当然大多公司是通过gitlab自己搭建远程仓库中心。关于gitlab的使用和操作这里不再过多描述。

三、git工作机制

工作区就是项目的工作空间。执行git add . 命令，可以将代码提交到暂存区，提交到暂存区的代码，执行git commit命令，提交到本地仓库。这个本地仓库就是每个开发个人的一个仓库管理中心。
个人本地仓库的代码，通过git push命令，可以推送到远程中央仓库上。相应的，个人也可以通过git pull命令，拉取远程仓库的代码到本地仓库中。本地仓库的代码在传给暂存区，然后再传到工作空间中，是一个提交代码的逆序。

四、git在idea中使用

从远程仓库拉取代码

本人习惯先用GitBash命令执行git clone命令从远程拉取代码下来，然后再通过idea打开。

创建分支

可以在远程代码仓库手动创建分支，也可以在idea中创建分支，然后提交到远程仓库中。

创建分支，默认从master中copy一份代码到新的分支中。此时，点击pull可以将分支提交到远程仓库中。

提交后，在远程分支上也会显示新创建的分支。

代码提交日志

在新建的dev分支中修改代码，并进行两次本地仓库的commit操作，查看提交日志，如下：

执行commit提交到本地仓库，在远程仓库的dev分支中，没有任何提交记录，如下图所示：

点击idea中pull按钮，进行远程仓库提交，提交后远程dev分支也会有两条提交记录：

五、分支代码合并

在dev分支开发完后，想要将代码合并到主线master上，首先，点击idea右下角的dev分支，切换为master分支，点击check out按钮进行分支切换，如下图所示:

跟svn使用习惯一样，切换分支后，首先执行update操作，更新代码。然后我们要把dev分支合并到master，所以点击dev分支，然后选择Merge into Current按钮，进行合并，如下图：

此时master中就合并了dev分支中的代码。我们看master中的提交记录:

可以看到master中也有了dev中的两次提交日志。此时master是本地仓库合并了代码，可以执行pull命令推送到远程仓库中。

注意： 要往哪个分支合并代码，就切换到哪个分支上。要合并哪个分支的代码，就选择哪个分支，然后点击Merege into Current按钮。

六、rebase和merge区别

rebase

如上图所示，master在commit4节点分离出了dev分支，在dev分支进行了两次提交，分别为commit7和commit8。在dev分支上执行rebase操作后，dev分支变成了从master的最新节点commit6中分离出来了，并且还保留了commit7和commit8两个节点。

rebase操作其实就是将某个分支的代码，更新到其母分支代码的最新版本，并且保留自己分支的原有代码。常常应用于其他分支更新master分支的代码中。

merge

上图是merge示例。dev分支在master分支的commit4分离出来，并进行了commit7和commit8两次提交，同时，在master分支上，也进行了commit5和commit6两次提交。如果此时在dev分支上执行merge操作，合并master分支的代码，那么master上的commit5和commit6两个节点就会合并到dev节点，并且生成一个新的节点commit9。

由此可以看到，进行rebase操作时，是dev分支的指针从commit4移动到commit6，然后再连接commit7和commit8。顺序是先提交了commit5和commit6，再执行commit7和commit8。而执行merge操作，是dev的指针不变，将master分支的commit5和commit6形成一个新的节点放在dev最后面，顺序先是commit7和commit8，然后是commit5和commit6。很明显，如果在dev上使用merge操作，就打乱了master主线提交顺序，所以，一般子分支更新代码，都有rebase。

还按上面这张图说，如果在master分支执行merge，会发生什么情况呢？那就是将dev的代码合并到master分支中。此时，会将commit7和commit8形成一个新节点，放到master节点最后，在master分支上形成一个新节点。这是符合我们预期的。因为最终最新的代码都要合并到master分支上。所以，master分支上的合并都要用merge。

那么master分支执行rebase操作，会是什么情况呢?那就会把master分支上的操作，都顶到子分支提交的commit7和commit8后面了，这个顺序乱的更离谱了，而且是将master提交顺序搞乱了，很严重。所以，master分支(功能分支，即最终合并代码的分支)只能用merge操作，不能用rebase操作。

总结

1.公共分支上选择merge(新功能整合到master上)
2.功能分支上选择rebase主分支(和公共分支同步，把自己代码提交到最后)
3.功能分支上选择merge(把别的分支加到自己身上，如果不介意顺序)
4.切记不要再公共分支上rebase任何分支

本地和远程对应同一个分支，优先使用rebase而不是merge

比如，我们在本地dev分支中，点击更新项目，拉取远程dev分支的代码，有时会出现如下图界面:

本地分支和远程分支明明都是dev分支，为何还有选择merge还是rebase呢？
因为本地dev分支和远程dev分支本质是两条分支。我们在pull远程dev分支时，可能其他人员对dev分支也有过提交记录。那么执行pull操作时，新更新下来的代码，是放在我们本地仓库后面呢，还是放在我们本地仓库之前呢？
这就又涉及到是merge还是rebase的问题了。选择rebase是将我们本地提交的记录推到最后面，把远程dev提交记录推到前面，这也符合我们的提交顺序，所以优先选择rebase。

案例

在dev分支上，再进行两次提交，如下图所示:

此时，在master分支上，也进行两次提交，如下图:

此时master分支和dev分支就分叉了。如果这时，我们要将dev分支代码合并到master分支，该如何操作呢？
首先master分支合并dev分支，相当于是dev分支代码要提交到master分支。遵循先更新后提交的原则，此时我们需要将dev分支更新到master最新的代码，才可以提交他自己的部分到master。所以，要先在dev分支执行rebase操作，更新最新的master代码到dev中。
切换到dev分支，然后选中master分支，点击Rebase Current onto Selected进行rebase操作，如下图:

在rebase操作时，可能会发生冲突，因为可能master的最新代码改动和dev分支我们代码的改动可能在同一个位置，发生冲突后，按照svn的方式解决冲突即可。该合并合并，该删除删除，解决完冲突后，再继续rebase操作。
rebase操作后，dev分支的操作就被推到了最后，master分支的记录被提到了前面，如下图所示:

此时，可以在master上进行merge操作。切换到master分支，然后进行merge操作即可。
遵循上面的操作，master分支和dev分支的提交记录都是一条直线，因为dev分支先执行了rebase操作，保证了最新master的最新代码与dev同步，然后再在master执行merge，是严格按照顺序来的，所以是一条直线。

如果在master合并dev分支时，dev分支没有进行rebase操作，情况如何呢？最终生成的master日志图如下所示:

可以看到此时的日志也出现了分叉，不是单独的一条直线了，这是为何呢？
如上图所示，直线就是master分支的提交节点。蓝线是dev分支。因为我们没有在dev分支执行rebase操作，所以，此时dev分支开始节点还在dev第六次提交那个节点。此后，dev分支执行了两次commit操作，分别为dev第七次提交和dev第八次提交。master也执行了两次commit操作，为master第五次提交和master第六次提交。此时，在master分支执行了merge操作，合并dev分支代码，那么dev分支的两次commit操作，就会新生成一个节点，合并到master分支最后，即上图的Merege branch 'dev’节点。所以，出现了分叉。

此后，dev分支如果一直不执行rebase操作，那么master分支和dev分支就是两条平行的分支，各自开发各自的东西。当某个节点时，master分支进行一次merge操作，将dev代码合并进来。而dev分支不再有master分支的代码进来。

分析

一般在实际开发中，都是在dev分支进行开发，所有人都在dev分支中更新代码，提交代码。每个人可以在自己本地仓库创建自己的仓库进行开发，开发完成后，在dev分支进行代码合并，然后传到远程dev分支。至于dev分支到master分支的合并，是由专门的项目负责人在项目没问题的情况下，进行master分支的merge操作。因此，一般情况下，dev分支和master分支提交记录一直是一条直线的情况，才是最合理，最简便的。

七、tag功能

tag是某个版本的说明。在commit时，节点是一直往后推进的。而tag是单独定义固定的某个节点为一个版本。以后使用这个tag时，就是这个版本的代码，不会再往后进行更新了。一般在里程碑阶段的时候可以打一个tag，来存储当时状态的代码。

八、其他

git还有很多功能，比如版本的回退，rebase或merge的回退，在实际应用中都很常见。因为是刚刚入门学习，这些操作暂时不再进行研究，以后有机会实操git，遇到这些问题了，再查找相应解决方案。