Git_Github_LinuxiOS实用教程iOS精英班

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

2017-06-07  本文已影响642人  s_在路上

安装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不一样,gitcommit 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.txtLICENSE都添加后,用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 commitgit 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.txtgit并且提交:

➜  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分支是一条线,gitmaster指向最新的提交,再用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分支mergemaster分支,造成代码冲突

准备新的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 id6224937,敲入命令:

$ 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教程-廖雪峰的官方网站

上一篇下一篇

猜你喜欢

热点阅读