git命令之分支管理和Tag标签

📝 个人简介

⭐ 个人主页：我是段段🙋‍
🍊 博客领域：编程基础、前端💻
🍅 写作风格：干货！干货！都是干货！
🍑 精选专栏：Git命令
🛸 支持段段：点赞👍、收藏⭐、留言💬

分支管理

1 、创建分支

$ git checkout -b dev
# Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于一下两条命令：

$ git branch dev
$ git checkout dev
# Switched to branch 'dev'			

注意到切换分支使用git checkout 切换的分支名称，而Git中撤销修改是git checkout -- 撤销的文件名称

为了避免困惑，最新版本的Git提供了新的命令来切换分支：git switch

创建并切换到新的dev分支，可以使用

$ git switch -c dev

切换到已经存在的分支master，可以使用

$ git switch master

2、查看分支

$ git branch

不带参数，列出本地已经存在的分支，并且在当前分支的前面会标记一个*

$ git branch -r(remote)

查看远程版本库分支列表

$ git branch -a(all)

查看所有的分支列表，包括本地和远程

$ git branch -vv

查看本地分支对应的远程分支

3、删除分支

$ git branch -d dev # dev为需要删除的分支名称

删除dev分支，如果在分支中还有一些没有merge的提交，则会删除分支失败，此时可以使用git branch -D dev命令来强制删除dev分支

4、分支重命名

$ git branch -m oldName newName

5、分支合并

$ git merge dev # 将dev分支的内容合并到当前分支

git merge命令用于合并指定分支到当前分支

分支合并时，如果出现Fast-forward信息，就是指这次合并是快进模式，当然，我们可以选择禁用，如果强制禁用Fast forward模式，Git就会在merge是生成一个新的commit，需要使用--no--ff参数进行禁用

$ git merge --no--ff -m 'merge with no-ff' dev

因为合并时会创建一个新的commit，所以需要加上-m参数，把commit描述写进去

6、bug分支

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

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该 bug，怎么办？

Git提供了一个stash功能， 可以把当前的工作现场“储藏”起来，等以后恢复现场后继续工作

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

用git status查看工作区，就是干净的，可以放心的去创建分支修改bug

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

$ git checkout master
$ git checkout -b issue-101

修复完成后，需要合并到master分支

$ git switch master
$ git merge --no-ff -m "bug fix 101" issue-101

bug修复后，回到刚才工作的分支，用git status命令查看工作区是干净的，然后使用git stash list命令查看刚才的工作现场

$ git stash list
# stash@{0}: WIP on dev: f52c633 add merge

工作现场还在，是因为Git把stash的内容存在某个地方了，用两种方法可以恢复

• 使用git stash apply恢复，但是恢复后，stash内容并不删除，需要使用git stash drop来删除
• 使用git stash pop命令，恢复的同时把stash内容也删除了

然后使用git stash list命令查看，就看不到任何stash内容了

可以进行多次stach，恢复的时候，先用git stash list查看，然后恢复指定的stash
$ git stash apply stash@{0}

在master分支上修复了bug后，但dev分支是早期从master分支上分出来的，所以bug在dev分支上也存在

那么怎么在dev分支上修复同样的bug呢？

为了方便操作，Git专门提供了一个cherry-pick命令，让我们复制一个特定的提交到当前分支

$ git branch # 先查看当前是否在dev分支
# * dev
#   master
$ git cherry-pick xxxx # xxxx表示刚才提交bug时的commit id

git标签（tag）

1、打标签

首先切换到需要打标签的分支上

$ git tag v1.0

运行上面代码就打了一个新的标签**（默认标签是打在最新提交的commit上）**

可以通过git tag命令查看所有的标签

有时候，如果忘了打标签，怎么办？方法是：找到历史提交的commit id，然后打上就可以了

$ git tag v0.9 xxxxxxx # xxxxxxx表示刚才提交的commit id

2、查看标签信息

$ git show tagname # tagname表示标签的名字 例如：v0.9、v1.0

3、创建带有说明的标签，其中-a指定标签名，-m指定说明的文字

$ git tag -a 标签名 -m '说明文字'

给历史提交打带有说明的标签

$ git tag -a 标签名 -m '说明文字' xxxxxxx # xxxxxxx表示需要打标签的commit id

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

4、删除tag

$ git tag -d v0.9

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

5、推送标签至远程

$ git push origin v1.0 # 推送单个标签至远程
$ git push origin --tags # 一次性推送全部尚未推送到远程的本地标签

6、删除远程的标签

需要先从本次删除，删除本地的标签

$ git tag -d v1.0

然后从远程删除，删除命令也是push，格式如下

$ git push origin :refs/tags/v1.0

其实，在上面介绍到的标签都只是 git 标签中的一种，叫轻量级的标签（lightweight），轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用

另外一种 git 标签叫含附注的标签（annotated），附注标签实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字、电子邮件地址和日期、以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证

7、创建含附注类型的标签，用-a(annotated)指定标签名即可

$ git tag -a v1.1 -m 'my version 1.1'

-m 选项则指定了对应的标签说明，Git 会将此说明一同保存在标签对象中

8、用私钥前属标签

如果你有自己的私钥，还可以用 GPG 来签署标签，只需要把之前的选项 -a 改为 -s ( signed）即可

$ git tag -s v1.2 -m 'my signed 1.2 tag' # 创建一个带GPG签名的标签

有什么需要补充的地方欢迎留言~~~