Git基础及常用命令

Git基础及常用命令

2022年6月18日 0 作者 老王

1 引言

写博客其实是一件非常反人性的事情,因为写博客需要占用自己大量的时间,而且这些时间本可以用来休息或者学习。但是写博客可以帮助自己深刻地理解相关知识点已经背后的原理,而且一段时间之后如果忘记了相关知识点,可以立马掉过头来复习,节省了很多时间。但是人性是懒惰的,是好逸恶劳的。每次写博客都是一次与自己的战斗,与自己的懒惰、好逸恶劳战斗!
希望自己还是能坚持坚持学习写博客吧。简单的事情重复做,贵在坚持。坚持下去,量变总有一天会引发质变。
所以,我们今天还是来写一篇博客,虽然这篇博客比较水。
由于公司在用Git管理新项目了,而其他老项目又是用的SVN,自己老是忘记Git的命令是怎么写的,所以本篇简单记录下,方便查阅。

2 Git基础知识

2.1 Git是分布式的

Git是分布式的,每个人的本地仓库都包含了完整的版本库。虽然是分布式的,但是我们还是会找一个服务器来托管仓库(比如GitHub),方便团队成员(有可能来自世界各地)从该服务器拉取、提交代码。虽然Git这样使用(加一个托管服务器)看起来好像是中心化的,但是不是!每个团队成员都可以向其他某一团队成员推送代码、拉取该其他成员的修改,Git是点对点的。举个例子:
Git分布式解释
如上图中,团队成员A可以直接向团队成员B推送代码,或者拉取B的修改。团队成员B也可以直接向团队成员D推送代码,或者拉取B的代码(上图中为了美观没有画出B和D的直接连接箭头)。
SVN不一样,团队成员只能和中心服务器交互,团队成员之间是不能互相推送、拉取代码的,如下图。(图中,我把SVN中心仓库画得大一点,表示中心仓库很重要,但是Git的托管仓库不怎么重要)
SVN工作模式

2.2 Git简单工作原理

在Git中,每一个版本保存的都是该版本下的所有文件。可以简单理解为每一次提交就是对所有文件的(注意是所有文件,不是只有修改的文件)一次备份。

在 Git 中,每当你提交更新或保存项目状态时,它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。为了效率,如果文件没有修改,Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。
 存储项目随时间改变的快照

这一点是Git与SVN的最大不同,SVN记录的是是一组基本文件和每个文件随时间逐步累积的差异 。
新建一个Git仓库,会自动创建一个.git的隐藏文件夹,里面存储的是Git的版本库。其他人只要拿到.git文件夹,就可以还原我们的整个提交历史。
.git文件夹外面就是Git仓库的工作区,所有需要被该Git仓库管理的文件和文件夹都需要放到工作区(也叫Working tree)里面。
Git文件层次结构
除了.git版本库和git工作区,还有一个暂存区(Staging Area),用来记录下一次提交的内容。暂存区(Staging Area)也叫索引(Index)。
举个例子:我们在工作区新建了一个文件README.md,然后需要用命令将README.md添加到暂存区中,最后再提交(commit)。
提交的一定是暂存区中的内容,没有添加到暂存区的修改是不会记录到本次提交的。

2.3 HEAD、origin、remote、FETCH_HEAD

HEAD是一个指针,指向我们当前检出的分支。
比如我们通过git log命令看提交日志的时候,可以通过HEAD知道我们当前检出(check out)的分支。
HEAD指针
origin是服务器托管仓库的简称,origin是默认的名字,也有使用upstream。
举个例子,我们服务器托管仓库的地址为git@github.com:betty-remote/netauto.git,那么为了在使用命令时不用写这么一长串地址,可以通过命令将这一长串地址设置为一个别名,如这里的origin。
origin:源,表示这个仓库是从哪儿来的。
remote是远程的意思,用来该信息是远程主机的,不是本地主机的。
FETCH_HEAD:指向从远端获取的最新的提交。

2.4 分支

Git最强大的一点就是它的分支管理。我们在开发中,可能会创建出很多的分支,比如master主分支、develop开发分支、各种feature功能分支、hotfix修复bug分支以及用来发布版本的release分支。
需要注意的是,在Git看来所有分支都是一样的,没有任何区别。比如在GitHub创建一个仓库,将会默认创建一个master分支。那master分支有什么特别吗?没有!在Git看来所有分支都是一样的,Git并不会因为这个分支名字是master就区别对待它。只是大家都用习惯了第一个分支命名为master。
当然,Git分支需要规范化的管理,具体可见我上篇的文章《Git工作流(分支管理规范)》。

3 常用命令

3.1 git init

在当前目录新建一个Git仓库。

git init . 

