05、git其他常用命令介紹

前面四節我們對git概念以及一些常用的命令做了介紹，但是考慮到文章的篇幅和連貫性，將一些實際也很重要的命令集中到本節博客做個補充。
本節內容預告：

1.git刪除和移動
2.標籤，diff和blame
3.checkout 和stash

1.git 刪除和移動

這個主要是爲了對比一下，我們和實際的直接刪除移動命令有什麼不一樣。

1.1 重命名文件

可以看到，剛開始我們有一個test.txt 的文件，然後通過linux的命令重命名爲test2.txt,然後使用命令git status,git 提示我們可以使用git add 命令添加內容到暫存區，另外還要留意到，我們重命名一個文件git實際上是理解爲我們先創建一個新的文件，然後再刪除舊的文件，注意這裏直接添加會git有個報錯：

git提示我們不能直接使用命令git add .，需要使用git add -A來添加這個變更，最後使用commi提交變更到版本庫。

如果使用git提供給我們的命令怎麼操作呢？
使用git mv 文件名 新的文件名,這樣就會變更保存到了暫存區，然後我們需要做的就是使用commit提交這個變更，通過和上面的對比，可以發現，使用git mv實際上是做了兩步操作，一步是在工作區變更，另一步是保存到暫存區

1.2 git rm 命令

git rm 命令實際上也是兩步操作，和上面的git mv類似，這裏就不再贅述了，有興趣可以自己本地嘗試

2.tag，diff和blame

2.1 git tag

我們在日常的版本迭代更新中偶爾會有一個重大的迭代更新，比如產品1.0初版上線等這種里程碑式的發版，需要做個標籤記錄下來。

因爲我們前面說過git每次提交都會有一個提交id生成，但是因爲提交id是一個sha1值，很不好記憶，然後我們是通過提交信息來標記這次提交的。想象一下，當你的版本一直迭代開發，有成白上千次提交的時候，這時候想要從這麼多提交信息裏面找到一個你想要的版本是比較頭疼的，而且如果有相似的提交信息更容易混亂。

基於類似種種原因，git給我們提供了一個標籤的功能，簡而言之就是給我們當前發版的穩定分支打一個標籤，這樣後面需要找這種版本的時候，就不會去提交記錄裏面翻找，而是在tag裏面查看，需要注意tag需要有明確意思，比如那個項目-那個日期-上線內容-版本號等，這樣更容易找到對應的版本，也避免時間長了後區分不清楚tag是哪個版本的。

初學這個的時候感覺這個沒啥作用，我們上次發生產環境後因爲代碼需要遷移到客戶的版本庫，算是一個里程碑式的標記，所以就想着打一個標籤，當然還有一種比較low的做法是在原來分支基礎上新拉一個分支，然後後續版本迭代在新的分支上面，不動原來分支代碼。。。

下面簡單介紹一下tag使用命令

1. git tag v1.0
   這個命令是基於當前分支最新的提交創建一個v1.0的標籤
2. git tag -l
   查看當前所有標籤，後面可以跟參數實現模糊查找和精確查找
   
3. git tag -a 'name' -m ’註釋‘
   可以給你的tag加註釋
   
4. git tag -d v1.0
   刪除某個tag
   關於標籤，暫時就展開這麼多，這裏需要留意，tag是不依賴於某個分支的，簡單來說就是你在這個分支打的標籤，在其他分支也能正常查看使用。

2.2 git blame

我們經常會遇見一種情況是，一個文件被很多人修改過，但是你不清楚有問題的那塊代碼最後一次是被誰修改的，什麼時候修改的。
git給我們提供了一個功能，可以看到一個文件的每行代碼，是被誰修改的，什麼時候修改的。這就是git blame。使用命令git blame 文件名，可以看到如下，每行最後一次修改的時間，作者是誰，提交id，這樣可以很方便的定位到具體是誰修改的代碼，這個命令關鍵時刻很管用，後面也會講git和idea集成的時候的使用方式

這個命令可以跟很多參數，這裏就不展開了，感興趣可以通過git blame --help查看具體使用方式或者訪問git官網

2.3 git diff

在瞭解git diff之前，我們先了解一下linux自帶的diff命令
在linux中，diff命令用於逐行比較兩個文件的差異，例子如下：有兩個文件內容如圖所示

上面的1,3c1,5的意思是，左邊的文件一到三行和有邊的文件一到五行比較，
箭頭向左表示左邊的文件減三行，向右表示左邊的文件加五行，這樣就會和右邊的文件一樣。

如上所示，通過加參數diff -u 文件一 文件二以合併的方式展示文件的差異，這種方式就比較明瞭了，很顯然看到左邊的文件減去一到三行，加上1,5行會和右邊的文件一致。
那麼git diff怎麼使用呢？

git-diff - Show changes between commits, commit and working tree, etc

這是git官網對git diff的介紹，展示提交之間以及提交和工作目錄之間的改變等等，這個命令在我們日常代碼版本維護中也是經常會用到的一個命令。

