檢視檔案的修改歷史

git log --pretty=oneline 檔名 # 顯示修改歷史[Git高階教程:git log與git reflog]

git show 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e # 檢視更改

歷史版本檢視和對比git show, git diff

檢視某一歷史版本的提交內容git show 4ebd4bb，這裡能看到版本的詳細修改程式碼。

對比不同版本git diff c0f28a2e 2e476412c34a63b213b

push之前可以使用git diff origin/dev...HEAD --name-status檢視要push的內容有沒有改變。

Note: 版本號沒必要寫全，前幾位就可以了，Git會自動去找。

[Git高階教程git log與git relog]

git reset命令

包括 --mixed，--soft --hard等，其中--mixed為預設方式，他們之間的區別如下
git reset –mixed：此為預設方式，不帶任何引數的git reset，即時這種方式，它回退到某個版本，只保留原始碼，回退commit和index資訊
git reset –soft：回退到某個版本，只回退了commit的資訊，不會恢復到index file一級。如果還要提交，直接commit即可
git reset –hard：徹底回退到某個版本，本地的原始碼也會變為上一個版本的內容
git reset -soft :取消了commit

。
git reset  --mixed（預設） :取消了commit ，取消了add。Your branch is ahead of 'origin/master' by 1 commit.不小心commit大檔案，但是push失敗，使用git log找到上一次的版本號，再使用git reset --mixed 版本號就可以了。
git reset -hard :取消了commit ，取消了add，取消原始檔修改（相當於checkout了也）。

重置檔案

在git中，有3種類型的重置。重置是讓檔案回到git歷史中的一個特定版本。

1. git reset –hard {{some-commit-hash}} —— 回退到一個特定的歷史版本。丟棄這次提交之後的所有變更。
2. git reset {{some-commit-hash}}—— 回滾到一個特定的歷史版本。將這個版本之後的所有變更移動到“未暫存”的階段。這也就意味著你需要執行 git add . 和 git commit 才能把這些變更提交到倉庫.
3. git reset –soft {{some-commit-hash}} ——回滾到一個特定的歷史版本。將這次提交之後所有的變更移動到暫存並準備提交階段。意味著你只需要執行 git commit 就可以把這些變更提交到倉庫。

這些命令似乎並沒有什麼用處，但當你嘗試著將檔案在不同版本間移動時，使用它們會非常方便。

使用重置的一些用例如下：

1. 如果想清除變更記錄，可以使用清理命令——git reset –hard HEAD
   
2. 如果想編輯，以不同的順序，重新暫存，重新提交檔案—— git reset {{some-start-point-hash}}
3. git reset –soft {{some-start-point-hash}}如果想把之前3次的提交，作為一次提交 git reset –soft {{some-start-point-hash}}

檢視日誌命令git log與git reflog

一個簡單的git log命令，顯示你最近的提交資訊，以及上一次，再上一次的提交資訊，以此類推。

而git reflog顯示的是所有head移動的資訊。記住，它是在本地的，而不是你倉庫的一部分，不會包含在推送(push)和合並中(merge)。

Note: git log 如果日誌過長顯示不完整，則按q結束。

git log

得到的提交資訊是我的倉庫的一部分。

命令示例：

git log --oneline --graph

git log常用引數：

• –author=“Alex Kras” ——只顯示某個使用者的提交任務
• –name-only ——只顯示變更檔案的名稱
• –oneline——將提交資訊壓縮到一行顯示
• –graph ——顯示所有提交的依賴樹
• –reverse ——按照逆序顯示提交記錄（最先提交的在最前面）
• –after ——顯示某個日期之後發生的提交
• –before ——顯示發生某個日期之前的提交

如果這些都不好用，git還有一個 --pretty 引數，可以用來建立高階自定義輸出。

例如，曾經有位主管要求在每週五提交週報。所以我每週五都執行一下這個指令： git log --author="Alex Kras" --after="1 week ago" --oneline，然後將輸出結果編輯一下，傳送給主管稽核。