3.2 git clone

从托管服务器上拷贝仓库(包含所有分支)到本地。

git clone git@github.com:betty-remote/netauto.git

从托管服务器上拷贝仓库中的指定分支,如下面例子为只拷贝develop分支到本地。

git clone -b develop git@github.com:betty-remote/netauto.git

3.2 git branch、checkout

3.2.1 新建分支

本地创建分支,创建完成后需要检出到该分支,才能在该分支上开始工作。

git branch hotfix
git checkout hotfix

当然这两个指令可以合并为一条指令。创建并立即检出到hotfix分支。

git checkout -b hotfix

然后推送本地分支到托管服务器。
如下面指令将本地的hotfix分支推送到origin主机的hotfix分支。如果origin主机的hotfix不存在,则会被新建。

git push origin hotfix

上面这个push语句其实是git push origin hotfix:hotfix的简写。更详细的push指令见git push小节。

3.2.2 查看分支

查看本地分支。

git branch

*开头的分支名表示我们当前所在的分支。如下图,我们本地有两个分支,master分支和develop分支,当前处于master分支。
git branch
查看远程主机的所有分支。-r中r,即remotes的缩写。

git branch -r

git branch -r
查看本地和远程主机的所有分支。

git branch -a

Git告诉我们本地只有一个master分支,远程的origin主机也只有一个master分支。
git branch -a

3.2.3 删除分支

删除本地分支。 -d即–delete的缩写。

git branch -d develop

上面这条指令将会删除本地的develop分支。需要注意无法删除当前检出的分支,如果本身就在develop分支,执行上面这条语句是会提示无法删除的,必须切换到其他分支才可删除develop分支。
删除远程分支。
如果本地该分支有修改但还未提交,也不能删除。此时需要提交修改之后再执行或执行强制删除(将-d改为-D)。

git branch -D develop

删除远程分支

git push origin -d hotfix

3.3 git add

将工作区文件的修改添加到暂存器。
git add . 指令将添加当前目录的所有文件到暂存区。

git add .

3.4 git status

用于查看当前工作区的状态。

git status

举个例子:
目前我们没有任何修改,执行git status,返回的信息告诉我们当前在master分支,工作区是干净的没有修改。
git status
然后修改一下README.md,并添加一个test.cs脚本。执行git stauts,然后git会告诉我们README.md被修改了,但是还没有添加到暂存区,需要用git add指令添加到暂存区以便下次提交包含此文件,或者使用git restore指令丢弃工作区该文件的修改;还告诉我们test.cs文件没有被追踪,需要使用git add指令将其加入Git的版本管理中来。
git status
处理完成后再执行git status,Git告诉我们以下文件将会记录在下次提交中,可以使用git resotre –staged指令将其取消暂存。
git status

3.4 git commit

提交暂存区的修改。后面的 -m “xxx”,就是本次提交的日志。

git commit -m "提交日志"

如果忘记了后面日志,只执行了git commit,Git会使用打开默认的vim编辑器,然后叫你输入日志。
git默认编辑器
这时需要如下操作:
– 点击键盘上的i,然后输入日志
i
– 输入完毕后,点击ESC键,然后输入:wq,点击ENTER键即可
:wq
可参考stack-overflow

3.5 git push

将本地分支推送到远程主机的指定分支。

git push <远程主机名> <本地分支名>:<远程分支名>

如git push orgin develop:develop,就是将develop分支推送到远程主机的develop分支。
如果本地分支名与远程分支名一样,可以将<本地分支名>:<远程分支名>简化为<本地分支名>。
即git push origin develop。
如果当前分支只有一个追踪分支,那么主机名都可以省略,直接使用git push即可。

3.6 git fetch、pull

fetch是获取远程分支的修改。
pull是拉取远程分支的修改。
fetch和pull是有点差别的,git pull实际上是先git fecth,然后再执行git merge,即先获取然后合并。

3.6.1 git fecth

获取远程主机origin的所有分支。

git fecth origin

获取origin主机的develop分支。

git fetch origin develop

然后本地切换到develop分支。

git checkout develop

然后合并远程主机的develop分支修改。

git merge oringin/master

git merge FETCH_HEAD

3.6.2 git pull

git pull <远程主机名> <远程分支名>:<本地分支名>

如果远程分支是与当前分支合并,则冒号后面的部分可以省略:

git pull origin develop

上面这条语句的意思就是拉取develop分支:即先获取origin主机的develop分支,然后合并到本地的develop分支上。

3.7 git merge

合并分支。
下面指令将hotfix分支的修改合并到当前分支。

git merge hotfix

合并分为快速前向合并(Fast-Forward)和三路(3-Way)合并。

3.7.1 Fast-Forward merge