1. git diff 比較工作區與暫存區的差異
2. git diff --cached 比較暫存區與版本庫差異
3. git diff HEAD 比較工作區與版本庫的差異
4. git diff test 不帶分支的時候，我們比較的是當前分支的，加了分支我們比較test分支
5. git diff HEAD – ./test 比較當前分支，但是限制只比較test這個文件
6. git diff HEAD^ HEAD 比較上次提交和上上次提交
7. git diff topic master 或者 git diff topic…master 比較topic分支和master分支之間差異，
8. git diff topic…master 比較自從topic從master新創建後，master和topic的差異
9. git diff --diff-filter=MRC 僅展示修改，重命名和複製，不展示新增和刪除
   這邊列舉了一些常見的，更多高級用法見git diff 官網

3. stash 和 checkout

3.1 checkout簡單回顧

關於checkout前面有多個地方提到，容易混亂，這裏簡單回顧一下。
我們再提到代碼 版本回滾的時候，講到可以通過命令git checkout -- 文件名 丟棄工作區相對於暫存區的變更，修改的是工作區的內容
然後還可以通過命令git checkout 提交id ,直接將代碼回滾到對應提交
分支切換的時候，當我們想切換的一個分支時，使用命令git checkout test，這樣就會切換到test分支。

3.2 stash

比較有經驗的開發肯定會遇見下面的場景：
有一個需求開發到一半，突然有一個緊急的需求或者線上的bug要修改，這時候需要從主分支新拉一個分支修改bug，問題是當兩個分支指針不一樣時，一個分支本地有修改後，如果有緊急需求需要切換到另一個分支是不可以的，因爲會丟失修改內容，此時可以選擇提交修改解決報錯，但是因爲代碼沒開發完，提交內容不能保證正常運行，所以需要用到stash

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
這段話是我在官網摘抄的，大意是：當你想當前工作區和暫存區的狀態，但是想要一個乾淨的工作區時，用git stash,這個命令保存了你的本地改變，而且轉換你本地工作區的內容與最新的提交保持一致。

3.2.1 git stash save ‘臨時保存’

可以看到上面剛開始有兩個文件要提交，通過git stash save 命令，將保存的內容保存起來。

3.2.2 git stash list

列舉當前有多少個stash,執行命令git stash list

3.2.3 git stash pop

恢復工作現場，同時會將緩存的stash內容刪除，可以看到內容恢復，此時使用git stash list發現緩存的stash內容刪除

3.2.4 git stash apply

恢復工作現場，保留緩存的stash內容，可以看到內容恢復，此時使用git stash list發現緩存的stash內容仍然存在

注：stash可以緩存多次，此時如果單純使用git stash pop或者 git stash apply,默認會恢復最新的也就是圖示最上面的內容，可以通過指定參數，如git stash pop stash@\{0\}，來告訴git，你想恢復的是哪一個內容

最後，我們根據官網的例子，代入一個使用場景：

When you are in the middle of something, you learn that there are upstream changes that are possibly relevant to what you are doing. When your local changes do not conflict with the changes in the upstream, a simple git pull will let you move forward.
你一個需求開發到一半發現，同事改了部分代碼，而且這部分代碼是你要用到的，此時，如果你本地代碼和同事已經提交的代碼沒有衝突的話， 你可以簡單通過git pull命令獲取遠程更新，本地相當於一個簡單的向前移動。
However, there are cases in which your local changes do conflict with the upstream changes, and git pull refuses to overwrite your changes. In such a case, you can stash your changes away, perform a pull, and then unstash, like this:
但是，常見的是，你的同事提交的的代碼和你本地的有衝突，git pull 命令拒絕覆蓋你本地的代碼變更，就是說，git pull ,默認不會強制覆蓋你的本地變更，這樣也很合理，不然可能會造成工作內容的丟失。在這種情況下：你可以先通過stash命令將你的變更保存到其他地方，然後本地就是乾淨的，通過pull命令獲取遠程變更，最後在通過pop命令恢復你的本地變更，此時應該會有衝突，你要做的就是解決本地解決衝突就好。如下：
$ git pull
…
file foobar not up to date, cannot merge.
$ git stash
$ git pull
$ git stash pop

另一個例子：

When you are in the middle of something, your boss comes in and demands that you fix something immediately. Traditionally, you would make a commit to a temporary branch to store your changes away, and return to your original branch to make the emergency fix, like this：
當你一個需求做到一半，老闆過來讓你馬上改一個線上緊急的bug,通常來說，你可以創建一個臨時的分支保存你的提交，然後切換到原始分支改bug,改完沒問題後，再切回你的臨時分支繼續coding,coding,coding…

… hack hack hack …
$ git switch -c my_wip
$ git commit -a -m “WIP”
$ git switch master
$ edit emergency fix
$ git commit -a -m “Fix in a hurry”
$ git switch my_wip
$ git reset --soft HEAD^
… continue hacking …
You can use git stash to simplify the above, like this:
你也可以使用下面的方式：
#… hack hack hack …
$ git stash
$ edit emergency fix
$ git commit -a -m “Fix in a hurry”
$ git stash pop
… continue hacking …

至此，git一些比較常見的命令我們基本介紹完畢，細心的讀者會發現，當前我們基本上雖說有時候會在一些案例中穿插的講到一些遠程的命令，但是還沒有系統的陳述介紹，下節我們開始介紹遠程命令與多人協作等。

下節預告：
1.git關聯遠程倉庫，以github爲例
2.git協作
3.git遠程分支，別名，以及git可視化界面簡介

最後，感謝閱讀，如有錯誤，請不吝指正