git tag创建、远程推送、回退以及强推push -f

一、给本地仓库分支打轻量级tag标签

1、在Git中打标签非常简单，首先，切换到需要打标签的分支上:

$ git branch
  devwhd
  gray
* master
  optimize_sel_driver_20170911
  pre_production

2、然后，敲命令git tag <name>就可以打一个新标签:

$ git tag v1.0

3、可以用命令git tag查看所有标签:

$ git tag
tag_20170908
tag_20170914
v1.o

4、默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？

方法是找到历史提交的commit id，然后打上就可以了

$ git log --pretty=oneline --abbrev-commit
aaff087 (HEAD -> devwhd, tag: v1.o, origin/devwhd) url add
c603e59 aaa
ae636a8 aaaa
471fd27 url update
d5a65e9 push url
b38926c url
cb96205 update sed msg
40c45b5 cong
61328f7 time git
9bc2e9b paida
6dac88d 派单规则修改

5、比方说要对url update这次提交打标签，它对应的commit id是471fd27，敲入命令:

$ git  tag v0.9 471fd27

6、再用命令git tag查看标签：

$ git tag
tag_20170908
tag_20170914
v0.9
v1.o

注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：

$ git show v0.9
commit 471fd274b47d36818204dbd23e6e646a1269b8ef (tag: v0.9)
Author: whd <whd@01zc.com>
Date:   Tue Sep 12 20:55:46 2017 +0800

    url update

可以看到，v0.9确实打在ulr update这次提交上。

二、上面我们打的tag是轻量级的也就是一般的tag没有注释，下面看看有注释的标签

1、创建带有说明的标签，用-a指定标签名，-m指定说明文字：

$ git tag -a v0.1 -m "version 0.1 released push url" d5a65e9

2、用命令git show <tagname>可以看到说明文字：

$ git show v0.1
tag v0.1
Tagger: whd <whd@01zc.com>
Date:   Thu Sep 14 14:22:25 2017 +0800

version 0.1 released push url

commit d5a65e9a08be3820d0b0a59b3df9750168557cd5 (tag: v0.1)
Author: whd <wanghaidong@01zhuanche.com>
Date:   Tue Sep 12 20:48:28 2017 +0800

    push url

这样我们就能看到我们添加的tag以及相关注释，比如这里我们添加的注释是version 0.1 released push url

ok 到这里我们就给相关分支的某些提交版本添加了tag，但是git tag命令是对本地仓库分支加的标签，为了能把标签同步到远程服务器，我们需要做如下操作

三、把本地仓库分支tag推送到远程服务器

默认情况下，git push并不会把tag标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库。

1.push单个tag，命令格式为：

git push origin [tagname]

$ git push origin tag_20170908

将本地 tag_20170908的tag推送到远端服务器

2.push所有tag，命令格式为：

git push [origin] --tags

git push --tags

或

git push origin --tags

当远程有多个服务的时候远程服务名称是必须的，而如果远程只有一个远程服务则远程服务名称可以省略。

ok 到这里添加 tag标签push tag标签结束……

以上命令经检验通过，如果不起作用，请在Git控制台上确认你的账号是否有权限推送Tag。这一点很重要，因为这个原因，我有过一段时间很抓狂。

四、通过标签恢复代码
1、查看标签的详情，找出打标签的那次提交的commit id

查看本地所有标签

$ git tag
tag_20170908
tag_20170914
v0.1
v0.9
v1.o

查看某个标签的详细信息

$ git show v0.1
tag v0.1
Tagger: whd <wanghaidong@01zhuanche.com>
Date:   Thu Sep 14 14:22:25 2017 +0800

version 0.1 released push url

commit d5a65e9a08be3820d0b0a59b3df9750168557cd5 (tag: v0.1)
Author: whd <wanghaidong@01zhuanche.com>
Date:   Tue Sep 12 20:48:28 2017 +0800

    push url

commit id是不是很长啊 不用担心，我们只需要记住前面几位就可以了，这里我们只取前6位：d5a65e。Git会根据前面几位自动识别的，当然，你的commit id跟我的是不一样的。

2、版本回退（将主干分支回退到某个版本）

下面我们就通过commit id回到发版本时候的代码去

git reset --hard d5a65e

注意把d5a65e换成你的commid id。回退完毕,其实就是把head指针指向了制定版本位置

当然写commit  id是可以回滚到任何版本，单在真实环境下我们用的比较多的应该是返回到上个版本即最后一次提价的版本这个我们可以使用如下命令

git  reset  --hard HEAD

回滚后如果你立马投入与bug的修改，修改后发版本，那么你就犯了严重的错误，因为你修改后的代码是无法与正在开发的版本合并哒，也就是说你的修改并不能加入现有的代码。

特别注意：通过标签回退版本后，要马上拉一个分支，然后当前主干分支要立即回到原来的位置，否则正在开发的代码可能白干了，接着在刚拉的分支上修改bug，修改完毕合并到主干上