檢視檔案的詳細變更git log -p
git log -p 或者 git log -p filename 不僅顯示提交說明、提交者以及提交日期，還會顯示這每次提交實際修改的內容。
然後你就可以使用 less 中常用的檢索命令即“斜槓”後面加檢索詞/{{在此處新增你的檢索詞}}），在變更內容日誌中檢索指定的關鍵詞（使用小寫的n跳到下一條檢索結果，大寫的N跳到上一條檢索結果）。

檢視檔案中指定位置的變更git log -L 
命令示例：git log -L 1,1:some-file.txt
你可以使用 git blame filename 追查出檔案中每一行是由誰變更的。
git blame 是一個非常強大的工具，但是又是無法提供足夠的資訊。
git log 提供了一個 -L 的選項。這個選項允許指定檔案中的某些行。Git只會輸出與這些行的變更日誌。這有點像帶焦點的 git log -p 。

檢視尚未合併的變更git log --no-merges master
如果你曾經與很多小夥伴工作在同一個持久分支上，也許會有這樣的經歷，父分支（例如：master）上的大量合併同步到你當前的分支。這使得我們很難分辨哪些變更時發生在主分支，哪些變更發生在當前分支，尚未合併到master分支。
git log --no-merges master..可以解決這個問題。注意--no-merges 標誌意味著只顯示沒有合併到任何分支的變更，master..選項，意思是指顯示沒有合併到master分支的變更（在master後面必須有..）。
你也可以執行 git show --no-merges master.. 或者 git log -p --no-merges master.. 命令（輸出結果相同）來檢視一下尚未合併的檔案

git relog

你提交了一個你不想要提交的程式碼，最後你通過使用硬重置(hard reset)使其回到了之前的狀態。稍後，你意識到，在這個過程中你丟失了一些其他的資訊，並想要退回或是至少能看一眼。git reflog命令可以幫你做到這一點。

git reflog顯示了一個提交資訊（b1b0ee9 – [email protected]{4}），這是我使用硬重置(hard reset)時丟失的那個。

git檔案刪除和恢復

{針對檔案刪除及恢復}
刪除檔案跟蹤並且刪除檔案系統中的檔案file git rm file
提交剛才的刪除動作，之後git不再管理該檔案git commit
刪除檔案跟蹤但不刪除檔案系統中的檔案file git rm --cached file
Note:--cached Use this option to unstage and remove paths only from the index.Working tree files, whether modified or not, will beleft alone.只是將檔案從暫存區去除（不影響工作區對應的檔案）。
[git-rm - Remove files from the working tree and from the index]
提交剛才的刪除動作，之後git不再管理該檔案。但是檔案系統中還是有file。 git commit
[Git版本控制教程 - Git本地倉庫:刪除檔案]

本地檔案被舊的遠端檔案覆蓋怎麼撤銷修改

git reflog ，找到同步前的提交，git reset 就可以了

git rm 之後的檔案如何還原

執行$git rm createGraph.py刪除檔案createGraph.py後，發現刪除錯了。
解決方案1：
$git status
...
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
    deleted:    createGraph.py
可以看到提示先使用git reset HEAD <file>...來unstage檔案
$git reset HEAD createGraph.py
Unstaged changes after reset:
D    createGraph.py
再檢視一下
$git status
...
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
    deleted:    createGraph.py
可以看到提示先使用git checkout -- <file>...來丟棄檔案的修改
$git checkout -- createGraph.py
這樣就恢復了rm了的檔案
$ls
createGraph.py
解決方案2：
git rm README
git status
$ git stash list
[email protected]{0}: WIP on master: bfcdf14 test git
#拿出來使用 git stash pop
git stash pop
[:git stash]
解決方案3：
這時可以直接使用git log; git reset --hard "commit id"恢復到上一個commit，但是這樣不好，我只想恢復刪除的那一個檔案，要是commit之間做了很多改動，恢復到上一個commit會將其它檔案的修改都恢復了。要對單個檔案修改。
首先檢視該檔案的歷史版本資訊：git log [email protected]

