【git教程】

2023-12-13 04:06:06

廖雪峰git教程

git与SVN的区别:集中式与分布式的区别

一、SVN是集中式的版本控制系统,版本库是集中存放在中央服务器的。干活的时候,用的都是自己的电脑,所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。

缺点:必须联网才能工作

二、Git是分布式版本控制系统,没有“中央服务器”,每个人的电脑上都是一个完整的版本库。假如你在自己电脑上改了文件A,你的同事也在他的电脑上改了文件A,这时你们俩之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。

在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。

三、注意

  1. 所有的版本控制系统,其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等。对于图片、视频这些二进制文件无法追踪到具体改了啥,只能看到大小的改变。
  2. Microsoft的Word格式是二进制格式,因此,版本控制系统也没法跟踪Word文件的改动的
  3. 千万不要使用Windows自带的记事本编辑任何文本文件。因为Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件,他们会在每个文件开头添加了0xefbbbf(十六进制)的字符,你会遇到很多不可思议的问题,比如,网页第一行可能会显示一个“?”,明明正确的程序一编译就报语法错误等等

Windows上安装Git

从Git官网直接下载安装程序,然后按默认选项安装即可。安装完成后,在开始菜单里找到“Git”->“Git Bash”,在命令行输入:

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
# --global参数表示你这台机器上所有的Git仓库都会使用这个配置

因为Git是分布式版本控制系统,所以,每个机器都必须自报家门:你的名字和Email地址。

创建版本库/仓库(repository)

repository可以简单理解成一个目录,这个目录里面的所有文件都可以被Git管理起来。

# 1. 创建空文件夹并进入。
$ mkdir learngit
$ cd learngit
$ pwd  # 显示当前目录
/Users/michael/learngit
# 2. 通过git init命令把这个目录变成Git可以管理的仓库
$ git init 
Initialized empty Git repository in /Users/michael/learngit/.git/

也可以让git来管理已有的文件夹,此时不用创建空文件夹,直接cd到要管理的文件夹,然后执行执行git init即可

如此就创建好了repository,你会发现当前目录learngit下多了一个.git的文件夹,这个文件夹是Git来跟踪管理版本库的。

将文件添加到repository

在当前目录learngit下创建一个readme.txt,内容如下:

Git is a version control system.
Git is free software.

接下来我们将readme.txt添加到repository:

  • 用命令git add告诉Git,把文件添加到仓库:$ git add readme.txt,执行命令后没有任何显示即为成功。
  • 用命令git commit告诉Git,把文件提交到仓库:
$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt
# -m后面输入的是本次提交的说明

commit可以一次提交很多文件,所以你可以多次add不同的文件做一次提交

报错处理

  • Q:输入git add readme.txt,得到错误:fatal: not a git repository (or any of the parent directories)。
    A:Git命令必须在Git仓库目录内执行(git init除外),在仓库目录外执行是没有意义的。
  • Q:输入git add readme.txt,得到错误fatal: pathspec 'readme.txt' did not match any files。
    A:添加某个文件时,该文件必须在当前目录下存在,用ls或者dir命令查看当前目录的文件,看看文件是否存在,或者是否写错了文件名。

查看仓库的状态

将readme.txt文件改成如下内容:

Git is a distributed version control system.
Git is free software.

运行git status命令查看仓库当前的状态:

$ git status
On branch master
Changes not staged for commit:# 文件被修改了但还未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")

git diff查看修改的内容

$ git diff readme.txt 
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@ # 改变的两行进行比对:
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software.

将修改后的文件提交到repository和提交新文件是一样的

  1. 把文件添加到repository
$ git add readme.txt

在执行第二步git commit之前,我们先运行git status看看当前仓库的状态:

$ git status
On branch master
Changes to be committed: # 将要被提交的修改包括readme.txt
  (use "git reset HEAD <file>..." to unstage)

	modified:   readme.txt
  1. 提交:
$ git commit -m "add distributed"
[master e475afc] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

提交后,我们再用git status命令看看仓库的当前状态:

$ git status
On branch master 
nothing to commit, working tree clean
# 没有需要提交的修改,而且,工作目录是干净

版本回退

修改readme.txt文件如下:

Git is a distributed version control system.
Git is free software distributed under the GPL.

然后添加到仓库:

$ git add readme.txt
$ git commit -m "append GPL"
[master 1094adb] append GPL
 1 file changed, 1 insertion(+), 1 deletion(-)

当你觉得文件修改到一定程度的时候,就可以commit一下。一旦你把文件改乱了,或者误删了文件,可以从commit中恢复。使用git log命令查看readme.txt有哪些版本被提交到Git仓库里了(会按照从最近到最远的提交日志显示):

$ 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
# 前面的那一串是commit id

现在打算把readme.txt回退到上一个版本,也就是add distributed的那个版本,使用git reset命令回退:

$ git reset --hard HEAD^
HEAD is now at e475afc add distributed

在Git中,用HEAD表示当前版本,也就是最新的提交1094adb…,上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100

看看readme.txt的内容是不是版本add distributed的内容:

$ cat readme.txt
Git is a distributed version control system.
Git is free software.

