0


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

标签: git

本文转载自: https://blog.csdn.net/qq1309664161/article/details/126451906
版权归原作者 敲代码的小小酥 所有, 如有侵权,请联系我们删除。

“git入门使用详解”的评论:

还没有评论