記錄下需要恢復的commit版本號：如 9aa51d89799716aa68cff3f30c26f8815408e926
恢復該檔案：git reset 9aa51d89799716aa68cff3f30c26f8815408e926 [email protected]
提交git:git commit -m "revert old file"
測試了一下，發現檔案根本沒有改動，只是有unstaged commit的提示（說明一下，我是在windows環境下使用git客戶端，linux不知道是不是同樣的問題），並且，一旦執行“git add .”，所有暫存區中的變化全都消失了。
嘗試執行git checkout命令，因為這個命令平時只適應於將檔案恢復到上次遞交的狀態，而不能選擇遞交的版本。
雖然執行完畢後什麼提示都沒，但是檢視檔案可以看到，檔案已經被修改為歷史版本了。
總結：git將單個檔案恢復到歷史版本的正確方法如下：
   git reset commit_id 檔案路徑
   git checkout -- 檔案路徑
[ GIT 恢復單個檔案到歷史版本]

版本回退-撤銷檔案修改

{針對檔案修改恢復}

工作區修改一個檔案後，又想回到修改前（add之前）

1. 當然可以直接手動再在工作區中將檔案修改回去

2. 修改後，通過命令git status檢視

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

這時Git會告訴你，git checkout -- file可以丟棄工作區的修改：

$ git checkout -- readme.txt

Note:

1. git checkout -- file命令中的--很重要，沒有--，就變成了“切換到另一個分支”的命令，我們在後面的分支管理中會再次遇到git checkout命令。

2. 命令git checkout -- readme.txt意思就是，把readme.txt檔案在工作區的修改全部撤銷，這裡有兩種情況：

一種是readme.txt自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；一種是readme.txt已經新增到暫存區後，又作了修改，現在，撤銷修改就回到新增到暫存區後的狀態。總之，就是讓這個檔案回到最近一次git commit或git add時的狀態。

如果在工作區中修改了檔案還git add到暫存區（add之後，commit之前）

用git status檢視一下，修改只是新增到了暫存區，還沒有提交：

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   readme.txt
#

Git同樣告訴我們，用命令git reset HEAD file可以把暫存區的修改撤銷掉（unstage），重新放回工作區：

$ git reset HEAD readme.txt
Unstaged changes after reset:
M       readme.txt

git reset命令既可以回退版本，也可以把暫存區的修改回退到工作區。當我們用HEAD時，表示最新的版本。這裡相當於git reset  --mixed HEAD。

再用git status檢視一下，現在暫存區是乾淨的，工作區有修改。

然後如果想丟棄工作區檔案的修改git checkout -- readme.txt，當然也可以直接使用git reset  --hard HEAD。

不但修改了檔案還從暫存區提交commit到了版本庫 - 版本回退（commit之後，push之前）

版本回退可以回退到上一個版本。不過，這是有條件的，就是你還沒有把自己的本地版本庫推送到遠端。Git是分散式版本控制系統。

在工作中對某個檔案（如readme.txt）進行多次修改交commit。

可以通過版本控制系統命令告訴我們提交的歷史記錄，在Git中，我們用git log命令檢視：

$ git log
commit 3628164fb26d48395383f8f31179f24e0882e1e0
    append GPL

commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
    add distributed

Note:

1. git log命令顯示從最近到最遠的提交日誌，我們可以看到2次提交，最近的一次是append GPL，最早的一次是add distributed。

2. 如果嫌輸出資訊太多，看得眼花繚亂的，可以試試加上--pretty=oneline引數：

$git log --pretty=oneline
3628164fb26d48395383f8f31179f24e0882e1e0 append GPL
ea34578d5496d7dd233c827ed32a8cd576c5ee85 add distributed

3. 你看到的一大串類似3628164...882e1e0的是commit id（版本號），和SVN不一樣，Git的commit id不是1，2，3……遞增的數字，而是一個SHA1計算出來的一個非常大的數字，用十六進位制表示，而且你看到的commit id和我的肯定不一樣，以你自己的為準。為什麼commit id需要用這麼一大串數字表示呢？因為Git是分散式的版本控制系統，後面我們還要研究多人在同一個版本庫裡工作，如果大家都用1，2，3……作為版本號，那肯定就衝突了。