果然被还原了,使用git log再看看现在版本库的状态

$ git log
commit e475afc93c209a690c39c13a46716e8fa000c366 (HEAD -> master)
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

最新的那个版本append GPL已经看不到了!好比你从21世纪坐时光穿梭机来到了19世纪,想再回去已经回不去了,怎么办?办法其实还是有的,只要上面的命令行窗口还没有被关掉,你就可以找到那个append GPL的commit id是1094adb…,于是就可以指定回到未来的某个版本:

$ git reset --hard 1094a
HEAD is now at 83b0afe append GPL

版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。

再看看readme.txt的内容:

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.

果然又恢复了。

Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD指针,当你回退版本的时候,Git仅仅是把HEAD从指向append GPL:
在这里插入图片描述
改为指向add distributed:
在这里插入图片描述
然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号,你就把当前版本定位在哪。

现在,你回退到了某个版本,关掉了电脑,第二天早上就后悔了,想恢复到新版本怎么办?找不到新版本的commit id怎么办?Git提供了一个命令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,现在,你又可以乘坐时光机回到未来了。

工作区和暂存区

工作区(Working Directory):就是你在电脑里能看到的目录,比如learngit文件夹就是一个工作区。
版本库(Repository):Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。
在这里插入图片描述
前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:

第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;

第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。

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

你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。

管理和修改

如果不用git add到暂存区,那就不会加入到commit中,也就无法提交到仓库。假如你第一次修改了文件 -> git add -> 第二次修改文件 -> git commit,此时只会commit第一次修改的内容,因为Git管理的是修改,当你用git add命令后,在工作区的第一次修改被放入暂存区,准备提交,但是,在工作区的第二次修改并没有放入暂存区,所以,git commit只负责把暂存区的修改提交了,也就是第一次的修改被提交了,第二次的修改不会被提交。
为了解决这个问题,第二次修改后你可以先git addgit commit

撤销修改

一、假如你修改了文档,可以使用git checkout -- file可以丢弃工作区的修改:

  1. readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
  2. readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。

总之,git checkout -- file就是让这个文件回到最近一次git commitgit add时的状态。

注意:一定要有--,不然就变成切换到另一个分支的指令了

二、假如你修改了文档并添加到了暂存区,但还没有提交,可以使用命令git reset HEAD <file>把暂存区的修改撤销掉(unstage),重新放回工作区:

$ git reset HEAD readme.txt # HEAD表示最新的版本
Unstaged changes after reset:
M	readme.txt

git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区,接下来可以使用一中的指令将工作取得修改丢弃,如此,你就丢弃了暂存区的修改。

删除文件

远程仓库

Git是分布式版本控制系统,同一个Git仓库,可以分布到不同的机器上。怎么分布呢?最早,肯定只有一台机器有一个原始版本库,此后,别的机器可以“克隆”这个原始版本库,而且每台机器的版本库其实都是一样的,并没有主次之分。所以首先需要找一台电脑充当服务器的角色,每天24小时开机,其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上,并且各自把各自的提交推送到服务器仓库里,也从服务器仓库中拉取别人的提交。GitHub就充当这个“服务器”的角色,提供Git仓库托管服务。
前往GitHub注册账号后还需要做一些设置:

  • 创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:ssh-keygen -t rsa -C "youremail@example.com",把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。如果一切顺利的话,就可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。
  • 登陆GitHub,打开“Account settings”,“SSH Keys”页面,然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容。点“Add Key”,你就应该看到已经添加的Key:

为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。

添加远程仓库

现在,你已经在本地创建了Git仓库,假如你又想在GitHub创建一个Git仓库,并且让这两个仓库进行远程同步,这样,GitHub上的仓库既可以作为备份,又可以让其他人通过该仓库来协作。

  • 登陆GitHub,然后,在右上角找到Create a new repo按钮,创建一个新的仓库:
  • Repository name填入仓库名,本文为learngit,其他保持默认设置,点击Create repository按钮,就成功地创建了一个新的Git仓库:
  • 本地的learngit仓库下运行命令:git remote add origin git@github.com:GitHub账户名/仓库名.git,添加后,远程库的名字就是origin,这是Git默认的叫法
  • 使用git push把本地库的所有内容推送到远程库上,实际上是把当前分支master推送到远程:
$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
 - [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。

  • 推送成功后,可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样。从现在起,只要本地作了提交,就可以通过命令:git push origin master,把本地master分支的最新修改推送至GitHub

警告

当你第一次使用Git的clone或者push命令连接GitHub时,会得到一个警告:

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

这是因为Git使用SSH连接,而SSH连接在第一次验证GitHub服务器的Key时,需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器,输入yes回车即可。Git会输出一个警告,告诉你已经把GitHub的Key添加到本机的一个信任列表里了:Warning: Permanently added 'github.com' (RSA) to the list of known hosts.。这个警告只会出现一次,后面的操作就不会有任何警告了。

解除本地和远程的绑定关系

如果添加的时候地址写错了,或者就是想删除远程库,可以用git remote rm <name>命令。使用前,建议先用git remote -v查看远程库信息:

$ git remote -v
origin  git@github.com:michaelliao/learn-git.git (fetch)
origin  git@github.com:michaelliao/learn-git.git (push)

然后,根据名字删除,比如删除origin:git remote rm origin
此处的“删除”其实是解除了本地和远程的绑定关系,并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库,需要登录到GitHub,在后台页面找到删除按钮再删除。

从远程库克隆

一、登陆GitHub,创建一个新的仓库,然后点击【code】或者【clone】,复制地址
在这里插入图片描述
二、用命令git clone克隆一个本地库:

$ git clone git@github.com:yan7Cara/xx.git #复制的地址粘贴到这里
Cloning into 'gitskills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.

GitHub给出的地址不止一个,还可以用https协议的地址。使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令

分支

你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样既安全,又不影响别人工作。

创建与合并分支

每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。这个分支叫主分支,即master分支。HEAD严格来说指向的就是当前分支。一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:
在这里插入图片描述
每次提交,master分支都会向前移动一步,这样随着你不断提交,master分支的线也越来越长。当我们创建新的分支,例如dev时,Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上:
在这里插入图片描述
不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变:
在这里插入图片描述
假如我们在dev上的工作完成了,就可以把dev合并到master上。Git直接把master指向dev的当前提交,就完成了合并:
在这里插入图片描述
下面开始实战:

  1. 我们创建dev分支,然后切换到dev分支:
$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:

$ git branch dev # 创建dev分支
$ git checkout dev # 切换分支
Switched to branch 'dev'

我们注意到切换分支使用git checkout <branch>,而前面讲过的撤销修改则是git checkout -- <file>,同一个命令,有两种作用,确实有点令人迷惑。因此,最新版本的Git提供了新的git switch命令来切换分支,创建并切换到新的dev分支,可以使用:git switch -c dev,直接切换到已有的master分支,可以使用:git switch master

  1. git branch命令查看当前分支:
$ git branch
* dev
  master

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

  1. 我们可以在dev分支上正常提交,比如对readme.txt做个修改,加上一行:Creating a new branch is quick.,然后提交:
$ git add readme.txt 
$ git commit -m "branch test"
[dev b17d20e] branch test
 1 file changed, 1 insertion(+)
  1. dev分支的工作完成,我们就可以切换回master分支:
$ git checkout master
Switched to branch 'master'

切换回master分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:
在这里插入图片描述

  1. 我们可以使用git merge把dev分支的工作成果合并到master分支上:
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

Fast-forward表示这次合并是“快进模式”,也就是直接把master指向dev的当前提交

  1. 合并完成后,就可以放心地删除dev分支了:
$ git branch -d dev
Deleted branch dev (was b17d20e).

如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>强行删除。

解决冲突

准备新的feature1分支,继续我们的新分支开发:

$ git switch -c 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 14096d0] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支:

$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

在master分支上把readme.txt文件的最后一行改为:Creating a new branch is quick & simple.,提交:

$ git add readme.txt 
$ git commit -m "& simple"
[master 5dc6824] & 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.
  (use "git push" to publish your local commits)

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的内容:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< 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 cf810e4] conflict fixed

现在,master分支和feature1分支变成了下图所示:
用带参数的git log也可以看到分支的合并情况:

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/  
* b17d20e branch test
* d46f35e (origin/master) 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

分支管理策略

bug分支

假设你现在在dev分支上进行开发,因为你还没开发完,所以代码还没法提交,但是现在需要你新开一个bug分支修复bug,那你需要把当前工作现场“储藏”起来,等以后恢复现场后继续工作:

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge

标签

发布一个版本时,我们通常先在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照,其实它就是指向某个commit的指针。因为commit id是一串数字,且不方便记忆,所以有了tag

创建标签

一、切换到需要打标签的分支上:

$ 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,然后给其打上tag:

$ 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,再用命令git tag查看标签:

$ git tag
v0.9
v1.0

标签不是按时间顺序列出,而是按字母排序的。

可以用git show <tagname>查看标签信息:

$ git show v0.9
commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9) # 可以看到,v0.9确实打在add merge这次提交上。
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
...

还可以创建带有说明的标签,用-a指定标签名,-m指定说明文字:git tag -a v0.1 -m "version 0.1 released" 1094adb,使用命令git show <tagname>可以看到说明文字:

$ git show v0.1
tag v0.1
Tagger: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 22:48:43 2018 +0800

version 0.1 released

commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (tag: v0.1)
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 21:06:15 2018 +0800

    append GPL

diff --git a/readme.txt b/readme.txt
...

注意:标签总是和某个commit挂钩。如果这个commit既出现在master分支,又出现在dev分支,那么在这两个分支上都可以看到这个标签。

操作标签

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

$ git tag -d v0.1
Deleted tag 'v0.1' (was f15b0dd)

因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。如果要推送某个标签到远程,可以使用命令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

如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除:

$ git tag -d v0.9
Deleted tag 'v0.9' (was f52c633)

然后,使用命令git push origin :refs/tags/<tagname>从远程删除:

$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git
 - [deleted]         v0.9

忽略特殊文件

文章来源:https://blog.csdn.net/CaraYQ/article/details/134846496
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。