3、从当前分支拉分支

主干分支回退版本后，从回退后的主干分支立即拉取分支，这里取名bugfix分支，假如这里我们是从master主干分支回退后再拉新分支的，流程如下：

(1) 切换到master分支

git chekcout master

(2) 更新为最新

git  pull

(3) 拉取修改bug新分支

git checkout -b bugfix

(4) 拉取新分支后查看分支

git  branch

ok到这里回滚的准备我们做好了

4、从当前tag拉分支

当我们一次迭代上线前会对master分支打一个tag,这个tag作为回滚备份，然后将新需求分支合并到master在用master代码上线，如果最新master出现问题则我们可以从最新tag拉取分支。

(1) 切换到具体tag

git checkout tag_name 

(2) 从tag拉取新分支

git branch <new-branch-name> <tag-name>

（3）从tag拉取新分支

git checkout -b branch_name tag_name

切换到具体tag后使用2、3两种方式都能从当前tag拉取新分支，然后基于该分支进行bugfix,修复后可以再次合并到master;

5、主干分支立即回到原来的位置

(1) 首先回到主干分支

git chekcout master

(2) 查看回去的commit id

回退版本需要commit id，向前进同样也是的。还记得我在第三次提交完毕后，用git log命令查看提交记录吗，现在我们需要第三次提交的commit id，再用git log命令：

git  log

查看当前分支提交的log日志
可以看到只有第一次的提交记录了，因为这个时候版本回退了git log是查不到第三次提交记录的，怎么办呢，怎么才能回去呢？ 
我们用下面这个命令：

git reflog

git reflog 相比git log能查询更多的日志信息，两个的具体区别之后再详细学习，反正使用git reflog 能查询到所有的日志commit id即使是删除的。

(3) 回到回退前版本

git reset --hard aaff087

ok  这样master主干分支回到了回退前的版本状态即回到最新的版本啦

(4) 切换到bugfix分支，修改bug

git checkout bugfix

(5) bugfix 分支上修改bug并添加提交

当我们在bugfix分支上修改了bug后要把修改后的代码add、commit

git  add fileName
git commit  -m "bugfix"

(6) 将bugfix分支合并到主干分支上

在bugfix分支上修复了紧急bug之后，就可以发一个新的版本，之后就要把修复后的代码合并到我们的主干上，不然下次发版本这个bug还是存在的。合并用下面的命令:

git checkout master //先切换到主干上
git merge bugfix    //再合并修改bug的分支

(7) 冲突解决

在合并后你会发现，有冲突，这是必然的，因为我们在两个分支上修改了同一个文件，我们可以使用git status来查看那些文件冲突了。

git  status

ok 这样我们就能看到具体冲突的文件了，我们开始修改冲突文件：

其中<<<<<<Head到======这个是当前分支，也就是master分支的内容，从======到>>>>>>>bugfix，是bugfix分支的内容 
修改冲突很简单啦，把多余的内容去掉就可以了，ok这样我们的冲突解决了，提交修改后的代码到master。

ok 到此我们的代码回滚就搞定了！！！

五、git log和git reflog 的区别

git reflog 可以查看所有分支的所有操作记录（包括commit和reset的操作），包括已经被删除的commit记录，git log则不能察看已经删除了的commit记录

具体一个例子，假设有三个commit:

(1) git  commit -m"add test1.c"

(2) git  commit -m"add test2.c"

(3)git  commit -m"add test3.c"

这样提交了三个，也就是有三个commit id，commit3是最后提交的。

如果执行git reset --hard HEAD~1则 删除了commit3，如果发现删除错误了，需要恢复commit3，这个时候就要使用git reflog 因为回退原因使用git log是看不到commit3的commit id的

六、强推 push -f

情况理解：当我们的master分支想回退到某个之前的版本时需要做如下流程：

1、git checkout  master :本地切换到master分支

2、git pull : 本地分支跟新为最新（非必须，只是习惯）

3、git log 、git  reflog :查看提交记录，寻找合适的commitId (注意这里的commitid一定要注意，因为我们开发分支的版本号在合并的时候也会被合并过来)

4、git  reset --hard commitid :回滚到指定的版本、git reset --hard HEAD：会滚到之前一个版本

这里为什么会写两个那，因为HEAD 之前版本就是master的版本也就是各个开发分支merge时的版本所以不会存在commitid是分支版本的问题。

5、git  push : 将本地代码推到远程，但是这时会报错误，不会让你推因为你的本地版本比远程低一个版本，所以他会要求你更新为最新的在push但是这样的话就会有问题啊，把我们回滚的又覆盖了，所以我们不能更新，所以不能使用这个命令，只能使用下面的6这个命令了！！！

6、git push -f  origin master(修改这里的master为你的分支名称，不要把你的分支强推到master分支) ：将本地代码强制推到远程，也就是用本地代码覆盖远程。

OK这样回退就完成了！