4. 每提交一個新版本，實際上Git就會把它們自動串成一條時間線。如果使用視覺化工具（如GitX、github的客戶端、pycharm）檢視Git歷史，就可以更清楚地看到提交歷史的時間線。

現在我們想要把readme.txt回退到上一個版本

如“add distributed”的那個版本，怎麼做呢？首先，Git必須知道當前版本是哪個版本，在Git中，用HEAD表示當前版本，也就是最新的提交3628164...882e1e0，上一個版本就是HEAD^，上上一個版本就是HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成HEAD~100。

現在，我們要把當前版本“append GPL”回退到上一個版本“add distributed”，就可以使用git reset命令：

git reset HEAD^

Note：lz建議不要使用--hard，萬一之前沒有commit，而修改了工作區的檔案，hard會使工作區的檔案修改消失。

$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed

這時readme.txt的內容就成了版本add distributed。我們用git log再看看現在版本庫的狀態：

$ git log
commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
    add distributed

最新的那個版本append GPL已經看不到了！

恢復檔案後，要是我們又想回到修改後的檔案呢？（命令列視窗未關掉）

{這個是git reset --hard後，又反悔了，想回到修改後的狀態}

只要上面的命令列視窗還沒有被關掉，你就可以順著往上找啊找啊，找到那個append GPL的commit id是3628164...，於是就可以指定回到未來的某個版本：

$ git reset --hard 3628164
HEAD is now at 3628164 append GPL

Git的版本回退速度非常快，因為Git在內部有個指向當前版本的HEAD指標，當你回退版本的時候，Git僅僅是把HEAD從指向append GPL：

改為指向add distributed：

然後順便把工作區的檔案更新了。所以你讓HEAD指向哪個版本號，你就把當前版本定位在哪。

恢復檔案後，要是我們又想回到修改後的檔案呢？（命令列視窗早就關掉了）

想恢復到新版本怎麼辦？找不到新版本的commit id怎麼辦？當你用$ git reset --hard HEAD^回退到add distributed版本時，再想恢復到append GPL，就必須找到append GPL的commit id。

Git提供了一個命令git reflog用來記錄你的每一次命令：[Git高階教程:git log與git reflog]

$ git reflog
ea34578 HEAD@{0}: reset: moving to HEAD^
3628164 HEAD@{1}: commit: append GPL
ea34578 HEAD@{2}: commit: add distributed

第二行顯示append GPL的commit id是3628164。git reset --hard回到這個版本號就ok了。

git 撤銷檔案追蹤

git忽略已經被提交的檔案/資料夾

{git 對於 已經新增到版本庫的檔案設定忽略}

問題

git commit時候忘記設定ignore了，於是commit了一個相當大的檔案，git push時候，因為要push大檔案，可能會出錯，也可能push好久還沒好。如果直接刪除掉大檔案，再push還是同樣問題；如果把大檔案放到忽略檔案裡，再push，還是這樣的問題不變。
幾種解決方案：

解決方案1

適用於這個檔案是最近一次commit的，並且git commit的其它內容（如小檔案）也回退。

一旦發現git push了大檔案失敗了，就使用命令git reset  --mixed回退這次commit（取消commit ，取消add），再新增.gitignore再add 和 commit。

解決方案2

