创建git仓库

我们一般是在一个空目录下创建一个git仓库,使用git init命令就可以把目录变成可以管理的仓库

mkdir learngit命令用来创建一个新的空目录;cd learngit命令用于进入这个新建的目录;pwd命令用于显示当前目录

git init命令可以将这个命令变成可以管理的仓库,执行完此命令后当前目录下就多了一个.git的目录(默认是隐藏的,可以使用ls -ah命令查看),这个目录是git用来跟踪管理版本库的,不要手动修改这个目录里面的文件,以免破坏git仓库

$ mkdir learngit

$ cd learngit

$ pwd
/e/yuli/learngit

$ git init
Initialized empty Git repository in E:/yuli/learngit/.git/

把文件添加到git仓库

完成git仓库的初始化之后我们就可以把文件放到仓库中进行管理了,现在我在learngit目录下创建了一个新的文件学习git的笔记.md并在里面书写了内容

1.现在我们使用git status命令来查看git仓库的状态

$ git status
On branch master

No commits yet

Untracked files:
(use "git add <file>..." to include in what will be committed)
"\345\255\246\344\271\240git\347\232\204\347\254\224\350\256\260.md"

nothing added to commit but untracked files present (use "git add" to track)

2.上面git status命令的输出告诉我们,可以使用git add <file>...命令把文件添加到仓库(git add .命令可以将所有更改文件全部添加到git仓库)

$ git add 学习git的笔记.md
//执行完这个命令没有任何的输出但是文件已经添加成功

3.接下来就可以使用git commit -m '这里写本次提交的描述'命令把文件提交到git仓库

$ git commit -m '第一次提交文件'
[master (root-commit) f22ba99] 第一次提交文件
1 file changed, 45 insertions(+)
create mode 100644 "\345\255\246\344\271\240git\347\232\204\347\254\224\350\256\260.md"

现在我们已经成功提交了一个文件到git仓库中,现在我们可以继续修改文件的内容,随后运行git status命令查看git仓库现在的状态

$ git status
On branch master
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: "\345\255\246\344\271\240git\347\232\204\347\254\224\350\256\260.md"

no changes added to commit (use "git add" and/or "git commit -a")

运行命令后git仓库告诉我们有文件被修改了,但是没有说具体的修改内容,想要查看具体修改内容需要使用git diff命令

版本回退

上面我们已经学会了如何将git文件提交到git仓库里进行保管,但是这还不能满足我们的工作需要,比如工作中如果误提交了什么错误的代码或文件,我们想要撤销提交,就还需要学习git的版本回退

1.我们先来使用git log命令来查看一下我们的历史提交记录

$ git log
commit 88abac605904cdfa330bb985db31703477c770d0 (HEAD -> master)
Author: yuli <yuli@xxxx.com>
Date: Fri Nov 6 09:51:18 2020 +0800

测试版本回退3

commit f751895f583faa1e9b65986ea468d1a4fc4dcd2a
Author: yuli <yuli@xxxx.com>
Date: Fri Nov 6 09:50:47 2020 +0800

测试版本回退2

commit 3cd8a4847dd18b83eacfce3cb4dff2da3e3f580c
Author: yuli <yuli@xxxx.com>
Date: Fri Nov 6 09:50:08 2020 +0800

测试版本回退1

commit 435839386a57c914a4051e47850d061d242182ec
Author: yuli <yuli@xxxx.com>
Date: Fri Nov 6 09:49:17 2020 +0800

md文件修改

commit f22ba99536079dba4208be755f607b91925958d5
Author: yuli <yuli@xxxx.com>
Date: Thu Nov 5 16:57:30 2020 +0800

第一次提交文件

git log命令显示从最近到最远的提交日志,如果嫌输出信息太多,可以加上--pretty=oneline参数

