git版本管理工具用法介绍



1. 概要

      Git 是 Linux 发明者 Linus 开发的一款新时代的版本控制系统,对于软件开发领域来说版本控制是最重要的一环,而 Git 毫无疑问是当下最流行、最好用的版本控制系统。

2. Git 安装

上面说了,Git 是一个版本控制系统,你也可以理解成是一个工具,跟 Java 类似,使用之前必须得先下载安装,所以第一步必须要安装,我用的是 Mac , Mac 上其实系统自带 Git 的,不过这里统一提供一下各平台的安装方式,这部分就不过多介绍,相信大家这里搞的定。

  • Mac:https://sourceforge.net/projects/git-osx-installer/

  • Windows:https://git-for-windows.github.io/

  • Linux:apt-get install git

3. 如何学习 Git ?

安装好 Git 之后,怎么学习是个问题,其实关于 Git 有很多图形化的软件可以操作,但是我强烈建议大家从命令行开始学习理解,我知道没接触过命令行的人可能会很抵触,但是我的亲身实践证明,只有一开始学习命令行,之后你对 Git 的每一步操作才能理解其意义,而等你熟练之后你想用任何的图形化的软件去操作完全没问题。

我一开始教我们团队成员全是基于命令行的,事后证明他们现在已经深深爱上命令行无法自拔,他们很理解 Git 每一步操作的具体含义,以致于在实际项目很少犯错,所以我这里也是基于命令行去教你们学习理解。

4. Git 命令列表

怎么判断你 Git 有没有安装成功?请在命令行里输入 git ,如果出现以下提示证明你已经安装成功了。

Git 所有的操作命令开头都要以 git 开头,上面列举了最常用的一些 Git 命令,紧接着会有一句英文解释这个命令的意义,都不是很难的单词,不妨试着看一下,不过没有实际操作你仍然不好理解,下面我们来以一个实际的操作来介绍下一些常用命令的含义。

5. Git 具体命令

第一步,我们先新建一个文件夹,在文件夹里新建一个文件(我是用 Linux 命令去新建的,Windows用户可以自己手动新建)

mkdir test (创建文件夹test) cd test (切换到test目录) touch a.md (新建a.md文件)

这里提醒下:在进行任何 Git 操作之前,都要先切换到 Git 仓库目录,也就是先要先切换到项目的文件夹目录下。

这个时候我们先随便操作一个命令,比如 git status ,可以看到如下提示(别纠结颜色之类的,配置与主题不一样而已):

意思就是当前目录还不是一个 Git 仓库。

git init

这个时候用到了第一个命令,代表初始化 git 仓库,输入 git init 之后会提示:

可以看到初始化成了,至此 test 目录已经是一个 git 仓库了。

git status

紧接着我们输入 git status 命令,会有如下提示:

默认就直接在 master 分支,关于分支的概念后面会提,这时最主要的是提示 a.md 文件 Untracked files ,就是说 a.md 这个文件还没有被跟踪,还没有提交在 git 仓库里呢,而且提示你可以使用 git add 去操作你想要提交的文件。

git status 这个命令顾名思义就是查看状态,这个命令可以算是使用最频繁的一个命令了,建议大家没事就输入下这个命令,来查看你当前 git 仓库的一些状态。

git add

上面提示 a.md 文件还没有提交到 git 仓库里,这个时候我们可以随便编辑下 a.md 文件,然后输入 git add a.md ,然后再输入 git status :

此时提示以下文件 Changes to be committed , 意思就是 a.md 文件等待被提交,当然你可以使用 git rm –cached 这个命令去移除这个缓存。

git commit

接着我们输入 git commit -m ‘first commit’ ,这个命令什么意思呢? commit 是提交的意思,-m 代表是提交信息,执行了以上命令代表我们已经正式进行了第一次提交。

这个时候再输入 git status ,会提示 nothing to commit。

git log

这个时候我们输入 git log 命令,会看到如下:

git log 命令可以查看所有产生的 commit 记录,所以可以看到已经产生了一条 commit 记录,而提交时候的附带信息叫 ‘first commit’ 。

git add & git commit

看到这里估计很多人会有疑问,我想要提交直接进行 commit 不就行了么,为什么先要再 add 一次呢?首先 git add 是先把改动添加到一个「暂存区」,你可以理解成是一个缓存区域,临时保存你的改动,而 git commit 才是最后真正的提交。这样做的好处就是防止误提交,当然也有办法把这两步合并成一步,不过后面再介绍,建议新手先按部就班的一步步来。