git當push100M以上檔案，就直接拒絕你的push，要想push必須把該檔案從本地倉庫和遠端倉庫全部移除到commit外。
注意此方法適用於這個檔案是最近一次commit的{包括已經push到github了（所以要先git pull）}並且希望git commit的其它內容（如小檔案）不回退。
git rm --cached /XXX/XXX/libbaiduNaviSDK.a（加下劃線部分是你自己的要移除的檔案的路徑）
find . -size +100M ! -path "*git*" | xargs git rm --cached
git commit --amend -CHEAD
find . -size +100M ! -path "*git*" | mv /tmp/tmpgit
git pull
git push
下次再add時
先新增大檔案到.gitignore
mv /tmp/tmpgit .
再git add .
git commit -m 'del -size +100M'
git pushNote: 
第一步：將檔案從暫存區去除；
第二步：是修改提交，也就是用這次刪除了大檔案的暫存區的新的commit覆蓋上次大檔案的commit；
第三步：移除之前的大檔案（或者是想刪除之前commit上的檔案）；
第四步：如果不執行幹什麼都會提示：On branch master Your branch and 'origin/master' have diverged,and have 1 and 1 different commits each, respectively.  (use "git pull" to merge the remote branch into yours)nothing to commit, working tree clean
第五步：新增大檔案不加入git版本控制
第七步：commit
執行完這步後，這個大檔案將會從你的commit記錄裡和add移除（也就是不會再出現在stage暫存區或者master中，這些大於100M的檔案會回到git add .之前的狀態，相當於沒有git add，成為untracked files），這時候就可以git push把原生代碼push到github上了。
記得加.ignore或者回到git lfs中來上傳大檔案！[]
[Removing a file added in the most recent unpushed commit]
[Working with large files]
如果是前幾次提交的git commit了大檔案，這時上面的修改可能包含了對大檔案的處理過程（這樣就可逆對大檔案的commit了？），還是會上傳對大檔案的修改。如：
$ git diff origin/master --name-statusA       JIM/business_result.json #並沒有大檔案會push
A       JIM/yelp_academic_dataset_business.json
A       JIM/yelp_academic_dataset_tip.json
但是git push時怎麼還是上傳的這個大檔案，這難道是因為git diff比較的只是當前commit和遠端，而本地實際有兩個commit版本，大檔案存在於前一個版本中，所以只要有就會上傳
remote: error: Trace: 4cbb68625000edd0054cf593be3f7058
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File JIM/test_candidate.dat is 188.52 MB; this exceeds GitHub's file size limit of 100.00 MB
這時只能使用下面的終極解決方案2了，前本地commit所有版本中的大檔案都del掉。

終極解決方案3

此方法適用於這個檔案是前幾次commit的

git filter-branch --tree-filter

如commit了一個EpipeCpu/ipch目錄下的大檔案， 現在要push但是僅想刪去commit中的這個目錄。
$git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch 大檔案目錄或名字 -r' --prune-empty --tag-name-filter cat -- --all
Rewrite 44a7e4ad5e52ff26306338fbba9a890c50ba9ba7 (1/1) (0 seconds passed, remaining 0 predicted)  
 rm 'EpipeCpu/ipch/algorithms-5512fb35/algorithms-c0d91126.ipch'
rm 'EpipeCpu/ipch/epipecpu-63fefe78/epipecpu-e9527547.ipch'
Ref 'refs/heads/master' was rewritten
再使用git push就不會上傳那個目錄下的檔案了
當然lz也將這個目錄加入到了exclude中（之前git commit忘了加的）。
不過此方法有可能會帶來一些問題
一定要儘可能少用這個功能，雖然他可以減少我們 git 目錄的大小，但是這會對其他協作者產生極大的影響。所有受到影響的 commit 的 ID 都會被重寫，另外如果 commit 像我這樣有 GPG 簽名的話，就無法執行這個操作了。
[從 git commit 中永久刪除某個檔案]

使用git reset回滾commit操作

像上面撤銷檔案修改那樣git reset操作解決。但是如果是commit很多次提交後才發現commit了大檔案，回滾到大檔案之前的同時也回滾了不想回滾的其它commit，這樣不好。並且這樣有可能git reset操作之後有時候還是會提交上次提交失敗的大檔案，可能還在上一個commit中大檔案沒有ignore(這個是通過git diff origin/dev...HEAD --name-status查到大檔案還是會上傳push看到的)，git reset方法似乎不是最保險。

使用git rm --cached

{這個刪除了還是要上傳的，不知道為嘛，可能是因為：git rm --cached will add the delete action of the file to the index, just like git add will add an add action.也就是說還是會新增這個檔案到遠端，然後再刪除，不是坑嗎...不過lz覺得這個方法只能用在git add .後並且在git commit之前}

