1、查看提交的歷史版本（git log）

我們可以使用 git log 命令來查看提交的歷史版本。

默認不用任何參數的話，git log 會按提交時間列出所有的更新，最近的更新排在最上面。每個版本都有一個 SHA-1 校驗和、作者的名字和電子郵件地址、提交時間，最后縮進一個段落顯示提交說明。

1.1、展開顯示每次提交的內容差異（git log -p）

git log -p 命令將會列出每次提交時相對于上一版本的修改。用 -2 則只顯示最近的兩次更新

1.2、只顯示每次提交的差異的簡要信息（git log --stat）

只列出了添加的文件，修改過的文件數，以及添加和移除的行數 

 1.3、將每個提交放在一行顯示（git log --pretty=oneline）

 --pretty 選項可以指定使用完全不同于默認格式的方式展示提交歷史。比如用 oneline 將每個提交放在一行顯示，這在提交數很大時非常有用。

2、撤銷操作

2.1、修改最近的一次提交（git commit --amend）

有時候我們提交完了才發現漏掉了幾個文件沒有加，或者提交信息寫錯了，想要撤消剛才的提交并對提交重新進行修改，可以使用  --amend 選項重新提交。（被覆蓋掉的版本其實也可以通過reflog查看，然后恢復該版本）

-- amend 命令的提交操作將會以現在的工作區中的文件為準。現在的工作區中有多少文件，或者工作區對文件進行了修改并加入了暫存區，那么使用 --amend 命令提交的版本將會以現在的工作區為準，并會覆蓋掉剛才的提交。--amend 命令將會啟動編輯器以重新輸入說明。

2.2、取消已暫存的文件（git reset HEAD filename）

假如有兩個修改過的文件，我們想要分開提交，但不小心用 git add . 全加到了暫存區域。我們可以使用 git reset HEAD filename 命令來將某一文件從暫存區中取出來，這時該文件將會又回到了之前已修改未暫存的狀態。

2.3、取消對文件的修改（git checkout filename）

如果覺得剛才對某一文件的修改完全沒有必要，可以使用git checkout filename 命令來讓文件回到沒修改之前的狀態（也就是恢復到了最新一版本的文件狀態）

（該命令只對暫未緩存的文件有效，如果已經放到了暫存區將沒有效果。如果先放到了暫存區然后再進行修改，這時將會用暫存區的文件重寫該文件）

這條命令有些危險，因為所有對文件的修改將會不見并且也恢復不了，所以在用這條命令前，請務必確定真的不再需要保留剛才的修改。

請記住，任何已經提交到 Git 的都可以被恢復。所以，可能失去的數據僅限于沒有提交過的，因為那些對 Git 來說它們就像從未存在過一樣。

3、回退版本（git reset --hard 目標版本號）

使用 git reset --hard 目標版本號能回退到指定的版本，或者使用 git reset --hard HEAD^ 命令能回退到上一版本。

在Git中，用 HEAD 表示現在所處的版本，上一個版本就是HEAD^，上上一個版本就是HEAD^^，往上100個版本寫100個^可以寫成HEAD~100。（在當前所處版本回退版本時，即使回退到 HEAD 版本，當前的修改也不會保存。若想先保存當前修改，可以使用 -stash 命令）

先使用 git log （或者git log --pretty=oneline）命令查看歷史版本，在 commit 字段后的就是版本號。使用 git reset --hard commitID 就能回退到指定版本，此時本地的HEAD指向回退到的版本。注意此時通過 git log 命令并不能看到當前版本（已經回退）的之前那些版本的信息，如果我們回退了某一版本然后又想退回去，可以通過 git reflog 命令查看所有 HEAD 指向過的版本信息。

3.1、查看 HEAD 所指向過的所有版本（git reflog）

git reflog 命令能查看所有 HEAD 指向過的版本信息，包括你在某一時刻回退后當時指向的版本。通過前面的版本號可以看到有哪些時刻指向的是同一版本。

git reflog 可以很好地幫助你恢復你誤操作的數據，例如你錯誤地回退了一個舊的版本，這個時候你可以使用reflog去查看在誤操作之前的信息，并且使用git reset --hard 去恢復之前的狀態。 

4、儲藏修改的內容（git stash）

4.1、儲藏修改（git stash、git stash save '說明'）

當你正在修改項目中的文件代碼，而這時你可能會因為某種原因要回退到之前的某一版本或者是你想轉到其他分支上進行一些其他的工作，但是你不想把現在的修改提交，也不希望在Git上看到當前修改的版本，而且你還想把當前的修改保留著，當你在其他地方的工作完成后還能將修改應用回來，此時你可以用 git stash命令。git stash save '儲藏說明'  命令能為每個儲藏提供說明信息。