$ git log --pretty=oneline
88abac605904cdfa330bb985db31703477c770d0 (HEAD -> master) 测试版本回退3
f751895f583faa1e9b65986ea468d1a4fc4dcd2a 测试版本回退2
3cd8a4847dd18b83eacfce3cb4dff2da3e3f580c 测试版本回退1
435839386a57c914a4051e47850d061d242182ec md文件修改
f22ba99536079dba4208be755f607b91925958d5 第一次提交文件

上面我们看到的一大串十六进制数字,是commit id版本号,在git中,用HEAD表示当前版本,也就是最新提交,上个版本就是HEAD^,上上个版本就是HEAD^^,如果往上的版本比较多的话,写100个^比较不容易接受,所以可以写成HEAD~100

现在我们要把当前版本回退到上一个版本,可以使用git reset命令

$ git reset --hard HEAD~1
HEAD is now at f751895 测试版本回退2

现在我们就已经成功将git仓库的内容回退到了上一个版本的内容,git的版本回退速度非常快,因为在git内部有个指向当前版本的HEAD指针,当你版本回退的时候,git仅仅是把HEAD改为指向上一次提交的版本,然后顺便把工作区的文件更新,所以HEAD指向哪个版本号,就把当前版本定位到哪里

当然,如果你回退版本后突然后悔,想恢复回退前的版本,这时候就必须找到对应版本的commit id,使用git reflog命令可以用来查看git的每一次命令记录,这样就可以找到每次提交对应的版本号,方便回到回退前的版本

$ git reflog
f751895 (HEAD -> master) HEAD@{0}: reset: moving to HEAD~1
88abac6 HEAD@{1}: commit: 测试版本回退3
f751895 (HEAD -> master) HEAD@{2}: commit: 测试版本回退2
3cd8a48 HEAD@{3}: commit: 测试版本回退1
4358393 HEAD@{4}: commit: md文件修改
f22ba99 HEAD@{5}: commit (initial): 第一次提交文件

下面我们使用git reset --hard commit_id命令回到最初的版本

$ git reset --hard 88abac6
HEAD is now at 88abac6 测试版本回退3

工作区和暂存区

工作区就是在我们电脑里能看到的目录,在工作区里有一个隐藏的.git文件夹,这个是git的版本库,不算是工作区,git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD

图1

我们使用的git add命令实际上是把文件修改添加到暂存区;而git commit命令实际上就是把暂存区的所有内容提交到当前分支

因此我们创建git版本库时,git为我们创建了唯一一个master分支,所以现在git commit就是往master分支上提交更改

现在我们先对readme.txt文件做个修改,然后在工作区新增一个LICENSE文本文件,然后先用git status命令查看一下文件状态

$ git status
On branch master
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.txt

Untracked files:
(use "git add <file>..." to include in what will be committed)
LICENSE

no changes added to commit (use "git add" and/or "git commit -a")

git非常清楚地告诉我们,readme.txt文件被修改了,而LICENSE文件还没有被添加过,所以它的状态是Untracked。现在使用两次git add命令把readme.txt文件和LICENSE文件都添加到暂存区或者直接使用一次git add .命令添加所有有更改的文件到暂存区。再用git status命令查看一下文件状态

$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: LICENSE
modified: readme.txt

现在readme.txt文件和LICENSE文件就都被添加到暂存区中了,可以使用git commit命令将它们提交到git仓库,一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是”干净”的

$ git status
On branch master
nothing to commit, working tree clean

git的优秀之处在于,它管理的是修改,而非文件。

现在我们在readme.txt文件中添加一行修改,并使用git status命令查看文件状态

$ git status
On branch master
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.txt

可以发现,git告诉我们使用git restore <file>...命令可以丢弃工作区的修改,如果更改已经被添加到暂存区了,则可以使用git restore --staged <file>...命令取消暂存

远程仓库

添加远程仓库,使用命令git remote add origin git@server-name:path/repo-name.git

把本地仓库的内容推送的远程仓库使用git push命令,

