安装git
如果你正在使用Mac做开发,有两种安装git
的方法。
- 一是安装homebrew,然后通过homebrew安装Git,具体方法请参考homebrew的文档:http://brew.sh/。
- 第二种方法更简单,登录https://developer.apple.com/download/more/ 然后下载
dmg
安装,或者Terminal
运行xcode-select --install
然后点击安装。
安装完成后,还需要最后一步设置,在命令行输入:
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
创建git仓库
git
仓库,你可以简单理解成一个目录,这个目录里面的所有文件都可以被git
仓库管理起来,每个文件的修改、删除,git
都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。
首先创建一个空目录:
➜ desktop git:(master) ✗ mkdir learngit
➜ desktop git:(master) ✗ cd learngit
➜ learngit git:(master) ✗ pwd
/Users/michael/desktop/learngit
➜ learngit git:(master) ✗
注意:pwd
命令用于显示当前目录的相对路径。
通过git init
命令初始化一个git
仓库:
➜ learngit git:(master) ✗ git init
Initialized empty Git repository in /Users/michael/Desktop/learngit/.git/
➜ learngit git:(master)
通过ls -ah
命令可以看到当前目录下多了一个.git
的目录,这个目录就是git
来跟踪管理git
库的。
➜ learngit git:(master) ls -ah
. .. .git
➜ learngit git:(master)
创建测试文本文件
➜ learngit git:(master) touch readme.txt
➜ learngit git:(master) ✗ ls
readme.txt
➜ learngit git:(master) ✗
通过vim
命令添加测试内容。
➜ learngit git:(master) ✗ vim readme.txt
2 files to edit
➜ learngit git:(master) ✗
一定要放到
learngit
目录下(子目录也行),因为这是一个git
仓库,放到其他地方git
再厉害也找不到这个文件。
把文件添加到git
仓库
➜ learngit git:(master) ✗ git add readme.txt
➜ learngit git:(master) ✗
把文件提交到git
仓库
➜ learngit git:(master) ✗ git commit -m "wrote a readme file"
[master (root-commit) e030980] wrote a readme file
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 readme.txt
➜ learngit git:(master) ✗
git status
修改刚才提交的readme.txt
文件,git status
:查看git
仓库当前的状态
➜ learngit git:(master) ✗ git status
On branch master
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
no changes added to commit (use "git add" and/or "git commit -a")
➜ learngit git:(master) ✗
git diff
git diff
可以查看文件的修改内容
diff --git a/readme.txt b/readme.txt
index e69de29..4d53f0e 100644
--- a/readme.txt
+++ b/readme.txt
@@ -0,0 +1,2 @@
+git is a distributed version control system.
+git is free software.
版本回退
git log
查看git
仓库里面提交的历史记录。
commit 3eb6880960b72a578eb2ee6308d6b3e26bb92e0e
Author: 孙金帅 <s_mike@163.com>
Date: Wed Jun 7 10:17:24 2017 +0800
add distributed
commit e03098052675e44512f8f2869e2d56636eb2e16b
Author: 孙金帅 <s_mike@163.com>
Date: Wed Jun 7 10:01:33 2017 +0800
wrote a readme file
注意:git log
命令显示从最近到最远的提交日志。
如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline
参数:
3eb6880960b72a578eb2ee6308d6b3e26bb92e0e add distributed
e03098052675e44512f8f2869e2d56636eb2e16b wrote a readme file
注意:
看到的一大串类似3628164...882e1e0的是commit id
(版本号),和svn
不一样,git
的commit id
不是1,2,3……递增的数字,而是一个SHA1
计算出来的一个非常大的数字,用十六进制表示,而且你看到的commit id
和我的肯定不一样,以你自己的为准。为什么commit id
需要用这么一大串数字表示呢?因为git
是分布式的版本控制系统,后面我们还要研究多人在同一个版本库里工作,如果大家都用1,2,3……作为版本号,那肯定就冲突了。
版本回退,首先,git
必须知道当前版本是哪个版本,在git
中,用HEAD
表示当前版本,也就是最新的提交3628164...882e1e0(注意我的提交ID和你的肯定不一样),上一个版本就是HEAD~1
,上上一个版本就是HEAD~2
,往上100个版本写成HEAD~100
。
把当前版本add distributed
回退到上一个版本wrote a readme file
,就可以使用git reset
命令:
➜ learngit git:(master) git reset --hard head~1
HEAD is now at e030980 wrote a readme file
➜ learngit git:(master)
用git log
再看看现在版本库的状态:
commit e03098052675e44512f8f2869e2d56636eb2e16b
Author: 孙金帅 <s_mike@163.com>
Date: Wed Jun 7 10:01:33 2017 +0800
wrote a readme file
最新的那个版本add distributed
已经看不到了。好比你从21世纪坐时光穿梭机来到了19世纪,想再回去已经回不去了,肿么办?
办法其实还是有的,只要上面的命令行窗口还没有被关掉,你就可以顺着往上找啊找啊,找到那个add distributed
的commit id是3eb6880960b72a578eb2ee6308d6b3e26bb92e0e,于是就可以指定回到未来的某个版本:
➜ learngit git:(master) git reset --hard 3eb6880960b72a578eb2ee6308d6b3e26bb92e0e
HEAD is now at 3eb6880 add distributed
➜ learngit git:(master)
版本号没必要写全,前几位就可以了,git
会自动去找。当然也不能只写前一两位,因为git
可能会找到多个版本号,就无法确定是哪一个了。
查看readme.txt
的内容:
➜ learngit git:(master) cat readme.txt
git is a distributed version control system.
git is free software.
➜ learngit git:(master)
git
的版本回退速度非常快,因为git
在内部有个指向当前版本的HEAD
指针,当你回退版本的时候,git
仅仅是把HEAD
从指向add distributed
:
改为指向wrote a readme file
:
然后顺便把工作区的文件更新了。所以你让HEAD
指向哪个版本号,你就把当前版本定位在哪。
git reflog
假如,你想回退到新版本,但是又找不到新版本的commit id
,在git
中,可以使用git reflog
找到新版本的commit id
。然后在使用git reset 3eb6880960b72a578eb2ee6308d6b3e26bb92e0e
,就可以回退到新版本了。
git reflog
查看命令历史,用来记录你的每一次命令:
3eb6880 HEAD@{0}: reset: moving to 3eb6880960b72a578eb2ee6308d6b3e26bb92e0e
e030980 HEAD@{1}: reset: moving to head~1
3eb6880 HEAD@{2}: reset: moving to head
3eb6880 HEAD@{3}: commit: add distributed
e030980 HEAD@{4}: commit (initial): wrote a readme file
工作区和暂存区
工作区可以理解为,新建或者workingcopy下来的文件夹,可以在文件夹里面,新增删除文件等等。
暂存区可以理解为,当使用git init
命令初始化git
仓库里面有一个隐藏的.git
文件,里面就存放暂存区空间和分支master
空间,以及指向的一个指针叫HEAD
。
使用git add
把文件添加git
仓库,实际上就是把文件修改添加到暂存区;
使用git commit
提交文件,实际上就是把暂存区的所有内容提交到当前分支。
例如:
修改readme.txt
,然后在工作区新增一个LICENSE
文本文件。
然后,git status
查看状态;
On branch master
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
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 status
再查看一下:
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: LICENSE
modified: readme.txt
➜ learngit git:(master) ✗
现在,暂存区的状态就变成这样了:
image.png所以,git add
命令实际上就是把要提交的所有修改放到暂存区(Stage)。然后,执行git commit
就可以一次性把暂存区的所有修改提交到分支。
➜ learngit git:(master) ✗ git commit -m "understand how stage works"
[master 97bf1a5] understand how stage works
2 files changed, 3 insertions(+), 2 deletions(-)
create mode 100644 LICENSE
➜ learngit git:(master)
一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的:
➜ learngit git:(master) git status
On branch master
nothing to commit, working tree clean
➜ learngit git:(master)
现在版本库变成了这样,暂存区就没有任何内容了:
image.png撤销修改
场景1:当你改乱了工作区某个文件的内容。
例如,在readme.txt
改乱了一行代码,但是没有通过git add
命令把错误文件添加到git
仓库里面的暂存区。
➜ learngit git:(master) ✗ cat readme.txt
git is a distributed version control system.
git is free software.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN. // 错误代码
➜ learngit git:(master) ✗
既然错误发现得很及时,就可以很容易地纠正它。你可以删掉最后一行,手动把文件恢复到上一个版本的状态。如果用git status查看一下:
➜ learngit git:(master) ✗ git status
On branch master
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
no changes added to commit (use "git add" and/or "git commit -a")
➜ learngit git:(master) ✗
git
会告诉你,git checkout -- file
可以丢弃工作区的修改:
git checkout -- readme.txt
命令git checkout -- readme.txt
意思就是,把readme.txt
文件在工作区的修改全部撤销,这里有两种情况:
一种是readme.txt
自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是readme.txt
已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit
或git add
时的状态。
查看readme.txt
的文件内容:
➜ learngit git:(master) cat readme.txt
git is a distributed version control system.
git is free software.
➜ learngit git:(master)
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时.
例如,在readme.txt
改乱了一行代码,并且使用通过git add
命令把错误文件添加到git
仓库里面的暂存区。但是在commit
之前,你发现了这个问题。用git status
查看一下,修改只是添加到了暂存区,还没有提交:
➜ learngit git:(master) ✗ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: readme.txt
➜ learngit git:(master) ✗
git
同样告诉我们,用命令git reset HEAD file
可以把暂存区的修改撤销掉(unstage),重新放回工作区:
➜ learngit git:(master) ✗ git reset HEAD readme.txt
Unstaged changes after reset:
M readme.txt
➜ learngit git:(master) ✗
git reset
命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD
时,表示最新的版本。
再用git status
查看一下,现在暂存区是干净的,工作区有修改:
➜ learngit git:(master) ✗ git status
On branch master
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
no changes added to commit (use "git add" and/or "git commit -a")
➜ learngit git:(master) ✗
然后使用git checkout -- file
可以丢弃工作区的修改:
➜ learngit git:(master) ✗ git checkout -- readme.txt
➜ learngit git:(master) git status
On branch master
nothing to commit, working tree clean
➜ learngit git:(master)
删除文件
在git
中,删除也是一个修改操作,我们实战一下,先添加一个新文件test.txt
到git
并且提交:
➜ learngit git:(master) touch test.txt
➜ learngit git:(master) ✗ git add test.txt
➜ learngit git:(master) ✗ git commit -m "add test.txt"
[master 2c26a6d] add test.txt
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test.txt
➜ learngit git:(master)
一般情况下,你通常直接在文件管理器中把没用的文件删了,或者用rm命令删了:
➜ learngit git:(master) rm test.txt
➜ learngit git:(master) ✗ git status
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: test.txt
no changes added to commit (use "git add" and/or "git commit -a")
➜ learngit git:(master) ✗
现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm
删掉,并且git commit
:
➜ learngit git:(master) ✗ git rm test.txt
rm 'test.txt'
➜ learngit git:(master) ✗ git commit -m "remove test.txt"
[master 584464a] remove test.txt
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 test.txt
➜ learngit git:(master)
现在,文件就从版本库中被删除了。
另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本:
git checkout -- test.txt
git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
命令
git rm
用于删除一个文件。如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容。
创建与合并分支
在初始化git
仓库的时候,会有一个master
分支,HEAD
是指向master
分支的指针。
开始的时候,master
分支是一条线,git
用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点:
每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长:
当我们创建新的分支,例如dev
时,git
新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上:
在git
仓库中,创建一个分支很快,因为除了增加一个dev
指针,改变head
的指向,工作区的文件没有任何的变化。
首先,我们创建dev
分支,然后切换到dev
分支:
➜ learngit git:(master) ✗ git checkout -b dev
A test.txt
Switched to a new branch 'dev'
➜ learngit git:(dev) ✗
git checkout
命令加上-b
参数表示创建并切换,相当于以下两条命令:
➜ learngit git:(master) ✗ git branch dev
➜ learngit git:(master) ✗ git checkout dev
A test.txt
Switched to branch 'dev'
➜ learngit git:(dev) ✗
然后,用git branch
命令查看当前分支:
➜ learngit git:(dev) ✗ git branch
* dev
master
➜ learngit git:(dev) ✗
git branch
命令会列出所有分支,当前分支前面会标一个*
号。
➜ learngit git:(dev) ✗ git add readme.txt
➜ learngit git:(dev) ✗ git commit -m "branch test"
[dev 08a2a35] branch test
2 files changed, 1 insertion(+)
create mode 100644 test.txt
➜ learngit git:(dev)
现在,dev
分支的工作完成,我们就可以切换回master
分支:
➜ learngit git:(dev) git checkout master
Switched to branch 'master'
➜ learngit git:(master)
切换回master
分支后,再查看一个readme.txt
文件,刚才添加的内容不见了!因为那个提交是在dev
分支上,而master
分支此刻的提交点并没有变:
现在,我们把dev
分支的工作成果合并到master
分支上:
➜ learngit git:(master) git merge dev
Updating 584464a..08a2a35
Fast-forward
readme.txt | 1 +
test.txt | 0
2 files changed, 1 insertion(+)
create mode 100644 test.txt
➜ learngit git:(master)
git merge
命令用于合并指定分支到当前分支。合并后,再查看readme.txt
的内容,就可以看到,和dev
分支的最新提交是完全一样的。
➜ learngit git:(master) cat readme.txt
git is a distributed version control system.
git is free software.
Creating a new branch is quick.
➜ learngit git:(master)
合并完成后,就可以放心地删除dev
分支了:
➜ learngit git:(master) git branch -d dev
Deleted branch dev (was 08a2a35).
➜ learngit git:(master)
删除后,查看branch
,就只剩下master
分支了:
➜ learngit git:(master) git branch
* master
➜ learngit git:(master)
综上,在dev
的分支上,对工作区的修改和提交后,而master
指针不变:
如果在dev
上的工作完成了,就可以把dev
合并到master
上,就是直接把master指向dev的当前提交,就完成了合并:
合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支:
总结:
查看分支:git branch
创建分支:git branch <name>
切换分支:git checkout <name>
创建+切换分支:git checkout -b <name>
合并某分支到当前分支:git merge <name>
删除分支:git branch -d <name>
解决冲突
场景:把feature1
分支merge
到master
分支,造成代码冲突
准备新的feature1分支,继续我们的新分支开发:
$ git checkout -b feature1
Switched to a new branch 'feature1'
修改readme.txt最后一行,改为:
Creating a new branch is quick AND simple.
在feature1
分支上提交:
$ git add readme.txt
$ git commit -m "AND simple"
[feature1 75a857c] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
然后切换到master
分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
git
还会自动提示我们当前master
分支比远程的master
分支要超前1个提交。
在master
分支上把readme.txt
文件的最后一行改为:
Creating a new branch is quick & simple.
提交:
$ git add readme.txt
$ git commit -m "& simple"
[master 400b400] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
现在,master
分支和feature1
分支各自都分别有新的提交,变成了这样:
这种情况下,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
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
我们可以直接查看readme.txt的内容:
➜ learngit git:(master) ✗ cat readme.txt
git is a distributed version control system.
git is free software.
Creating a new branch is quick.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
git
用<<<<<<<,=======,>>>>>>>
标记出不同分支的内容,我们修改如下后保存:
Creating a new branch is quick and simple.
再提交:
$ git add readme.txt
$ git commit -m "conflict fixed"
[master 59bc1cb] conflict fixed
现在,master分支和feature1分支变成了下图所示:
image.png用带参数的git log也可以看到分支的合并情况:
* f110aa7 conflict fixed
|\
| * 62f8819 AND simple
* | 930642f & simple
|/
* 08a2a35 branch test
* 584464a remove test.txt
* 2c26a6d add test.txt
* 9d7eb44 commit
* 3eb6880 add distributed
* e030980 wrote a readme file
分支管理策略
通常,合并分支时,如果可能,git
会用Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward
模式,git
就会在merge
时生成一个新的commit
,这样,从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff
方式的git merge
:
首先,仍然创建并切换dev
分支:
$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件,并提交一个新的commit:
$ git add readme.txt
$ git commit -m "add merge"
[dev 6224937] add merge
1 file changed, 1 insertion(+)
现在,我们切换回master:
$ git checkout 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 | 1 +
1 file changed, 1 insertion(+)
因为本次合并要创建一个新的commit
,所以加上-m
参数,把commit
描述写进去。
合并后,我们用git log --graph --pretty=oneline --abbrev-commit
看看分支历史:
* 25e02ae merge with no-ff
|\
| * 661745d add merge
|/
* f110aa7 conflict fixed
|\
| * 62f8819 AND simple
* | 930642f & simple
|/
* 08a2a35 branch test
* 584464a remove test.txt
* 2c26a6d add test.txt
* 9d7eb44 commit
* 3eb6880 add distributed
* e030980 wrote a readme file
可以看到,不使用Fast forward
模式,merge
后就像这样:
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
image.png标签管理
在Git中打标签非常简单,首先,切换到需要打标签的分支上:
$ git branch
* dev
master
$ git checkout 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
6a5819e merged bug fix 101
cc17032 fix bug 101
7825a50 merge with no-ff
6224937 add merge
59bc1cb conflict fixed
400b400 & simple
75a857c AND simple
fec145a branch test
d17efd8 remove test.txt
...
比方说要对add merge
这次提交打标签,它对应的commit id
是6224937
,敲入命令:
$ git tag v0.9 6224937
再用命令git tag
查看标签:
$ git tag
v0.9
v1.0
注意,标签不是按时间顺序列出,而是按字母排序的。可以用git show <tagname>
查看标签信息:
$ git show v0.9
commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4
Author: Michael Liao <askxuefeng@gmail.com>
Date: Thu Aug 22 11:22:08 2013 +0800
add merge
...
可以看到,v0.9确实打在add merge
这次提交上。
还可以创建带有说明的标签,用-a
指定标签名,-m
指定说明文字:
$ git tag -a v0.1 -m "version 0.1 released" 3628164
用命令git show <tagname>
可以看到说明文字:
$ git show v0.1
tag v0.1
Tagger: Michael Liao <askxuefeng@gmail.com>
Date: Mon Aug 26 07:28:11 2013 +0800
version 0.1 released
commit 3628164fb26d48395383f8f31179f24e0882e1e0
Author: Michael Liao <askxuefeng@gmail.com>
Date: Tue Aug 20 15:11:49 2013 +0800
append GPL
如果标签打错了,也可以删除:
$ git tag -d v0.1
Deleted tag 'v0.1' (was e078af9)
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
如果要推送某个标签到远程,使用命令git push origin <tagname>
:
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0
或者,一次性推送全部尚未推送到远程的本地标签:
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 554 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new tag] v0.2 -> v0.2
* [new tag] v0.9 -> v0.9
如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除:
$ git tag -d v0.9
Deleted tag 'v0.9' (was 6224937)
然后,从远程删除。删除命令也是push,但是格式如下:
$ git push origin :refs/tags/v0.9
To git@github.com:michaelliao/learngit.git
- [deleted] v0.9
总结:
命令git push origin <tagname>可以推送一个本地标签;
命令git push origin --tags可以推送全部未推送过的本地标签;
命令git tag -d <tagname>可以删除一个本地标签;
命令git push origin :refs/tags/<tagname>可以删除一个远程标签。
网友评论