“‘儲藏”“可以獲取你修改的內容，包括你修改過的所有已被追蹤的文件和暫存的變更，并將它保存到一個堆棧中，隨時可以重新應用。運行 git stash 命令過后你的工作目錄就會變干凈了，這時你的文件代碼也會回退到沒修改之前，而你的修改全部都保存在了一個堆棧中。

4.2、git stash -u 暫存新建文件

請注意，git stash 默認情況下不會暫存新建的文件，而我們平常也需要將新建的文件進行暫存的，此時要加上 -u 參數

git stash -u
git stash save -u '保存信息說明'

默認情況下， git stash 命令會把以下修改存儲到一個新的堆棧中。堆棧中的內容（stash）可以被所有分支訪問。

git stash 命令暫存的文件包括：暫存區中的修改、工作區中已經存在的文件的修改

也就是說，默認情況下，git stash 命令不會存儲以下文件：工作區中新增的文件（untracked files）、被版本庫忽略的文件（.gitignore 中定義的）

如果你還想要存儲 untracked files，可以使用 -u 選項

參考：https://blog.csdn.net/lamp_yang_3533/article/details/80370380、

4.3、查看儲藏列表（git stash list）

要查看現有的儲藏，你可以使用git stash list 命令。


4.4、重新應用儲藏（git stash apply）

git stash apply stash@{1}：git stash apply 命令應用儲藏默認是應用最上面的儲藏（也是你最新導出的），通過指定名字可以應用更早導出的儲藏，示例：git stash apply stash@{1}

git stash pop：apply 選項只應用儲藏，該儲藏仍然留在棧上，要想在應用的同時移除該儲藏，可以通過 git stash pop 命令，這個命令只支持應用第一個儲藏。

git stash apply --index：重新應用儲藏時，之前放在暫存區的修改并不會自動也放在暫存區，而是處于未暫存狀態。如果你想應用的同時之前放在暫存區的現在也一樣，這時可以使用 git stash apply --index 命令。 

你可以在跟導出儲藏的同一分支且干凈的工作目錄上應用儲藏；但是一個干凈的工作目錄和應用到相同的分支上并不是應用儲藏的必要條件。你可以在其中一個分支上保留一份儲藏，隨后切換到另外一個分支，再重新應用這些變更。在工作目錄里包含已修改和未提交的文件時，你也可以應用儲藏——Git 會顯示有沖突如果有任何儲藏無法干凈地被應用。

4.5、移除指定儲藏（git stash drop 儲藏名）

想要移除指定儲藏，可以運行git stash drop 加上儲藏名，這時并不會應用該儲藏

5、Git 中本地與遠程不同步時

當你在本地修改了代碼，而如果遠程別人也進行了版本提交，此時你直接使用 git pull 會覆蓋掉你本地修改的代碼。

而要想避免這種情況，有兩種辦法：

5.1、先本地提交一個版本再拉取

將本地提交為一個版本，最后再 git pull 拉取，Git 會自動合并對應的遠程分支代碼

git add .
git commit -m '修改了代碼'
git pull  

使用 git pull 后（相當于先使用了 git fetch，然后再使用了git merge），Git 會自動生成一個提交版本，此時可能會彈出一個輸入窗，需要你輸入此時合并的說明信息，也就是此時提交版本的說明信息。

如果合并有沖突，Git 不會生成提交版本，而是等你手動解決沖突，解決完沖突后應該手動提交一個版本。

這樣做的缺點是必須先在本地提交一個版本，然后合并后還得生成一個版本才行。要避免這種情況，可以參考下面的方法，即只要合并后生成一個版本即可

5.2、使用 git stash （推薦）

可以使用 git stash 命令將本地修改全部放入暫存（注意：默認不包括新生成的文件），然后拉取代碼，再使用 git pop 應用修改

git stash    //或者是 git stash -u
git pull
git stash pop

參考：https://blog.csdn.net/yangfengjueqi/article/details/82848962

6、git 上的HEAD、Index、Working Copy的概念

1）HEAD：可以理解為當前本地分支的最近的一次提交，即本地的版本信息中的最新 commit 版本

2）Index（索引）：在本地修改之后已經執行過了 git add 操作的文件，即暫存區中的文件

3）Working Copy（工作目錄）：工作副本指的是你已經進行了修改，但是沒有執行任何 git 操作的文件，即已經修改過但是還沒放到暫存區的文件。

7、git 上的回退操作的三個參數（git reset --soft、--mixed、--hard）

在 git 上你可以使用 git reset 命令來進行回退操作，該命令有三種模式：軟模式、混合模式和硬模式。三種模式對于本地修改的保留越來越少。

7.1、軟模式（git reset --soft commitId）

該模式的回退操作只是將你的本地提交版本回退到你指定的 commit id 版本上，但是在這個 commit id 版本之后的所有修改，包括后面版本的修改和你的本地的已提交和未提交的修改都不會被刪除，此時你只需要重新提交一個版本即可，在這個 commit id 版本之后的所有修改都會保存在新生成的版本中。

