学习笔记之git命令行的详细使用

安装git

如果你正在使用Mac做开发，有两种安装git的方法。

安装完成后，还需要最后一步设置，在命令行输入：

$ 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：

image.png

改为指向wrote a readme file：

image.png

然后顺便把工作区的文件更新了。所以你让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。

image.png

使用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，就能确定当前分支，以及当前分支的提交点：

image.png

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

image.png

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

image.png

在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指针不变：

image.png

如果在dev上的工作完成了，就可以把dev合并到master上，就是直接把master指向dev的当前提交，就完成了合并：

image.png

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

image.png

总结：

查看分支：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分支各自都分别有新的提交，变成了这样：

image.png

这种情况下，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后就像这样：

image.png

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，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>可以删除一个远程标签。

参考资料

git教程-廖雪峰的官方网站

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 158,560评论 4赞 361
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,104评论 1赞 291
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 108,297评论 0赞 243
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 43,869评论 0赞 204
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,275评论 3赞 287
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,563评论 1赞 216
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,833评论 2赞 312
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,543评论 0赞 197
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,245评论 1赞 241
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,512评论 2赞 244
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,011评论 1赞 258
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,359评论 2赞 253
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,006评论 3赞 235
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,062评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,825评论 0赞 194
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,590评论 2赞 273
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,501评论 2赞 268

推荐阅读更多精彩内容