首页 > 其他 > 详细

从不同使用场景来介绍git的基础命令

时间:2020-10-11 08:51:27      阅读:55      评论:0      收藏:0      [点我收藏+]

从不同使用场景来介绍git的基础命令

自从上了软件学院孟宁老师的课后,我对于Git在多人协作和版本控制方面的作用,产生了浓厚的兴趣。之前本人也做过一些的小的项目,在开发者只有一人的情况下,自然不用考虑太多,尤其是涉及到多个分支,多人协同开发的情况。但现在的软件行业,已经不是孤身一人就可以作战,每个人或多或少的都会在某个项目中与他人互动。这就产生了以下几个问题:如果几个人同时对某个文件进行了改动,且改动不一,该怎么处理?如果当前的项目进展的不是很顺利,想要使用之前写过的版本,但过去的代码并未备份,这时候又该怎么办?

不用担心,Git作为一个伟大的版本控制工具,为我们做了解答,下面就让我们一起来看一下Git的基本使用方法。

鉴于Vscode支持Git的使用,接下来的演示,我会使用Windows上安装的Vscode和Git工具。对于如何在Windows上安装这两款工具,请见链接:

https://blog.csdn.net/qq_32786873/article/details/80570783(Windows10下安装git)

https://blog.csdn.net/x15011238662/article/details/85094006(Windows下安装Vscode,并使用,以及中文配置)

以下我会分五个场景介绍Git的基础使用,但在此之前,让我们先来看一下,Git中涉及的一些概念。

技术分享图片

以上就是Git的基本架构和操作逻辑。

Git的工作区域可以简单分为两类——本地(local)和远程(remote)。

Git的本地工作区包括3个部分:

工作区(work directory):就是我们项目所在的根目录,也是我们直接改动代码的地方;

暂存区(stage):与工作区的文件进行直接交互,工作区文件的提交或者回滚,首选都是通过暂存区

本地仓库(repository):我们将项目设置为本地版本库后,在项目的根目录下,就会生成一个隐藏的“.git”文件夹,该目录即为本地仓库

看完了上述的几个名词,有些疑惑是吗?没关系,下面就让我们来一个个解释。

场景一.Git本地版本库的基础用法

我先在桌面新建一个名为”gitdisplay“的文件夹,右键点击,选择”Git Bash Here“,便会打开如下图所示的窗口

技术分享图片

当我们敲下如下命令:git init

我们会发现,在gitdisplay目录下多了一个.git隐藏文件夹,也就是说我们通过命令初始化了一个本地仓库。

此时如果我们通过Vscode打开gitdisplay文件夹,并且新增一个"readme.md"文件,Vscode的侧边栏,便会出现以下情况:

技术分享图片

如果我们返回Git bash界面,输入命令:git status

便可以查看工作区的当前状态
技术分享图片

以上信息说明,当前工作区的文件“readme.md”未被跟踪,因此我们需要把该文件提交到暂存区

输入命令 git add [FILES]

此时查看工作区状态,显示文件已被added,位于暂存区中,等待提交

命令git commit -m "added info" ,可以将暂存区中的文件提交到本地仓库

技术分享图片

以上我们就完成了本地对源代码的基本的版本控制,简单来说,每当我们的工作区有了变动,我们就通过 git add 将改动添加到暂存区,然后通过 git commit 将其提交到本地仓库。

如果此时我们试着向readme.md中写入一些东西,然后重复上述操作,将其提交,通过 git log 指令,我们可以看到git bash界面显示了两次提交记录。

技术分享图片

由图片可以看出,“HEAD”对准的是我们最新的提交。

当然,并不是我们的每一次提交都是有意义的提交,有的时候,我们需要的可能是之前的提交,而命令

git reset --hard HEAD^^/HEAD~100/commit-id/commit-id的头几个字符 可以让我们回退到过去的某次提交,并且新的commit记录也会消失。当我们输入 git reset --hard 02bc9 ,然后用 git log 查看提交记录
技术分享图片

我们惊讶地发现,只剩下了第一次的提交记录,并且HEAD指针指向了该次提交记录。同时,此时打开readme.md,我们会发现,添加的语句已经没有了。

然而,并不是所有回滚都是有意义的,可能某些同学回滚完了之后,又开始后悔了,可是通过git log 指令,我们已经无法查看 第一次提交之后的记录了。别担心,指令 git reflog 可以查看当前HEAD之后的提交记录

技术分享图片

看懂了吗,HEAD指向我们工作区所依赖的版本,同时也是未来与过去的分界线。

当我们再次输入 git reset --hard 7081a

技术分享图片

恭喜,我们又回到了最新的提交版本。借助HEAD,我们可以在过去和未来之间来回切换。

有关git reset 的其他模式,请参照 https://www.jianshu.com/p/c2ec5f06cf1a(git reset 三种模式)

场景二.git远程版本库的基本用法

还记得我们是怎么来初始化一个本地版本库的吗?没错,我们使用的是git init。同样的,我们也可以通过

git clone [链接地址] 的方式初始化。该命令的意思是从远程仓库克隆一个项目到本地仓库。

那么问题来了,这个所谓的远程仓库是在哪?一般来说,远程仓库位于github这个网站上。git与github的关系,经常有人混淆,其实git是个版本控制工具,而github就是个远程仓库。

首先,我们要做的就是新建一个远程仓库,关于此部分我就不再赘述,有兴趣的同学可以参考一下链接:

https://www.jianshu.com/p/750527980651(git添加远程仓库)

当我们成功创建一个远程仓库后,就会获得一个你的远程仓库的链接地址。接下我们要做的就是将远程仓库,和我们的本地仓库联系起来。

需要输入的命令为:

git remote add origin [your repository link]

git push -u origin master (仅第一次需要添加“-u”)

我们发现,远程仓库的内容,与本地仓库已经一摸一样了。

此后每当我们在本地工作区产生改动,当提交到本地仓库后,再使用指令 git push origin master 使远程仓库与本地仓库保持一致。

如果我们之后的开发只要按照这种流程,那么也就不会有后续的烦恼了。但问题在于,我们不光可以在本地进行修改,也可以在远程仓库进行修改。当我们在远程仓库加入新的改动时,由于我们本地并未改动过,如果我们想以远程仓库的最新版本为基准,那我们需要使本地仓库与远程仓库保持一致。这时,使用git fetchgit merge,便可以使本地仓库与远程仓库保持一致。

当我们输入git fetch

技术分享图片

git bash中有如上显示,但是本地文件中,还是没变。

同时我们查看status时,

技术分享图片

显示我们的本地仓库,已经落后了远程仓库1次提交。也就是说git fetch指令拉取了远程仓库的最新信息,但并没有立即合并到当前分支中。此时,如果我们输入 git merge

技术分享图片

现在我们可以看到本地仓库与远程仓库,都保持一致了。

当然,如果我们总是以远程仓库的版本为基准,我们可以使用git pull指令,可以近似看做以上两条指令的组合。

另外当git merge发生冲突时,我们需要处理冲突,之后再次提交。(假如本地和远程修改了同一文件的同一处的地方)

一个比较保险的做法,就是不管实在本地仓库还是远程仓库,在对代码修改之前,都应该进行代码同步,以防止产生冲突和分叉。

场景三.团队项目中的分叉与合并

之前介绍的情况,都是基于一点,那就是在master主分支上开发。master分支一般只用来发布重大版本,如果一个项目有多人协作,如果大家都在master分支上开发,那势必会引起版本混乱。正确的做法应该是在其他分支上做开发,调试好了再合并到主分支。

如果我们想创建一个分支并切换到该分支,可以使用命令 git checkout -b dev1 ,这样我们就创建并切换到了分支dev1。

技术分享图片
技术分享图片

当我们用git branch命令查看分支的情况时,发现共有两个分支,且当前所在的分支为dev1。

如果我们在readme.md中添加了一行新的语句,并提交。然后再重复一遍该操作

技术分享图片

我们发现在dev1分支下多了两条提交记录。

假如我们已经在dev1分支上完成了开发,希望将该分支上的变动合并到主分支master上,我们又该做什么呢?

首先,我们先要用git checkout master 返回主分支。

技术分享图片

然后,我们使用git pull命令使主分支与远程仓库同步。

之后我们使用命令git merge --no-ff dev1 将dev1分支上的变动,合并到master分支。

技术分享图片

命令中的--no-ff,作用是禁止快进式合并,这样可以使分支的提交历史,变得更加清晰。

接下来我们要做的就是将本地的变动,push到远程仓库。好了,我们成功创建了一个分支,完成了一个功能修改,然后将主分支与其合并,然后使远程仓库与主分支保持一致。以上就是开发某个模块或者功能的基本流程了。

场景四.Git Rebase

有人可能对git rebase 命令的作用产生疑惑。一般来说,作用是精简提交记录。比如你自己在某个分支上 提交了多个记录,但是并不是每一次提交都是有意义的提交。通过git rebase 可以使某些提交记录合并为一个,从而变得简洁明了。

假如我们在dev1分支上进行三次改动,每次都提交记录,结果如下:

技术分享图片

接着我们回到master主分支,并在该分支上进行三次操作,同样每次都要提交记录,结果如下:

技术分享图片

图中红线圈起来的部分,就是在master和dev1分支上分别提交的3次记录。如果我们嫌dev1分支上的3次提交过于繁琐,想把它整合为一次,我们可以先切换为dev1分支,然后使用命令

git rebase -i [startpoint] [endpoint]

后续的endpoint如果不指定,则要合并的区间的终点,默认是当前分支的HEAD。

技术分享图片

我们希望仅希望保留第三次提交记录

技术分享图片

保存退出文件,这时我们发现git bash显示报错,并打开冲突文件,因为前两次提交相当于第三次提交的基础,所以我们需要对冲突文件进行修改。我们可以直接修改文件,保留三次修改的内容,同时去掉提示符号,并保存。

这时我们通过git status查看

技术分享图片

此时,我们需要通过git add 命令将修改好的文件存入暂存区 ,然后输入命令git rebase --continue

此时会出现以下画面

技术分享图片

提示我们需要重新修改记录提交信息。

这时我们发现,在dev1上的提交记录,已经合并为一次了

技术分享图片

接下来的操作就是,先切换为master分支,使用git pull指令使本地与远程保持一致,然后合并dev1分支到master分支,并用git push origin master 向远程仓库推送。

技术分享图片

最后,我们看到,虽然dev1有多次提交记录,但最终只有一个提交记录有显示。

以上就是关于Git的一些基础命令,感谢您的观看。

参考文章:五?场景玩转 Git,只要这一篇就够了!

从不同使用场景来介绍git的基础命令

原文:https://www.cnblogs.com/chuanguo/p/13795951.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!