从远程仓库克隆使用命令git clone git@server-name:path/repo-name.git,

从远程仓库拉取最新代码到本地使用git pull命令

分支管理

创建与合并分支

每次提交,git都把它们串成一条时间线,这条时间线就是一个分支,截止到目前,只有一条时间线,在git里,这个分支叫主分支,即master分支。HEAD严格来说不是指向提交,而是指向mastermaster才是指向提交的,所以,HEAD指向的就是当前分支。

一开始的时候,master分支是一条线,git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:

图2

每次提交,master分支都会向前移动一步,这样,随着不断的提交,master分支的线也越来越长。

当我们创建新的分支,例如dev时,git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev

图3

git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化。

不过从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针就往前移动一步,而master指针不变:

图4

假如我们在dev上的工作完成了,就可以把dev合并到master分支上。最简单的方法就是直接把master指向dev的当前提交,就完成了合并:

图5

所以git合并分支也很快,就改改指针,工作区内容也不变。合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,删掉后,我们就剩下一条master分支:

图6

下面创建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 branch命令查看当前分支:

$ git branch
* dev
master

git branch命令会列出所有分支,当前分支前面会标一个*

然后我们可以在dev分支上正常提交,比如对readme.txt做个修改,然后提交,dev分支的工作完成,我们就可以切换回master分支:

$ git checkout master
Switched to branch 'master'

切换回master分支后,再查看readme.txt文件,会发现刚才添加的内容不见了,因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:

图7

现在,我们把dev分支的工作成果合并到master分支上,使用git merge命令

$ git merge dev
Updating 6b3ebf0..e47ac2a
Fast-forward
readme.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

git merge命令用于合并指定分支到当前分支,合并后,再查看readme.txt文件的内容,,就可以看到和dev分支的最新提交是完全一样的。注意到上面的Fast-forward信息,git告诉我们,这次合并是”快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。

合并完成后,就可以放心地删除dev分支了:

$ git branch -d dev
Deleted branch dev (was e47ac2a).

删除后查看branch就只剩下master分支了

$ git branch
* master

前面我们使用的切换分支的命令是git checkout <branch>,实际上,切换分支操作,使用git switch命令更科学,创建并切换到新的dev分支可以使用:

$ git switch -c dev
Switched to a new branch 'dev'

直接切换到已有的master分支,可以使用:

$ git switch master
Switched to branch 'master'

解决冲突

合并分支有时候也会出现冲突,所以我们还要学习如何解决冲突

创建一个新的分支feature1分支,继续我们新分支的开发,修改readme.txt文件

$ git switch -c feature1
Switched to a new branch 'feature1'

feature1分支上提交:

$ git add .

$ git commit -m "feature1 branch commit"
[feature1 71cdbd8] feature1 branch commit
1 file changed, 3 insertions(+), 1 deletion(-)

切换到master分支

$ git switch master
Switched to branch 'master'

master分支上,修改readme.txt文件并提交

现在,masterfeature1分支各自都分别有新的提交。变成了这样:

图8

这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突:

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

果然冲突了,git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交。git status命令也可以告诉我们冲突的文件

$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)

Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看readme.txt文件的内容

测试版本回退第一次提交
测试版本回退第二次提交
测试版本回退第三次提交

暂存区的概念

新的分支

<<<<<<< HEAD
仙女棒
=======
可可爱爱没有脑袋
>>>>>>> feature1

git用<<<<<<<=======>>>>>>>标记出不同分支的内容,我们可以修改后保存,再提交

$ git add .

$ git commit -m "fix conflicts"
[master 27433e4] fix conflicts

现在masterfeature1分支变成了如下图所示

图9

用带参数的git log命令也可以看到分支合并的情况