git branch

branch 即分支的意思,分支的概念很重要,尤其是团队协作的时候,假设两个人都在做同一个项目,这个时候分支就是保证两人能协同合作的最大利器了。举个例子,A, B俩人都在做同一个项目,但是不同的模块,这个时候A新建了一个分支叫a, B新建了一个分支叫b,这样A、B做的所有代码改动都各自在各自的分支,互不影响,等到俩人都把各自的模块都做完了,最后再统一把分支合并起来。

执行 git init 初始化git仓库之后会默认生成一个主分支 master ,也是你所在的默认分支,也基本是实际开发正式环境下的分支,一般情况下 master 分支不会轻易直接在上面操作的,你们可以输入 git branch 查看下当前分支情况:

如果我们想在此基础上新建一个分支呢,很简单,执行 git branch a 就新建了一个名字叫 a 的分支,这时候分支 a 跟分支 master 是一模一样的内容,我们再输入 git branch 查看的当前分支情况:

但是可以看到 master 分支前有个 * 号,即虽然新建了一个 a 的分支,但是当前所在的分支还是在 master 上,如果我们想在 a 分支上进行开发,首先要先切换到 a 分支上才行,所以下一步要切换分支

git checkout a

执行这个命令,然后再输入 git branch 查看下分支情况:

可以看到当前我们在的分支已经是a了,这个时候 A 同学就可以尽情的在他新建的a分支去进行代码改动了。

那有人就说了,我要先新建再切换,未免有点麻烦,有没有一步到位的,聪明:

git checkout -b a

这个命令的意思就是新建一个a分支,并且自动切换到a分支。

git merge

A同学在a分支代码写的不亦乐乎,终于他的功能完工了,并且测试也都ok了,准备要上线了,这个时候就需要把他的代码合并到主分支master上来,然后发布。git merge 就是合并分支用到的命令,针对这个情况,需要先做两步,第一步是切换到 master 分支,如果你已经在了就不用切换了,第二步执行 git merge a ,意思就是把a分支的代码合并过来,不出意外,这个时候a分支的代码就顺利合并到 master 分支来了。为什么说不出意外呢?因为这个时候可能会有冲突而合并失败,留个包袱,这个到后面进阶的时候再讲。

git branch -d

有新建分支,那肯定有删除分支,假如这个分支新建错了,或者a分支的代码已经顺利合并到 master 分支来了,那么a分支没用了,需要删除,这个时候执行 git branch -d a 就可以把a分支删除了。

git branch -D

有些时候可能会删除失败,比如如果a分支的代码还没有合并到master,你执行 git branch -d a 是删除不了的,它会智能的提示你a分支还有未合并的代码,但是如果你非要删除,那就执行 git branch -D a 就可以强制删除a分支。

git tag

我们在客户端开发的时候经常有版本的概念,比如v1.0、v1.1之类的,不同的版本肯定对应不同的代码,所以我一般要给我们的代码加上标签,这样假设v1.1版本出了一个新bug,但是又不晓得v1.0是不是有这个bug,有了标签就可以顺利切换到v1.0的代码,重新打个包测试了。

所以如果想要新建一个标签很简单,比如 git tag v1.0 就代表我在当前代码状态下新建了一个v1.0的标签,输入 git tag 可以查看历史 tag 记录。

可以看到我新建了两个标签 v1.0、v1.1。

想要切换到某个tag怎么办?也很简单,执行 git checkout v1.0 ,这样就顺利的切换到 v1.0 tag的代码状态了。

git tag -d v1.1

删除  tag v1.1.

OK,以上全是一些最基本的Git操作,而且全是在本地环境进行操作的,完全没有涉及到远程仓库,下一章节将以远程 GitHub 仓库为例,讲解下本地如何跟远程仓库一起同步协作,另外今天讲的全是最基础最简单的Git操作,一步步来,后续再继续讲解一下Git的高阶以及一些Git的酷炫操作。

另外,考虑到可能会有人嫌我讲解的太基础太慢,毕竟我是针对小白,所以得一步步来,迫不及待的想要提前自己学习的不妨在我公众号 AndroidDeveloper 回复「git」关键字,获取一份我推荐的还不错的 Git 学习资料,不谢,毕竟我这么帅!


GIT进阶:

1. 用户名和邮箱

我们知道我们进行的每一次commit都会产生一条log,这条log标记了提交人的姓名与邮箱,以便其他人方便的查看与联系提交人,所以我们在进行提交代码的第一步就是要设置自己的用户名与邮箱。执行以下代码:

git config --global user.name "stormzhang"
git config --global user.email "[email protected]"

以上进行了全局配置,当然有些时候我们的某一个项目想要用特定的邮箱,这个时候只需切换到你的项目,以上代码把 –global 参数去除,再重新执行一遍就ok了。

PS:我们在 GitHub 的每次提交理论上都会在 主页的下面产生一条绿色小方块的记录,如果你确认你提交了,但是没有绿色方块显示,那肯定是你提交代码配置的邮箱跟你 GitHub 上的邮箱不一致,GitHub 上的邮箱可以到Setting -> Emails里查看。

2. alias

我们知道我们执行的一些Git命令其实操作很频繁的类似有:

git commit
git checkout
git branch
git status
...

这些操作非常频繁,每次都要输入完全是不是有点麻烦,有没有一种简单的缩写输入呢?比如我对应的直接输入以下:

git c
git co
git br
git s
...

是不是很简单快捷啊?这个时候就用到了alias配置了,翻译过来就是别名的意思,输入以下命令就可以直接满足了以上的需求。

git config --global alias.co checkout  # 别名
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch

当然以上别名不是固定的,你完全可以根据自己的习惯去定制,除此之外还可以设置组合,比如:

git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'

之后经常用到的git push origin mastergit pull origin master 直接就用git psmgit plm 代替了,是不是很方便?

另外这里给大家推荐一个很强大的 alias 命令,我们知道我们输入 git log 查看日志的时候是类似这样的:

告诉大家一个比较屌的命令,输入**git log –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit –date=relative ** 然后日志这样了:

是不是比较清晰,整个分支的走向也很明确,但是每次都要输这么一大串是不是也很烦?这时候你就该想到 alias 啊:

git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"

这样以后直接输入 git lg 就行了。

3. 其他配置

当然还有一些其他有用的配置,默认情况下 git 用的编辑器是 vi ,如果不喜欢可以改成其他编辑器,比如我习惯 vim 。

git config --global core.editor "vim"  # 设置Editor使用vim

你们如果喜欢其他编辑器可自行搜索配置,前提是本机有安装。

有些人纳闷我的终端怎么有各种颜色,自己却不是这样的,那是因为你们没有开启给 Git 着色,输入如下命令即可:

git config --global color.ui true

还有些其他的配置如:

git config --global core.quotepath false # 设置显示中文文件名

以上基本所有的配置就差不多了,默认这些配置都在 ~/.gitconfig 文件下的,你可以找到这个文件查看自己的配置,也可以输入git config -l 命令查看。

4. diff

diff命令算是很常用的,使用场景是我们经常在做代码改动,但是有的时候2天前的代码了,做了哪些改动都忘记了,在提交之前需要确认下,这个时候就可以用diff来查看你到底做了哪些改动,举个例子,比如我有一个 a.md 的文件,我现在做了一些改动,然后输入git diff 就会看到如下:

红色的部分前面有个 - 代表我删除的,绿色的部分前面有个 + 代表我增加的,所以从这里你们很一目了然的知道我到底对这个文件做了哪些改动。

值得一提的是直接输入 git diff 只能比较当前文件和暂存区文件差异,什么是暂存区?就是你还没有执行 git add 的文件。

当然跟暂存区做比较之外,他还可以有其他用法,如比较两次 commit 之间的差异,比较两个分支之间的差异,比较暂存区和版本库之间的差异等,具体用法如下:

git diff <$id1> <$id2>   # 比较两次提交之间的差异
git diff .. # 在两个分支之间比较 
git diff --staged   # 比较暂存区和版本库差异

5. checkout

我们知道 checkout 一般用作切换分支使用,比如切换到 develop 分支,可以执行:

git checkout develop

但是 checkout 不只用作切换分支,他可以用来切换tag,切换到某次commit,如:

git checkout v1.0
git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7 # 后面的一长串是commit_id,是每次commit的SHA1值,可以根据 git log 看到。

除了有“切换”的意思,checkout 还有一个撤销的作用,举个例子,假设我们在一个分支开发一个小功能,刚写完一半,这时候需求变了,而且是大变化,之前写的代码完全用不了了,好在你刚写,甚至都没有git add 进暂存区,这个时候很简单的一个操作就直接把原文件还原:

git checkout a.md

这里稍微提下,checkout 命令只能撤销还没有 add 进暂存区的文件。

6. stash

