一、创建版本库
什么是版本库呢?版本库又名仓库,英文名repository,你可以简单理解成一个目录,这个目录里面的所有文件都可以被Git管理起来,每个文件的修改、删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。
首先,选择一个合适的地方,创建一个空目录:
$ mkdir learngit $ cd learngit $ pwd /Users/michael/learngit
说明:mkdir
命令用于创建文件夹,后接文件夹名称;pwd
命令用于显示当前目录。
第二步,通过git init
初始化命令把这个目录变成Git可以管理的仓库:
$ git init Initialized empty Git repository in /Users/michael/learngit/.git/
Git就把仓库建好了,而且告诉你是一个空的仓库(empty Git repository)。可以发现当前目录下多了一个.git
的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。
如果没有看到.git
目录,那是因为这个目录默认是隐藏的,用ls -ah
命令就可以看见。
也不一定必须在空目录下创建Git仓库,选择一个已经有东西的目录也是可以的。
把文件添加到版本库
首先这里再明确一下,所有的版本控制系统,其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,Git也不例外。版本控制系统可以告诉你每次的改动,比如在第5行加了一个单词“Linux”,在第8行删了一个单词“Windows”。而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从100KB改成了120KB,但到底改了啥,版本控制系统不知道,也没法知道。
使用Windows的童鞋要特别注意:千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件,他们自作聪明地在每个文件开头添加了0xefbbbf(十六进制)的字符,你会遇到很多不可思议的问题,比如,网页第一行可能会显示一个“?”,明明正确的程序一编译就报语法错误,等等,都是由记事本的弱智行为带来的。
编写一个readme.md
文件,内容如下:
这是一个git举例文件。 git用来控制文本版本。
一定要放到learngit
目录下(子目录也行),因为这是一个Git仓库,放到其他地方Git再厉害也找不到这个文件。
第一步,用命令git add
告诉Git,把文件添加到仓库:
$ git add readme.md
执行上面的命令,没有任何显示,这就对了,Unix的哲学是“没有消息就是好消息”,说明添加成功。
第二步,用命令git commit
告诉Git,把文件提交到仓库:
$ git commit -m "wrote a readme file" [master (root-commit) eaadf4e] wrote a readme file 1 file changed, 2 insertions(+) create mode 100644 readme.md
说明:git commit
命令,-m
后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样你就能从历史记录里方便地找到改动记录。
git commit
命令执行成功后会告诉你,1 file changed
:1个文件被改动(我们新添加的readme.txt文件);2 insertions
:插入了两行内容(readme.txt有两行内容)。
为什么Git添加文件需要add
,commit
一共两步呢?因为commit
可以一次提交很多文件,所以你可以多次add
不同的文件,比如:
$ git add file1.txt $ git add file2.txt file3.txt $ git commit -m "add 3 files."
二、基本操作
我们已提交了一次readme.txt
文件,我们继续修改readme.txt
文件,改成如下内容:
这是一个git举例文件。 git用来控制文本版本。 git可以追溯文本历史版本。
然后,运行git status
命令看看结果:
$ git status On branch leetcode Your branch is ahead of '猫屋/leetcode' by 1 commit. (use "git push" to publish your local commits) Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: readme.md no changes added to commit (use "git add" and/or "git commit -a")
说明:git status
命令可以让我们时刻掌握仓库当前的状态,上面的命令输出告诉我们,readme.md
被修改过了,但还没有准备提交的修改。
使用git diff
这个命令查看具体修改内容:
$ git diff readme.md diff --git a/readme.md b/readme.md index 4b6ef0c..eec7318 100644 --- a/readme.md +++ b/readme.md @@ -1,4 +1,7 @@ -# readma +# readme 这是一个git举例文件。 -git用来控制文本版本。 \ No newline at end of file + +git用来控制文本版本。 + +git可以追溯文本历史版本。 \ No newline at end of file
说明:git diff
顾名思义就是查看difference(区别),显示的格式正是Unix通用的diff格式。可以看到,我们添加了一行“git用来控制文本版本。”
再次使用git add
命令进行添加,然后,我们执行git status
命令查看一下仓库状态:
$ git status On branch leetcode Your branch is ahead of '猫屋/leetcode' by 1 commit. (use "git push" to publish your local commits) Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: readme.md
git status
告诉我们,将要被提交的修改包括readme.md
,下一步,就可以放心地提交了:
$ git commit -m "第一次修改后的readme文档" [leetcode 2070a38] 第一次修改后的readme文档 1 file changed, 5 insertions(+), 2 deletions(-)
再次使用git status
命令查看一下仓库状态:
$ git status On branch leetcode Your branch is ahead of '猫屋/leetcode' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean
Git告诉我们当前没有需要提交的修改,而且,工作目录是干净(working tree clean)的。
2.1 版本回退
git log
命令可以告诉我们历史记录:
$ git log commit 2070a3851d529cb899f979d4721095c63535fa47 (HEAD -> leetcode) Author: maopeiming <2414782708@qq.com> Date: Sat Jul 9 17:54:45 2022 +0800 第一次修改后的readme文档 commit 67c788e8ff60d07d21921e86d0a8da049b1573bd Author: maopeiming <2414782708@qq.com> Date: Sat Jul 9 17:04:40 2022 +0800 这是一份readme文档
说明:git log
命令显示从最近到最远的提交日志。如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline
参数:
$ git log --pretty=oneline 2070a3851d529cb899f979d4721095c63535fa47 (HEAD -> leetcode) 第一次修改后的readme文档 67c788e8ff60d07d21921e86d0a8da049b1573bd 这是一份readme文档
需要友情提示的是,你看到的一大串类似1094adb...
的是commit id
(版本号),和SVN不一样,Git的commit id
不是1,2,3……递增的数字,而是一个SHA1计算出来的一个非常大的数字,用十六进制表示,而且你看到的commit id
和我的肯定不一样,以你自己的为准。为什么commit id
需要用这么一大串数字表示呢?因为Git是分布式的版本控制系统,后面我们还要研究多人在同一个版本库里工作,如果大家都用1,2,3……作为版本号,那肯定就冲突了。
现在,开始进行版本回退
首先,Git必须知道当前版本是哪个版本,在Git中,用HEAD
表示当前版本,也就是最新的提交。上一个版本就是HEAD^
,上上一个版本就是HEAD^^
,当然往上100个版本写100个^
比较容易数不过来,所以写成HEAD~100
。
现在,我们要把当前版本回退到上一个版本,就可以使用git reset
命令:
$ git reset --hard HEAD^ HEAD is now at 67c788e 这是一份readme文档
此时,readme.md
内容变为了上一版本内容:
这是一个git举例文件。 git用来控制文本版本。
我们用git log
再看看现在版本库的状态:
$ git log --pretty=oneline 67c788e8ff60d07d21921e86d0a8da049b1573bd (HEAD -> leetcode) 这是一份readme文档
最新的那个版本append GPL
已经看不到了!好比你从21世纪坐时光穿梭机来到了19世纪,想再回去已经回不去了,肿么办?
办法其实还是有的,只要上面的命令行窗口还没有被关掉,你就可以顺着往上找啊找啊,找到那个append GPL
的commit id
是2070a...
,于是就可以指定回到未来的某个版本:
$ git reset --hard 2070a HEAD is now at 2070a38 第一次修改后的readme文档
版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。
再看看readme.md
的内容:
$ cat readme.md # readme 这是一个git举例文件。 git用来控制文本版本。 git可以追溯文本历史版本。
Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD
指针,当你回退版本的时候,Git仅仅是把HEAD从指向“这是一份readme文档”,改为指向“第一次修改后的readme文档”。然后顺便把工作区的文件更新了。所以你让HEAD
指向哪个版本号,你就把当前版本定位在哪。
现在,你回退到了某个版本,关掉了电脑,第二天早上就后悔了,想恢复到新版本怎么办?找不到新版本的commit id
怎么办?
在Git中,总是有后悔药可以吃的。当你用$ git reset --hard HEAD^
回退到上一次版本时,再想恢复到最新版本,就必须找到其对应的commit id
。Git提供了一个命令git reflog
用来记录你的每一次命令:
$ git reflog 2070a38 (HEAD -> leetcode) HEAD@{0}: reset: moving to 2070a 67c788e HEAD@{1}: reset: moving to HEAD^ 2070a38 (HEAD -> leetcode) HEAD@{2}: commit: 第一次修改后的readme文档 67c788e HEAD@{3}: commit: 这是一份readme文档
总结:
-
HEAD
指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id
。 -
穿梭前,用
git log
可以查看提交历史,以便确定要回退到哪个版本。 -
要重返未来,用
git reflog
查看命令历史,以便确定要回到未来的哪个版本。
2.2 工作区和版本库
工作区(Working Directory)
就是你在电脑里能看到的目录,比如我的本地文件夹就是一个工作区。
版本库(Repository)
工作区有一个隐藏目录.git
,这个不算工作区,而是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master
,以及指向master
的一个指针叫HEAD
。
我们把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用git add
把文件添加进去,实际上就是把文件修改添加到暂存区;
第二步是用git commit
提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master
分支,所以,现在,git commit
就是往master
分支上提交更改。
你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
2.3 管理修改
为什么Git比其他版本控制系统设计得优秀,因为Git跟踪并管理的是修改,而非文件。
什么是修改?比如你新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改。
用git diff HEAD -- readme.txt
命令可以查看工作区和版本库里面最新版本的区别:
$ git diff HEAD -- readme.md diff --git a/readme.md b/readme.md index eec7318..14e88a0 100644 --- a/readme.md +++ b/readme.md @@ -4,4 +4,6 @@ git用来控制文本版本。 -git可以追溯文本历史版本。 \ No newline at end of file +git可以追溯文本历史版本。 + +Git非常好用。 \ No newline at end of file
2.4 撤销修改
git checkout -- file
可以丢弃工作区的修改:
$ git checkout -- readme.md
命令git checkout -- readme.txt
意思就是,把readme.txt
文件在工作区的修改全部撤销,这里有两种情况:
一种是readme.txt
自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是readme.txt
已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit
或git add
时的状态。
git checkout -- file
命令中的--
很重要,没有--
,就变成了“切换到另一个分支”的命令。
用命令git reset HEAD <file>
可以把暂存区的修改撤销掉(unstage),重新放回工作区:
$ git reset HEAD readme.md Unstaged changes after reset: M readme.md
git reset
命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD
时,表示最新的版本。
总结:
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file
。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD <file>
,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。
2.5 删除文件
在工作区删除文件:直接在文件管理器中删除,或者使用如下命令:
rm readme.md
此时,工作区与版本库就不一样了。可以使用git status
命令查看那些文件被删除了。
情况一
确定从版本库中删除文件:使用命令git rm
删掉,并且git commit
$ git rm test.txt rm 'test.txt' $ git commit -m "remove test.txt" [master d46f35e] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt
现在,文件就从版本库中被删除了。
情况二
删错了,需要从版本库中恢复文件
$ git checkout -- test.txt
git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
三、远程仓库
为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。
当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。
最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。
3.1 添加远程库
在github上创建一个库(最好与本地库同名)
本地关联远程库(以github为例):
在本地仓库下运行命令:
$ git remote add origin https://github.com/mao-yi-ming/pytest.git
说明:origin
是远程库的名字,这是Git默认的叫法,也可以改成别的,根据你创建的远程库而定。
下一步,就可以把本地库的所有内容推送到远程库上:
$ git push -u origin master
把本地库的内容推送到远程,用git push
命令,实际上是把当前分支master
推送到远程。
由于远程库是空的,我们第一次推送master
分支时,加上了-u
参数,Git不但会把本地的master
分支内容推送的远程新的master
分支,还会把本地的master
分支和远程的master
分支关联起来,在以后的推送或者拉取时就可以简化命令。
从现在起,只要本地作了提交,就可以通过命令:
$ git push origin master
把本地master
分支的最新修改推送至GitHub。
3.2 删除远程库
使用git remote rm <name>
命令。使用前,建议先用git remote -v
查看远程库信息
然后,根据名字删除,比如删除origin
:
$ git remote rm origin
此处的“删除”其实是解除了本地和远程的绑定关系,并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库,需要登录到GitHub,在后台页面找到删除按钮再删除。
3.3 克隆远程库
用命令git clone
克隆一个本地库:
$ git clone git@github.com:michaelliao/gitskills.git
GitHub给出的地址不止一个,还可以用https://github.com/michaelliao/gitskills.git
这样的地址。实际上,Git支持多种协议,默认的git://
使用ssh,但也可以使用https
等其他协议。
四、分支管理
4.1 基本操作
创建分支
$ git branch dev
切换分支(新版switch)
$ git checkout dev $ git switch <name>
创建并切换分支
$ git checkout -b dev git switch -c <name>
git checkout
命令加上-b
参数表示创建并切换,相当于以上两条命令。
查看分支:
$ git branch
git branch
命令会列出所有分支,当前分支前面会标一个*
号。
合并分支
$ git merge dev
git merge
命令用于合并指定分支到当前分支。
删除分支
$ git branch -d dev
4.2 冲突解决
用git log --graph
命令可以看到分支合并图。
4.3 BUG解决
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场使用git stash
命令“储存”起来,然后去修复bug,等后面现场恢复后,再继续工作。
用git stash list
命令查看当前储存的工作现场。
BUG修复完后,想要回到工作现场,有两种方式:
一是用git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除;
二是使用git stash pop
,恢复的同时把stash内容也删了。
可以多次stash,恢复的时候,先用git stash list
查看,然后恢复指定的stash,用命令:
$ git stash apply stash@{0}
在master分支上修复的bug,想要合并到当前dev分支,可以用git cherry-pick <commit>
命令,把bug提交的修改“复制”到当前分支,避免重复劳动。
4.4 feature分支
开发一个新feature,最好新建一个分支;
如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>
强行删除。
4.5 多人协作
-
查看远程库信息,使用
git remote -v
; -
本地新建的分支如果不推送到远程,对其他人就是不可见的;
-
从本地推送分支,使用
git push origin branch-name
,如果推送失败,先用git pull
抓取远程的新提交; -
在本地创建和远程分支对应的分支,使用
git checkout -b branch-name origin/branch-name
,本地和远程分支的名称最好一致; -
建立本地分支和远程分支的关联,使用
git branch --set-upstream branch-name origin/branch-name
; -
从远程抓取分支,使用
git pull
,如果有冲突,要先处理冲突。
4.6 Rebase操作
-
rebase操作可以把本地未push的分叉提交历史整理成直线;
-
rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。
五、标签管理
发布一个版本时,我们通常先在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。
Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。
Git有commit,为什么还要引入tag?
“请把上周一的那个版本打包发布,commit号是6a5819e...”
“一串乱七八糟的数字不好找!”
如果换一个办法:
“请把上周一的那个版本打包发布,版本号是v1.2”
“好的,按照tag v1.2查找commit就行!”
所以,tag就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起。
5.1 创建标签
首先,切换到需要打标签的分支上,然后,敲命令git tag <name>
就可以打一个新标签:
$ git tag v1.0
可以用命令git tag
查看所有标签:
$ git tag v1.0
默认标签是打在最新提交的commit上的。有时候,如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?
方法是找到历史提交的commit id,然后打上就可以了:
$ git log --pretty=oneline --abbrev-commit 12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 101 4c805e2 fix bug 101 e1e9c68 merge with no-ff f52c633 add merge cf810e4 conflict fixed 5dc6824 & simple 14096d0 AND simple b17d20e branch test d46f35e remove test.txt b84166e add test.txt 519219b git tracks changes e43a48b understand how stage works 1094adb append GPL e475afc add distributed eaadf4e wrote a readme file
比方说要对add merge
这次提交打标签,它对应的commit id是f52c633
,敲入命令:
$ git tag v0.9 f52c633
再用命令git tag
查看标签:
$ git tag v0.9 v1.0
注意,标签不是按时间顺序列出,而是按字母排序的。可以用git show <tagname>
查看标签信息:
$ git show v0.9 commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9) Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 21:56:54 2018 +0800 add merge diff --git a/readme.txt b/readme.txt ...
还可以创建带有说明的标签,用-a
指定标签名,-m
指定说明文字:
$ git tag -a v0.1 -m "version 0.1 released" 1094adb
用命令git show <tagname>
可以看到说明文字。
5.2 操作标签
删除标签
$ git tag -d v0.1
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
如果要推送某个标签到远程,使用命令git push origin <tagname>
:
$ git push origin v1.0
或者,一次性推送全部尚未推送到远程的本地标签:
$ git push origin --tags
删除远程标签
先删除本地的
$ git tag -d v0.9
然后,从远程删除。删除命令也是push,但是格式如下:
$ git push origin :refs/tags/v0.9