$ git log --graph --pretty=oneline --abbrev-commit
* 27433e4 (HEAD -> master) fix conflicts
|\
| * 71cdbd8 (feature1) feature1 branch commit
* | ab3cfe4 master branch commit
|/
* e47ac2a (dev) dev分支的提交
* 6b3ebf0 understand how stage works
* 88abac6 测试版本回退3
* f751895 测试版本回退2
* 3cd8a48 测试版本回退1
* 4358393 md文件修改
* f22ba99 第一次提交文件

最后,删除feature1分支,工作完成。

$ git branch -d feature1
Deleted branch feature1 (was 71cdbd8).

git log --graph命令可以看到分支合并图

分支管理策略

通常,合并分支时,如果可能,git会使用Fast forward模式,但在这种模式下,删除分支后,会丢掉分支信息。如果要强制禁用Fast forward模式,git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。

下面我们学习一下使用--no-ff方式的git merge

首先,依然创建并切换dev分支

$ git switch -c dev
Switched to a new branch 'dev'

修改readme.txt文件,并提交一个新的commit

$ git add .
$ git commit -m "bilibili"
[dev a5bfb36] bilibili
1 file changed, 2 insertions(+)

现在我们切换回master

$ git switch master
Switched to branch 'master'

准备合并dev分支,注意使用--no-ff参数,表示禁用Fast forward

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 2 ++
1 file changed, 2 insertions(+)

因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。

合并后我们使用git log查看分支历史

$ git log --graph --pretty=oneline --abbrev-commit
* 5d366bf (HEAD -> master) merge with no-ff
|\
| * a5bfb36 (dev) bilibili
|/
* 27433e4 fix conflicts
|\
| * 71cdbd8 feature1 branch commit
* | ab3cfe4 master branch commit
|/
* e47ac2a dev分支的提交
* 6b3ebf0 understand how stage works
* 88abac6 测试版本回退3
* f751895 测试版本回退2
* 3cd8a48 测试版本回退1
* 4358393 md文件修改
* f22ba99 第一次提交文件

可以看到不用Fast forward模式,merge后就像这样

图10

在实际开发中,我们应该按照几个基本原则进行分支管理,首先master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;

干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;你和你的小伙伴们都在dev分支上干活,每个人都有自己的分支,时不时往dev分支上合并就可以了。

合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。

Bug分支

软件开发中,bug就像家常便饭一样,有了bug就需要修复,在git中,由于分支是如此的强大,所以每个bug都可以通过一个新的临时分支来修复,修复后,合并分支然后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是等等,当前正在dev上进行的工作还没有提交

$ git status
On branch dev
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.txt

no changes added to commit (use "git add" and/or "git commit -a")

并不是你不想提交,只是工作进行到一半,还没办法提交,预计还需要1天时间,但是,必须在两个小时内修复bug,这时就可以使用git提供的另外一个命令git stash,其作用是把当前工作现场储藏起来,等以后恢复现场后继续工作:

$ git stash
Saved working directory and index state WIP on dev: a5bfb36 bilibili

现在用git status查看工作区,就是干净的,除非有没有被git管理的文件,因此可以放心地创建分支来修复bug。

首先确定需要在哪个分支上修复bug,假定需要在master分支上修复,就从master创建临时分支

$ git switch master
Switched to branch 'master'

$ git switch -c issue-101
Switched to a new branch 'issue-101'

issue-101分支上修复完bug后,切换到master分支,并完成合并,最后删除issue-101分支即可

随后我们回到dev分支,撤销之前的储藏;git stash list命令可以查看储藏列表

$ git stash list
stash@{0}: WIP on dev: a5bfb36 bilibili

恢复储藏有两种方法,一种是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;另一种方式是用git stash pop,恢复的同时把stash内容也删了。

$ git stash pop
On branch dev
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.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (646da603aa0513d92cb70af8fca055586e2f4c96)

再用git stash list命令查看,就看不到任何内容了

$ git stash list

你可以多次stash,恢复的时候,先用git stash list命令查看,然后恢复指定的stash;用命令$ git stash apply stash@{0}

