前些天發現了一個巨牛的人工智能學習網站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉到教程。

1 前言
本系列之所以取名”Git高級教程”，主要是教大家解決實際工作中遇到的問題，要求讀者會基本的Git用法和命令，請不要使用SourceTree這樣的工具，因為它讓你啥都不會、啥也不懂，git本身與Linux一脈相承，都是Linus torvalds寫的嘛，所以命令行才是精髓。如果你還不會Git的話，強烈建議你學習廖雪峰的教程,簡單易懂：

廖雪峰的Git教程

博主也是從這兒入門的，既然有這么好的教程，為什么還要寫這個系列的博客呢？很簡單嘛，這個教程只是入門教程，解決實際工作中遇到的問題還是不夠的，所以博主專門寫Git高級教程，記錄如何解決實際工作中的問題。

2 簡介
先提一個問題，如果線上版本遇到bug，老板要求緊急修復這個bug，然后馬上發版本，可是這個時候我們的代碼新功能已經開發了到一半了，不能回退，怎么辦呢？

用過SVN的童鞋都知道，當一個版本發布后，就要拉一個分支做備份，這樣以后線上版本出現緊急bug就可以直接在分支上修復后，發版本，然后合并分支到主干上。

現在我們使用Git進行版本管理的時候，則只需要打一個標簽就行啦。

3 Git與SVN區別
Git和SVN正好相反，git提倡開發時拉分支，各干各的，相互獨立，發版本時打標簽；而svn呢，平時大家都在主干上干活，發版本時拉個分支，所以呢，svn經常會提交沖突，經常要合并代碼，只能先把自己的代碼備份，然后下載別人的，再合并。Git只需要合并一次就行了。

為啥會這樣呢？因為SVN拉分支真的就是在磁盤上復制一份代碼，速度自然是很慢的啦，所以大家都不喜歡拉分支，只有發版本時拉一下。而git呢，拉一個分支其實只不過是增加了一根指針而已，所以很快，發版本時打個標簽，其實只是取個別名而已，同樣很快。

本文就講述如何通過標簽來修復緊急bug。

4 環境搭建
我們先來模擬開發中遇到的情況，博主演示用的目錄是 e:\learngit?
(1) 首先在e盤下建一個文件夾learngit, 然后打開GitBash，進入e:\learngit目錄，并初始化：

cd "e:\learngit"
git init

使用下面的命令，來設置你的用戶名和郵箱，這里的用戶名和郵箱一般是你的github賬號:

git config user.name "xxxx"
git config user.email "xxx@xxx"

(2) 在leangit下新建一個文件a.txt,然后寫

第一次發版本

用下面的命令來提交：

git add a.txt
git commit -m "第一次發版本"

提交完畢，可以使用下面的命令來查看提交的記錄:

git log

(2) 打標簽，發布版本之后就要打標簽了,命令如下：

git tag -a v1.0 -m "v1.0版本發布"

然后查看所有標簽用下面命令：

git tag?

你也可以查看某個標簽的詳情：

git show v1.0

上面是打標簽的時候寫的備注，下面是標簽記錄的那次提交的備注，其實標簽只是對某一次提交記錄起了一個別名而已，不要以為通過標簽一下次就能拉取代碼。

(3) 在a.txt中增加一行”第二次發布版本”，然后用

git add a.txt
git commit -m "第二次發布版本"?

命令提交，但是不需要打標簽。

(4) 在a.txt中再增加一行”第三次發布版本”，然后用

git add a.txt
git commit -m "第三次發布版本"?

命令提交，也不需要打標簽，這樣我們就模擬了在第一次發布版本，打完標簽后，我們向前繼續開發的過程，a.txt內容如下：

第一次發版本
第二次發版本
第三次發版本

用 git log命令查看，如下圖：

(5) 到此我們就模擬完成了，這個時候第一次發的版本有個bug，要緊急修復，下面我們來完成這個需求

5 通過標簽恢復代碼
(1) 查看標簽的詳情，找出打標簽的那次提交的commit id

git tag
git show v1.0

commit id這么長記不住怎么辦呢？別擔心，我們只需要記住前面幾位就可以了，這里我們只取前6位：7441b8。Git會根據前面幾位自動識別的，當然，你的commit id跟我的肯定是不一樣的。

(2) 版本回退?
下面我們就通過commit id回到發版本時候的代碼去嘍:

git reset --hard 7441b8

注意把7441b8換成你的commid id。回退完畢，再看a.txt:

第一次發版本

如果有亂碼的話，改成以UTF-8無BOM格式編碼。看到沒，我們又回到了第一次發版本時候的代碼，是不是有點小激動啊.

如果這個時候你立馬投入與bug的戰斗，修改后發版本，那么你就犯了嚴重的錯誤，因為你修改后的代碼是無法與正在開發的版本合并噠，也就是說你的修改并不能加入現有的代碼。所以:

特別注意：通過標簽回退版本后，要馬上拉一個分支，然后當前主干分支要立即回到原來的位置，否則正在開發的代碼可能白干了，接著在剛拉的分支上修改bug，修改完畢合并到主干上

(3) 拉取分支

回退版本后，立即拉取分支，這里取名bugfix分支：

git checkout -b bugfix

如圖所示，我們已經在bugfix分支上了：

查看所有分支請用命令：

git branch

(4) 主干分支立即回到原來的位置

首先，請先回到主干分支上：

git checkout master

回退版本需要commit id，向前進呢，同樣也是的。還記得我在第三次提交完畢后，用git log命令查看提交記錄嗎，現在我們需要第三次提交的commit id，再用git log命令：

可以看到只有第一次的提交記錄了，因為這個時候版本回退了git log是查不到第三次提交記錄的，怎么辦呢，怎么才能回去呢？?
別急，這個時候，我們用下面這個命令：

git reflog

看到了嗎，你所有的操作記錄都在這兒，這就是git，記錄操作。可以看到第三次的commit id是 7358a51。回去嘍：

git reset --hard 7358a51

再看a.txt:

第一次發版本
第二次發版本
第三次發版本

回到最新的版本啦

(5) 切換到bugfix分支，修改bug

git checkout bugfix

這時a.txt只有一行文字，因為我們的bugfix分支是回退版本到第一次提交時拉取的分支，接著我們加一行”修復第一次發版本的緊急bug”:

第一次發版本
修復第一次發版本的緊急bug

接著用命令

git add a.txt
git commit -m "修復第一次發版本的緊急bug"
git tag v2.0?

提交這次修改，修改完畢，再打個標簽，一般標簽的版本要升一級,這樣下次再出bug了，就直接從這兒改起，也就可以在合并后直接刪除bugfix分支了

(6) 合并到主干上

在bugfix分支上修復了緊急bug之后，就可以發一個新的版本，之后就要把修復后的代碼合并到我們的主干上，不然下次發版本這個bug還是存在的。合并用下面的命令:

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

這個時候，你可以在心里默念，神獸保佑，沒有沖突。然而這并沒有什么卵用，你念或不念，沖突就在那里，不多不少。這個時候可以用git status 命令查看誰發生了沖突：

從上圖可以看到兩個分支都修改了a.txt,這個時候再來看a.txt:

第一次發版本
<<<<<<< HEAD
第二次發版本
第三次發版本
=======
修復第一次發版本的緊急bug
>>>>>>> bugfix

其中<<<<<<Head到======這個是當前分支，也就是master分支的內容，從======到>>>>>>>bugfix，是bugfix分支的內容?
修改沖突很簡單啦，把多余的內容去掉就可以了

第一次發版本
修復第一次發版本的緊急bug
第二次發版本
第三次發版本

提交代碼就解決沖突了

(7) 推送標簽到遠程

在實際開發中我們都是關聯了遠程倉庫的，在提交完代碼后我們一般用git push將代碼推送到遠程倉庫中，但是git push命令是不會推送標簽的，這點一定要注意

標簽必須手動推送到遠程倉庫

可以用下面的命令一次推送所有標簽到遠程：

git push origin --tags?

(8) 好了，到這里我們就完成了通過標簽修復線上版本的緊急bug，這個時候你就可以刪掉本地分支bugfix了，但是不建議你這么做，搞不好線上又出個bug，你就可以直接接著改啦，反正是在本地的分支。

6 總結
總結一下，通過標簽修改bug的步驟如下：

主分支回退到打標簽的那次提交
拉取分支bugfix
主分支立即回到最新狀態
切換到bugfix分支，修改bug，發版本，打新標簽
合并bugfix分支到主干上
手動推送標簽到遠程

轉自 “梧桐那時雨”的博客：http://blog.csdn.net/fuchaosz/article/details/51698896
?