比如,我们当前再master分支,现在想合并SDN分支的修改到master分支。
我们先切换到master分支,然后执行git merge SDN,就会执行一个快速前向合并。
因为未合并前master分支指向的提交点是SDN分支的祖先节点,那么只需要将master指针指向SDN指向的提交点即可,不用做其他任何额外工作。
git merge SDN
Fast-Forward合并前:
Fast-Forward合并前
Fast-Forward合并后:
Fast-Forward合并前

3.7.2 3-Way merge

比如我们想在想把auth分支的修改合并到master分支来。
合并前的提交历史如下图。
3-Way merge前
此时我们在master分支执行git merge auth,将会执行3路合并。所谓的3路是指哪3路呢?指两分支所在的祖先节点以及两分支分别所在最新的节点。
3路是指哪3路
3路合并就是把这三个提交点的修改合并,然后创建一个新的提交。
3-Way merge后
所以,需要注意的是,3路合并将会创建一个新的提交(commit)。
3路合并有可能会产生冲突,这是合并指令会暂停,手动处理完毕冲突后(然后使用git add . 并git commit -m “xxx”)会继续执行合并。当然遇到冲突也可以直接中断并丢弃本次合并,此时需要使用
git merge –abort指令。

git merge --abort

3.8 git rebase

rebase中文翻译为变基,改变基础。
指令如下。

git rebase master

假设当前分支为develop分支,即将develop分支的提交在master分支上重放一遍。这听起来有点不知所云,没关系,咱们看看rebase到底是怎么工作的。

3.8.1 git rebase原理

git rebase 和 git merge的功能类似,同一目的都是将其他分支的修改合并到当前分支。不同点在于提交记录不同。
我们上面讲过,git merge在执行3路合并的时候会产生一个额外的新的提交。在多人同时开发的时候,很多人同时使用git merge将会时提交信息看起来非常凌乱。比如这样。
gitmerge的缺点
而使用rebase来合并可以让我们提交历史保持在一条线上,就像这样。
rebase合并效果
git rebase指令并不是直接执行合并,而是执行“重放”。
比如我们想把experiment分支的修改rebase(变基)到master分支来。
rebase前
我们先将当前分支切换为experiment分支,然后执行变基(rebase)。

git checkout experiment
git rebase master

rebase的原理如下:
首先找到这两个分支(即当前分支 experiment、变基操作的目标基底分支 master) 的最近共同祖先 C2,然后对比当前分支相对于该祖先C2的历次提交,提取相应的修改并存为临时文件, 然后将当前分支(experiment)指向目标基底 C3, 最后以此将之前另存为临时文件的修改依次应用。
变基
就相当于将experiment分支的修改在master分支上重放一遍,然后再将experiment分支执向rebase后的提交。
最后,需要再切换为master分支,然后执行快速合并。

git checkout master
git merge experiment

3.8.2 git rebase使用规范

只能在本地分支执行rebase,切记不能在远程主机的分支上执行rebase!
只能在本地分支执行rebase,切记不能在远程主机的分支上执行rebase!
只能在本地分支执行rebase,切记不能在远程主机的分支上执行rebase!

比如我们想把feature/player分支的修改合并到develop分支,使用rebase的工作流如下:
– 切换到feature/player分支

git checkout feature/player
  • 然后以develop分支为基地分支进行变基
git rebase develop
  • 然后切换为develop分支
git checkout develop
  • develop分支合并变基后的feature/player分支,此时会执行快速合并不会产生新的提交
git merge feature/player

即:

git checkout feature/player
git rebase develop
git checkout develop
git merge feature/player

3.9 git stash

git stash指令用于解决如下这种情况:
比如我们正在develop分支上开发某一新功能,但是突然需要修复一个紧急Bug,但是新功能还没开发好,不能提交,此时,我们想把当前的工作区内容给存起来,等把紧急Bug修复完毕后再来接着开发。
git stash指令就是用来缓存我们当前的工作内容的。

缓存当前工作内容。

git stash

git stash lit
可以使用git stash save “xxx”指定缓存日志。

git stash save "缓存(贮藏)日志"

查看缓存的列表。

git stash list

比如,我们这里只有一个缓存,编号是0(stash@{0}),是在master分支上的29efbb0那次提交执行的缓存。
git stash list
应用最近的缓存。

git stash apply

应用特定缓存。

git stash apply stash@{x}

删除最新的缓存。

git stash pop

3.10 git config

git config –global 配置全局用户名和邮箱

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

3.11 git log

查看提交日志。
–online 每次提交只用一行展示
–graph 用图形展示
-x 指看最新的x条提交

git log --oneline --graph -x

git log --oneline --graph -3

4 参考文章