master分支上修复了bug后,我们要想一想,dev分支是早期从master分支分出来的,所以这个bug其实在当前dev分支上也存在,这时候,我们只需要把[issue-101 9203417] fix bug这个提交所做的修改“复制”到dev分支。注意:我们只想复制[issue-101 9203417] fix bug这个提交所做的修改,并不是把整个master分支merge过来。为了方便操作,git提供了一个专门的cherry-pick命令,让我们能复制一个特定的提交到当前分支。

$ git branch
* dev
master

$ git cherry-pick 9203417
[dev c5992b0] fix bug
Date: Mon Nov 9 19:56:43 2020 +0800
1 file changed, 3 insertions(+), 1 deletion(-)

Git自动给dev分支做了一次提交,注意这次提交的commit是c5992b0,它并不同于master的9203417,因为这两个commit只是改动相同,但确实是两个不同的commit。用git cherry-pick,我们就不需要在dev分支上手动再把修bug的过程重复一遍。

既然可以在master分支上修复bug后,在dev分支上可以“重放”这个修复过程,那么直接在dev分支上修复bug,然后在master分支上“重放”当然也可以,不过仍然需要git stash命令保存现场,才能从dev分支切换到master分支。

Feature分支

在软件开发中,总有无穷无尽的新功能要不断添加进来,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后删除该feature分支。

现在我们接到一个任务,开发代号为Vulcan的新功能,于是准备开发:

$ git switch -c feature-vulcan
Switched to a new branch 'feature-vulcan'

开发完毕后,

$ git add .

$ git status
On branch feature-vulcan
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: vulcan.py

$ git commit -m "add feature vulcan"
[feature-vulcan b99d0d2] add feature vulcan
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 vulcan.py

切回dev准备合并分支

$ git switch dev
Switched to branch 'dev'

一切顺利的话,feature分支和bug分支是类似的,合并,然后删除
但是,就在此时,接到上级命令,因经费不足,新功能必须取消,虽然白干了,但是这个包含机密资料的分支还是必须就地销毁

$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

销毁失败。git友情提示,feature-vulcan分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用大写的-D参数

现在我们强制删除:

$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was b99d0d2).

多人协作

当从远程仓库克隆时,实际上git自动把本地的master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin。要查看远远程库的信息,用git remote命令,或者用git remote -v显示更详细的信息(只显示可以拉取和推送的origin的地址,如果没有推送权限,就看不到push的地址)

推送分支:

推送分支,就是把该分支上的所有本地提交推送到远程库,推送时,要指定本地分支,这样,git就会把该分支推送到远程库对应的远程分支上

$ git push origin master

如果要推送其他分支,比如dev,就改成:

$ git push origin dev

但是,并不是一定要把本地分支往远程推送,

  • master分支是主分支。因此要时刻与远程同步;
  • dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
  • bug分支只用于在本地修复bug,就没有必要推到远程了,除非老板要看看你每周到底修复了几个bug;
  • feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发;

拉取分支:

多人协作时,大家都会往masterdev分支上推送各自的修改。

当从远程库clone时,默认只能看到本地的master分支,现在你需要在dev分支上开发,就必须创建远程origindev分支到本地,可以使用这个命令创建本地dev分支:

$ git switch -c dev origin/dev

现在,我们就可以在dev上继续修改,然后时不时地把dev分支push到远程:git push origin dev

你的小伙伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件做了修改,并试图推送;git会提示推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,先用git pull把最新的提交从origin/dev抓下来,然后在本地合并,解决冲突,再推送

如果git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置devorigin/dev的链接:

$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

之后再git pull,这回git pull成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再git push

标签管理

发布一个版本时,我们通常先在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本,将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来,所以标签也似乎版本库的一个快照

git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。

创建标签

在git中打标签非常简单,首先切换到需要打标签的分支上:

$ git branch
* dev
master

$ git switch master
Switched to branch 'master'

然后敲命令:git tag <name>就可以打一个新标签

$ git tag v1.0

可以用命令git tag查看所有标签:

$ git tag
v1.0

默认标签是打在最新提交的commit上的,有时候,如果忘了打标签,比如现在已经是周五了,但应该在周一打的标签没有打,这个时候应该找到历史提交的commit-id,然后打上就可以了

$ git log --pretty=oneline --abbrev-commit
9203417 (HEAD -> master, tag: v1.0) fix bug
5d366bf merge with no-ff
a5bfb36 bilibili
27433e4 fix conflicts
ab3cfe4 master branch commit
71cdbd8 feature1 branch commit
e47ac2a dev分支的提交
6b3ebf0 understand how stage works
88abac6 测试版本回退3
f751895 测试版本回退2
3cd8a48 测试版本回退1
4358393 md文件修改
f22ba99 第一次提交文件

比如要对fix conflicts这次提交打标签,它对应的commit id是27433e4,敲入命令:

$ git tag v0.5 27433e4

再用命令git tag查看所有标签

$ git tag
v0.5
v1.0

注意,标签不是按时间顺序列出,而是按字母排序的,可以用git show <tagname>查看标签信息

$ git show v0.5
commit 27433e440ef4670a3c7ec593f46e3600572c3c71 (tag: v0.5)
Merge: ab3cfe4 71cdbd8
Author: yuli <yuli@xxxx.com>
Date: Mon Nov 9 17:17:05 2020 +0800

fix conflicts

diff --cc readme.txt
index bdf3ddd,21451bf..b1a9441
--- a/readme.txt
+++ b/readme.txt
@@@ -6,4 -6,4 +6,5 @@@

新的分支

- 仙女棒
-可可爱爱没有脑袋
++仙女棒
++可可爱爱没有脑袋

可以看到v0.5确实打在fix conflicts这次提交上。

还可以创建带有说明的标签,用-a指定标签名,-m指定说明文字,即用命令:git tag -a <tagname> -m "blablabla..."

$ git tag -a v0.2 -m "version 0.2 released" e47ac2a

用命令git show <tagname>可以看到说明文字

$ git show v0.2
tag v0.2
Tagger: yuli <yuli@xxxx.com>
Date: Tue Nov 10 10:57:38 2020 +0800

version 0.2 released

commit e47ac2a026ea6558436175552f37e5dc4830d5a7 (tag: v0.2)
Author: yuli <yuli@xxxx.com>
Date: Mon Nov 9 15:34:35 2020 +0800

dev分支的提交

diff --git a/readme.txt b/readme.txt
index e544e38..b7a6f01 100644
--- a/readme.txt
+++ b/readme.txt
@@ -2,4 +2,6 @@
测试版本回退第二次提交
测试版本回退第三次提交

-暂存区的概念
\ No newline at end of file
+暂存区的概念
+
+新的分支
\ No newline at end of file

管理标签

如果标签打错了,也可以删除:

$ git tag -d v0.2
Deleted tag 'v0.2' (was 2d4784e)

因为创建的标签都只存储在本地,不会自动推送到远程,所以打错的标签可以在本地安全地删除。

如果要推送某个标签到远程,使用命令git push origin <tagname>

或者,一次性推送全部尚未推送到远程的本地标签:git push origin --tags;

如果标签已经推送到远程,要删除远程标签就有一点麻烦,先从本地删除:git tag -d <tagname>

然后,从远程删除。删除命令也是push,但是格式如下:git push origin :refs/tags/<tagname>

要看看是否真的从远程库删除了标签,可以登陆远程仓库查看。

这个笔记是在学习git的过程中,为了加深印象所记,参考了廖雪峰老师的git教程,如有不明白的地方可以参考原教程:https://www.liaoxuefeng.com/wiki/896043488029600