有下面的另一種方法，即不是回退，而是將commit後的檔案直接從commit中刪除掉，這樣就不用管是哪次的commit出了大檔案錯誤問題了。Git取消跟蹤某個檔案：git commit某個檔案後又不想跟蹤它了（比如取消已經commit的大檔案，不想push到遠端），可以通過下面的方法解決
$git rm --cached FILENAME
如果後面跟的是目錄就加上個 -r  就行,（這個操作不會刪除這個檔案）git rm -r --cached DIR_NAME
然後更新info/exclude或者.gitignore忽略掉目標檔案，不知道怎麼操作的可參見[Git版本控制教程 - Git本地倉庫：忽略指定檔案]
最後 git commit -m "dont track"     還是 git commit --amend -CHEAD ?成功之後會提示：...* file changed ...delete mode ... FILENAME檢查一下，git status，提示nothing commit...就說明成功刪除檔案的追蹤。如果顯示untracked file FILENAME，可能是ignore檔案出錯，解決參見[Git版本控制教程 - Git本地倉庫：忽略指定檔案]。當然如果你後悔了，從ignore檔案中刪除FILENAME，再直接git add .就可以了，然後git commit，可能會提示沒有什麼變化。

究極解決方案：本地重建並取代遠端

lz碰到一個很煩人的，git rm --cached bigfile並且ignore後，使用git diff檢視明明沒有大檔案，所有要提交的大檔案都是D（delete模式），難道delete的檔案也要上傳？還是之前add大檔案後再git rm cached後有兩個操作，add再delete，可是git diff裡面並沒有add大檔案，不知道為什麼總是有那個大檔案上傳，總是！用了無數方法總是有這個大檔案targetopinion/dist/TargetOpinionMain.exe：git diff檢視是沒有TargetOpinionMain.exe檔案add的，也是奇怪。ps：lz曾經將這個大檔案從nlp/dist移動到nlp/targetopinion/dist中，然後路徑中git rm --cached不能作用於dist，而可以作用於targetopinion/dist，但是怎麼說那個targetopinion/dist中的exe大檔案是沒有的！可是它總是有！搞了好久，lz只能採取下面的極限方法了：刪除本地nlp目錄下的.git資料夾重新設定本地git管理：git initgit remote add origin [email protected]:***git add .git commit -m 'init commit'git push -u --force origin 分支名這裡是強制提交，本來要git pull的，但是這樣可能覆蓋本地檔案，要是完全不想要遠端的檔案了，可以這樣，用本地取代遠端的檔案（結果導致遠端主機上更新的版本被覆蓋）。git push見[Git版本控制教程 - Git遠端倉庫:--force選項]

修改最後一次提交git commit --amend

{還有一種有條件但是更簡單快捷的解決方案：git commit --amend 修改上一次的提交資訊，這是最快最好的方法，不過如果不是針對上一次提交那就不好了！}有時候用 git commit -m 提交時，可能沒寫好或者誤操作導致提交的資訊不合適，但你還沒有 push 到遠端分支時，可以使用 git commit --amend 修改上一次的提交資訊。有時候我們提交完了才發現漏掉了幾個檔案沒有加，或者提交資訊寫錯了。想要撤消剛才的提交操作，可以使用 --amend 選項重新提交：
$ git commit --amend
此命令將使用當前的暫存區域快照提交。如果剛才提交完沒有作任何改動，直接執行此命令的話，相當於有機會重新編輯提交說明，但將要提交的檔案快照和之前的一樣。
啟動文字編輯器後，會看到上次提交時的說明，編輯它確認沒問題後儲存退出，就會使用新的提交說明覆蓋剛才失誤的提交。
如果剛才提交時忘了暫存某些修改，可以先補上暫存操作，然後再執行 --amend 提交：
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
上面的三條命令最終只是產生一個提交，第二個提交命令修正了第一個的提交內容。

git update-index

這種方法好像有問題，不推薦git update-index --assume-unchanged <PATH>