设想一个场景,假设我们正在一个新的分支做新的功能,这个时候突然有一个紧急的bug需要修复,而且修复完之后需要立即发布。当然你说我先把刚写的一点代码进行提交不就行了么?这样理论上当然是ok的,但是这会产品垃圾commit,原则上我们每次的commit都要有实际的意义,你的代码只是刚写了一半,还没有什么实际的意义是不建议就这样commit的,那么有没有一种比较好的办法,可以让我暂时切到别的分支,修复完bug再切回来,而且代码也能保留的呢?

这个时候 stash 命令就大有用处了,前提是我们的代码没有进行 commit ,哪怕你执行了add 也没关系,我们先执行

git stash

命令,什么意思呢?意思就是把当前分支所有没有 commit 的代码先暂存起来,这个时候你再执行 git status 你会发现当前分支很干净,几乎看不到任何改动,你的代码改动也看不见了,但其实是暂存起来了。执行

git stash list

你会发现此时暂存区已经有了一条记录。

这个时候你可以切换会其他分支,赶紧把bug修复好,然后发布。之后一切都解决了,你再切换回来继续做你之前没做完的功能,但是之前的代码怎么还原呢?

git stash apply

你会发现你之前的代码全部又回来了,就好像一切都没发生过一样,紧接着你最好需要把暂存区的这次 stash 记录删除,执行:

git stash drop

就把最近一条的 stash 记录删除了,是不是很方便?其实还有更方便的,你可以使用:

git stash pop

来代替 apply 命令,popapply 的唯一区别就是pop 不但会帮你把代码还原,还自动帮你把这条stash 记录删除,省的自己再 drop 一次了,为了验证你可以紧接着执行 git stash list 命令来确认是不是已经没有记录了。

最后还有一个命令介绍下:

git stash clear

就是清空所有暂存区的记录,drop 是只删除一条,当然后面可以跟 stash_id 参数来删除指定的某条记录,不跟参数就是删除最近的,而clear 是清空。

7. merge & rebase

我们知道 merge 分支是合并的意思,我们在一个 featureA 分支开发完了一个功能,这个时候需要合并到主分支 master 上去,我们只需要进行如下操作:

git checkout master
git merge featureA

其实 rebase 命令也是合并的意思,上面的需求我们一样可以如下操作:

git checkout master
git rebase featureA

rebasemerge 的区别你们可以理解成有两个书架,你需要把两个书架的书整理到一起去,第一种做法是merge ,比较粗鲁暴力,就直接腾出一块地方把另一个书架的书全部放进去,虽然暴力,但是这种做法你可以知道哪些书是来自另一个书架的;第二种做法就是rebase ,他会把两个书架的书先进行比较,按照购书的时间来给他重新排序,然后重新放置好,这样做的好处就是合并之后的书架看起来很有逻辑,但是你很难清晰的知道哪些书来自哪个书架的。

只能说各有好处的,不同的团队根据不同的需要以及不同的习惯来选择就好。

8. 解决冲突

假设这样一个场景,A和B两位同学各自开了两个分支来开发不同的功能,大部分情况下都会尽量互不干扰的,但是有一个需求A需要改动一个基础库中的一个类的方法,不巧B这个时候由于业务需要也改动了基础库的这个方法,因为这种情况比较特殊,A和B都认为不会对地方造成影响,等两人各自把功能做完了,需要合并的到主分支 master 的时候,我们假设先合并A的分支,这个时候没问题的,之后再继续合并B的分支,这个时候想想也知道就有冲突了,因为A和B两个人同时更改了同一个地方,Git 本身他没法判断你们两个谁更改的对,但是这个时候他会智能的提示有conflicts ,需要手动解决这个冲突之后再重新进行一次 commit 提交。我随便在项目搞了一个冲突做下示例:

以上截图里就是冲突的示例,冲突的地方由 ==== 分出了上下两个部分,上部分一个叫 HEAD 的字样代表是我当前所在分支的代码,下半部分是一个叫baidu_activity 分支的代码,可以看到HEAD 对 gradle 插件进行了升级,同时新增了一个插件,所以我们很容易判断哪些代码该保留,哪些代码该删除,我们只需要移除掉那些老旧代码,而且同时也要把那些«< HEAD==== 以及»»»baidu_activity 这些标记符号也一并删除,最后进行一次 commit 就ok了。

我们在开发的过程中一般都会约定尽量大家写的代码不要彼此影响,以减少出现冲突的可能,但是冲突总归无法避免的,我们需要了解并掌握解决冲突的方法。




你可能感兴趣的:(版本管理)