自从上了软件学院孟宁老师的课后,我对于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”文件夹,该目录即为本地仓库
看完了上述的几个名词,有些疑惑是吗?没关系,下面就让我们来一个个解释。
我先在桌面新建一个名为”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 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 fetch
和 git 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
可以使某些提交记录合并为一个,从而变得简洁明了。
假如我们在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,只要这一篇就够了!
原文:https://www.cnblogs.com/chuanguo/p/13795951.html