Git简介
工作区
就是电脑里面里面能看到的目录,如learngit
文件夹就是一个工作区:
暂存区
Git是目前世界上最先进的分布式版本控制系统(没有之一)。
通俗来讲,可以记录文件的改动,也可以让同事协同编辑,不需要自己管理与保存,都由git来负责,跟下图类似。
版本库(仓库)
工作区有一个隐藏目录.git
,这个不算工作区,而是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master
,以及指向master
的一个指针叫HEAD
。
这个目录(仓库)里面的所有文件都可以被Git管理起来,每个文件的修改、删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。
创造仓库
在你想管理的目录下输入以下命令:
git init
当前目录下多了一个.git
的目录,这个目录是Git来跟踪管理版本库的,不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。
把文件放到Git仓库
- 第一步,用命令
git add
告诉Git,实际上就是把文件修改添加到暂存区:
$ git add readme.txt
$ git add file2.txt file3.txt //git add 也可以合在一起
执行上面的命令,没有任何显示,这就对了,Unix的哲学是“没有消息就是好消息”,说明添加成功。
- 第二步,用命令
git commit
告诉Git,实际上就是把暂存区的所有内容提交到当前分支:
$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
1 file changed, 2 insertions(+)
-m
后面输入的是本次提交的说明,很重要,一定要记得输入具体说明。
注意事项
- Git命令必须在Git仓库目录内执行(
git init
除外),在仓库目录外执行是没有意义的。 - 添加某个文件时,该文件必须在当前目录下存在,用
ls
或者dir
命令查看当前目录的文件,看看文件是否存在,或者是否写错了文件名。
常见命令
git status
输入此命令,可以知道仓库当前的状态,例如哪些文件被修改了,既文件的状态,但是不能查看具体哪里变动了。
git diff
弥补git status的缺陷,可以查看具体文件具体变动。
git log
git log
命令显示从最近到最远的提交日志。
$ git log
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:06:15 2018 +0800
append GPL
commit e475afc93c209a690c39c13a46716e8fa000c366
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:03:36 2018 +0800
add distributed
commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 20:59:18 2018 +0800
wrote a readme file
如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline
参数:
$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL
e475afc93c209a690c39c13a46716e8fa000c366 add distributed
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file
一大串类似1094adb...
的是commit id
(版本号)
git reset
git reset
命令:将当前版本回退到某个版本(版本回退)
$ git reset --hard HEAD^
//在Git中,用HEAD表示当前版本,也就是最新的提交1094adb...(注意我的提交ID和你的肯定不一样),上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100
HEAD is now at e475afc add distributed
git reset --hard 1094a //版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。
HEAD is now at 83b0afe append GPL
Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD
指针,当你回退版本的时候,Git仅仅是把HEAD从指向append GPL
:
┌────┐
│HEAD│
└────┘
│
└──▶ ○ append GPL
│
○ add distributed
│
○ wrote a readme file
改为指向add distributed
:
┌────┐
│HEAD│
└────┘
│
│ ○ append GPL
│ │
└──▶ ○ add distributed
│
○ wrote a readme file
然后顺便把工作区的文件更新了。所以你让HEAD
指向哪个版本号,你就把当前版本定位在哪。
git reflog
git reflog
用来记录你的每一次命令,可查找commit id用于版本回退或者恢复某个版本:
在Git中,总是有后悔药可以吃的。当你用$ git reset --hard HEAD^
回退到add distributed
版本时,再想恢复到append GPL
,就必须找到append GPL
的commit id。可以用git reflog
查找。
$ git reflog
e475afc HEAD@{1}: reset: moving to HEAD^
1094adb (HEAD -> master) HEAD@{2}: commit: append GPL
e475afc HEAD@{3}: commit: add distributed
eaadf4e HEAD@{4}: commit (initial): wrote a readme file
终于舒了口气,从输出可知,append GPL
的commit id是1094adb
,现在,你又可以乘坐时光机回到未来了。
场景
远程仓库
文件修改
撤销修改
-
方法一:
-
可以用命令
git checkout -- readme.txt
,把readme.txt
文件在工作区的修改全部撤销,这里有两种情况:-
readme.txt
修改后还没有放到暂存区:撤销修改就回到和版本库一模一样的状态。
-
readme.txt
已经添加到暂存区后,又做了修改:撤销修改就回到添加到暂存区后的状态。
-
总之,就是让这个文件回到最近一次git commit
或git add
时的状态。
-
方法二:
-
git reset
+git checkout -- readme.txt
-
git reset
:命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD
时,表示最新的版本。$ git reset HEAD readme.txt Unstaged changes after reset: M readme.txt
-
丢弃工作区的修改
$ git checkout -- readme.txt $ git status On branch master nothing to commit, working tree clean
-
一种特殊情况:不但改错了东西,还从暂存区提交到了版本库,想要撤销本次提交【前提是没有推送到远程库】,可以用git reset
进行版本回退。
删除文件
git add test.txt
git commit -m "add test.txt"
-
先用
rm test.txt
-
删除后,会导致工作区和版本库不一致,所以有
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都把它们串成一条时间线,这条时间线就是一个分支。
截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master
分支。HEAD
指向的就是当前分支。
一开始的时候,master
分支是一条线,Git用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点:
HEAD
│
│
▼
master
│
│
▼
┌───┐ ┌───┐ ┌───┐
│ │───▶│ │───▶│ │
└───┘ └───┘ └───┘
每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长。
当我们创建新的分支,例如dev
时,Git新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上:
master
│
│
▼
┌───┐ ┌───┐ ┌───┐
│ │───▶│ │───▶│ │
└───┘ └───┘ └───┘
▲
│
│
dev
▲
│
│
HEAD
你看,Git创建一个分支很快,因为除了增加一个dev
指针,改改HEAD
的指向,工作区的文件都没有任何变化!
不过,从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
master
│
│
▼
┌───┐ ┌───┐ ┌───┐ ┌───┐
│ │───▶│ │───▶│ │───▶│ │
└───┘ └───┘ └───┘ └───┘
▲
│
│
dev
▲
│
│
HEAD
假如我们在dev
上的工作完成了,就可以把dev
合并到master
上。Git怎么合并呢?最简单的方法,就是直接把master
指向dev
的当前提交,就完成了合并:
HEAD
│
│
▼
master
│
│
▼
┌───┐ ┌───┐ ┌───┐ ┌───┐
│ │───▶│ │───▶│ │───▶│ │
└───┘ └───┘ └───┘ └───┘
▲
│
│
dev
所以Git合并分支也很快!就改改指针,工作区内容也不变!
合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支:
HEAD
│
│
▼
master
│
│
▼
┌───┐ ┌───┐ ┌───┐ ┌───┐
│ │───▶│ │───▶│ │───▶│ │
创建分支与合并分支
创建分支
$ git branch dev //创建dev分支
-
如果想创建+切换,如下所示
$ git checkout -b dev Switched to a new branch 'dev'
git checkout
命令加上-b
参数表示创建并切换,相当于以下两条命令:$ git branch dev $ git checkout dev Switched to branch 'dev'
切换分支
$ git checkout dev
查看分支
$ git branch
* dev
master
git branch
命令会列出所有分支,当前分支前面会标一个*
号。
合并分支
$ git checkout master
Switched to branch 'master'
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
把dev
分支的工作成果合并到master
分支上:
git merge
命令用于合并指定分支到当前分支。合并后,再查看readme.txt
的内容,就可以看到,和dev
分支的最新提交是完全一样的。
注意到上面的Fast-forward
信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master
指向dev
的当前提交,所以合并速度非常快。
当然,也不是每次合并都能Fast-forward
,我们后面会讲其他方式的合并。
合并完成后,就可以放心地删除dev
分支了:
$ git branch -d dev
Deleted branch dev (was b17d20e).
删除分支
$ git branch -d dev
Deleted branch dev (was b17d20e).
$ git branch -D feature-vulcan //强行删除
Deleted branch feature-vulcan (was 287773e).
解决冲突
参考之前写的文章,其实就是,将冲突的文件修改,然后再git add, git commit就行。
https://blog.csdn.net/weixin_49708955/article/details/130570666?spm=1001.2014.3001.5501
修复bug
场景:如果你其他分支有Bug,但是你目前的分支正在开发,那怎么办呢?直接切换分支修改?
直接切换分支会导致的问题
经过测试,若直接从一个分支(xsy)切换到另一条分支(main),xsy分支创造的文件,在main分支里依然存在,会影响正在开发任务的需求。
所以,就需要用git stash这个命令来隐藏你目前分支开发的需求。
例子演示
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101
来修复它,但是,等等,当前正在dev
上进行的工作还没有提交,并且dev分支的代码只开发到了一半,此时可以用stash
功能,可以把当前工作现场【工作区和暂存区一起隐藏】“储藏”起来,等以后恢复现场后继续工作:
$ git status
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.py
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
然后在哪条分支上【假设main】修复Bug,就切换回去,并且从该分支【假设mian】创建临时分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git checkout -b issue-101
Switched to a new branch 'issue-101'
现在修复bug,需要把“Git is free software …”改为“Git is a free software …”,然后提交:
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后,切换到master
分支,并完成合并,最后删除issue-101
分支:
$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
bug修复后,切到dev
分支干活了!
$ git switch dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean
工作区是干净的,刚才的工作现场存到哪去了?用git stash list
命令看看:
$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除;
另一种方式是用git stash pop
,恢复的同时把stash内容也删了:
$ git stash pop
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.py
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list
查看,就看不到任何stash内容了:
$ git stash list
你可以多次stash,恢复的时候,先用git stash list
查看,然后恢复指定的stash,用命令:
$ git stash apply stash@{0}
但是main分支有的bug,dev也有,因为dev分支早期是从main分支演化出来的,所以也要修复dev的bug。
我们只需要把4c805e2 fix bug 101
这个提交所做的修改“复制”到dev分支。注意:我们只想复制4c805e2 fix bug 101
这个提交所做的修改,并不是把整个master分支merge过来。
为了方便操作,Git专门提供了一个cherry-pick
命令,让我们能复制一个特定的提交到当前分支:
$ git branch
* dev
master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
Git自动给dev分支做了一次提交,注意这次提交的commit是1d4b803
,它并不同于master的4c805e2
,因为这两个commit只是改动相同,但确实是两个不同的commit。用git cherry-pick
,我们就不需要在dev分支上手动再把修bug的过程重复一遍。
多人协作
查看远程库
要查看远程库的信息,用git remote
:
$ git remote
origin
或者,用git remote -v
显示更详细的信息:
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
上面显示了可以抓取和推送的origin
的地址。如果没有推送权限,就看不到push的地址。
推送分支
推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:
$ git push origin master
如果要推送其他分支,比如dev
,就改成:
$ git push origin dev
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
master
分支是主分支,因此要时刻与远程同步;dev
分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;- bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
- feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
抓取分支
git branch --set-upstream-to=origin/<branch> dev
如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to origin/。
rebase
暂时略,平时少用。
标签管理
什么是标签
标签也是版本库的一个快照,类似于ip和域名的关系。就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。
创建标签
切换到需要打标签的分支上,git tag <name>
就可以打一个新标签:
$ 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
创建有说明的标签
还可以创建带有说明的标签,用-a
指定标签名,-m
指定说明文字:
$ git tag -a v0.1 -m "version 0.1 released" 1094adb
查看标签
$ git tag
v0.9
v1.0
//不是按时间顺序列出的,而是按字母排序列出的
查看标签具体信息
$ 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
...
删除标签
标签未推送远程
$ git tag -d v0.1
Deleted tag 'v0.1' (was f15b0dd)
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
标签已推送远程
如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除:
$ git tag -d v0.9
Deleted tag 'v0.9' (was f52c633)
然后,从远程删除。删除命令也是push,但是格式如下:
$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git
- [deleted] v0.9
推送标签
推送一个本地标签
如果要推送某个标签到远程,使用命令git push origin <tagname>
:
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0
推送全部未推送过的本地标签本地
或者,一次性推送全部尚未推送到远程的本地标签:
$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v0.9 -> v0.9
ag 'v0.1' (was f15b0dd)
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
标签已推送远程
如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除:
$ git tag -d v0.9
Deleted tag 'v0.9' (was f52c633)
然后,从远程删除。删除命令也是push,但是格式如下:
$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git
- [deleted] v0.9
推送标签
推送一个本地标签
如果要推送某个标签到远程,使用命令git push origin <tagname>
:
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0
推送全部未推送过的本地标签本地
或者,一次性推送全部尚未推送到远程的本地标签:
$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v0.9 -> v0.9