一、給本地倉庫分支打輕量級tag標籤
1、在Git中打標籤非常簡單,首先,切換到需要打標籤的分支上:
$ git branch
devwhd
gray
* master
optimize_sel_driver_20170911
pre_production
2、然後,敲命令
git tag <name>
就可以打一個新標籤:$ git tag v1.0
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 <[email protected]>
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 <[email protected]>
Date: Thu Sep 14 14:22:25 2017 +0800
version 0.1 released push url
commit d5a65e9a08be3820d0b0a59b3df9750168557cd5 (tag: v0.1)
Author: whd <[email protected]>
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 <[email protected]>
Date: Thu Sep 14 14:22:25 2017 +0800
version 0.1 released push url
commit d5a65e9a08be3820d0b0a59b3df9750168557cd5 (tag: v0.1)
Author: whd <[email protected]>
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、主幹分支立即回到原來的位置
(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,git commit -m"add test1.c",git commit -m"add test2.c",git commit -m"add test3.c":
commit3: add test3.c
commit2: add test2.c
commit1: add test1.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這樣回退就完成了!