git reset --soft xxxx  // xxxx 表示你要回退到的版本的commit id

git status   //查看狀態你可以看到你的所有修改都沒有丟失

//然后重新提交一個版本即可
git add .
git commit -m '新版本'

這個模式的回退操作的影響只是讓你的本地倉庫丟失了一些提交版本的注釋信息而已。也就是說軟模式的回退只是改變了你的當前版本指向HEAD而已，你的索引Index和工作目錄working copy都不會發生任何改變。

在執行了軟模式回退之后，如果那些丟失的版本信息之前已經提交到了遠程倉庫的時候，你在執行了回退操作之后是不能將本地倉庫直接推送給遠程倉庫的，Git 會提示你的本地版本落后于遠程版本，必須得先拉取再推送。所以說，已經推送到了遠程倉庫中的版本信息是不會丟失的，你不可能在本地回退以后就能直接推送至遠程上。除非你進行強制推送，但這個命令非常危險，因為這會導致你的遠程倉庫中也會丟失這些版本信息，而且很可能會找不回來，所以不要輕易嘗試。

7.2、混合模式（git reset --mixed commitId，不帶參數時的默認模式）

混合模式是 git reset 命令不指定任何參數時默認執行的模式，該模式的回退操作會改變你的當前版本指向HEAD和索引 Index，而工作目錄working copy是不會發生改變的。也就是說的將你的當前版本指向改成你指定的版本，同時你執行了 git add 命令的文件將不會被繼續放在暫存區，因為該回退操作并不會保留暫存區的狀態，但是你在本地的所有修改都不會被刪除掉。

該回退操作命令除了把你的暫存狀態清掉，并不會對你的本地修改有任何影響，所以該回退操作影響也不算很大。

7.3、硬模式（git reset --hard commitId）

硬模式的回退操作非常危險，因為該模式的回退會直接將你的本地文件代碼回退至你所指定的版本，并且不會保留你在該版本之后的所有修改。不過所幸的是也可以通過 git reflog 命令查看本地曾指向過的所有版本號然后再回滾至之前所指向的最新版本，由此可以撤銷該操作。

硬模式的回退操作將會重置HEAD、Index和working copy，直接將你的本地文件回復至指定的版本的內容，也不會保留你本地未提交的修改，所以建議在執行該命令之前，先將本地修改提交為一個版本，以便能再次回滾至當前工作的版本。

硬模式命令的使用和撤銷參考上文中的：3、回退版本（git reset --hard 目標版本號） --> http://www.rzrgm.cn/wenxuehai/p/10401380.html#_label2

8、強制推送本地倉庫至遠程倉庫（git push -f origin master，非常危險）

在 git 中，為了保護遠程倉庫安全和避免用戶誤操作，在很多情況下你是無法將本地倉庫直接推送至遠程倉庫中的，比如說你的本地版本落后于遠程倉庫版本等等，這時候就會提示你先拉取再推送或者進行其他命令。

比如說我們再執行了回退操作 reset 后，是不會允許你直接將本地版本推送至遠程倉庫中的，因為此時你的本地版本就落后于遠程倉庫的版本，這也是為了避免用戶亂操作，導致遠程倉庫的版本被胡亂修改。此時如果你確確實實是為了回退至某指定版本，因為你在這個指定版本之后的修改操作都出錯了，不需要保留的話，Git 中也是可以強制將本地倉庫推送至遠程倉庫的。

比如：在遠程倉庫中最新的版本是 merge branch ....，如下圖所示：

然后我們在本地執行了回滾版本的操作，將本地版本回滾到了 "提交3"，：

 如果我們直接推送會提示我們必須先拉取再推送，這也是為了避免我們的遠程倉庫被誤操作導致版本回退。

 但如果我們確確實實是要回滾版本，并且需要推送至遠程倉庫中給所有協同者使用的話，我們可以使用強制推送命令：

git push -f origin 分支名
//比如：
git push -f origin master

此時在遠程倉庫中就可以看到在 “提交3” 版本之后的版本信息都不見了

這個命令非常危險，因為這會使得你的遠程倉庫中丟失了一些版本的提交信息，除非這個操作是非常必要的，否則不要輕易嘗試強制推送命令。

當然你也可以通過 git reflog 命令來查看你所有曾指向過的版本信息，然后再通過 git reset --hard 命令來指向之前的最新版本來避免強制推送導致的錯誤。但是 git reflog 命令只是針對于你本地曾指向過的版本信息，在遠程倉庫中的項目的并不會記錄這些信息，也就是說除了你以外，任何新克隆項目的人和未拉取最新版本的人都不曾感知過之前的最新版本的存在，也就無法操作回退至之前的最新版本。或許會出現除了你以外其他人都無法回退至最新版本的情況，所以說不要輕易嘗試這個命令。