git入门使用详解

前言

一直使用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遇到这些问题了再查找相应解决方案。