Git常用命令備忘錄

增加刪除文件

添加指定文件到index

git add [file1] [file2] ... git add [dir] git add .

刪除workspace文件，并且將這次刪除放入index

git rm [file1] [file2] ...

停止追蹤指定文件，但該文件會保留在workspace

偶然把a(bǔ)pplication.log加到代碼庫里了，現(xiàn)在每次運(yùn)行應(yīng)用，git 都會報告在application.log里有未提交的修改。把 *.login 放到了 .gitignore 文件里，可文件還是在代碼庫里，怎么才能告訴 git “撤銷” 對這個文件的追蹤呢?

雖然.gitignore會阻止 git 追蹤文件的修改，甚至不關(guān)注文件是否存在，但這只是針對那些以前從來沒有追蹤過的文件。一旦有個文件被加入并提交了，git 就會持續(xù)關(guān)注該文件的改變。類似地，如果你利用git add -f來強(qiáng)制或覆蓋了.gitignore， git 還會持續(xù)追蹤改變的情況。之后你就不必用-f來添加這個文件了。

如果希望從 git 的追蹤對象中刪除那個本應(yīng)忽略的文件,git rm --cached會從追蹤對象中刪除它，但讓文件在磁盤上保持原封不動。因為現(xiàn)在它已經(jīng)被忽略了，你在git status里就不會再看見這個文件，也不會再偶然提交該文件的修改了。

git rm --cached [file]

改名文件，并且將這個改名放入index

git mv [file-original] [file-renamed]

代碼提交本地倉庫

提交index到Repository

git commit -m [message]

提交index中指定文件到Repository

git commit [file1] [file2] ... -m [message]

提交workspace自上次commit之后的變化，直接到Repository中

git commit -a

提交時顯示所有的diff信息

git commit -v

使用一次新的commit，替代上一次commit，如果代碼沒有任何變化，則用來改寫commit信息

在最后一條 commit 消息里有個筆誤，已經(jīng)執(zhí)行了git commit -m "Fxies bug #42"，但在git push之前你意識到消息應(yīng)該是 “Fixes bug #42″。

該命令會用一個新的 commit 更新并替換最近的 commit ，這個新的 commit 會把任何修改內(nèi)容和上一個 commit 的內(nèi)容結(jié)合起來。如果當(dāng)前沒有提出任何修改，這個操作就只會把上次的 commit 消息重寫一遍。

git commit --amend -m [message]

重做上一次的commit，并包括指定文件的變化

git commit --amend [file1] [file2] ...

更新代碼

git pull <遠(yuǎn)程主機(jī)> <遠(yuǎn)程分支>:<本地分支>

如果要取回origin主機(jī)的next分支，與本地的master分支合并，使用命令：git pull origin next:origin，如果遠(yuǎn)程分支是與當(dāng)前分支進(jìn)行合并，則冒號后的部分可以忽略，簡寫為git pull origin next，上面命令表示，取回origin/next分支，再與當(dāng)前分支合并。實(shí)質(zhì)上，這等同于先做git fetch，再執(zhí)行g(shù)it merge。

git fetch origin git merge origin/next

在某些場合，Git會自動在本地分支與遠(yuǎn)程分支之間，建立一種追蹤關(guān)系(tracking)。比如，在git clone的時候，所有本地分支默認(rèn)與遠(yuǎn)程主機(jī)的同名分支，建立追蹤關(guān)系，也就是說，本地的master分支自動”追蹤”origin/master分支。

Git也允許手動建立追蹤關(guān)系。

git branch --set-upstream master origin/next

上面命令指定master分支追蹤origin/next分支。

如果當(dāng)前分支與遠(yuǎn)程分支存在追蹤關(guān)系，git pull就可以省略遠(yuǎn)程分支名。

git pull origin

上面命令表示，本地的當(dāng)前分支自動與對應(yīng)的origin主機(jī)”追蹤分支”(remote-tracking branch)進(jìn)行合并。

如果當(dāng)前分支只有一個追蹤分支，連遠(yuǎn)程主機(jī)名都可以省略。

git pull

上面命令表示，當(dāng)前分支自動與唯一一個追蹤分支進(jìn)行合并。

代碼提交遠(yuǎn)程倉庫

git push命令用于將本地分支的更新，推送到遠(yuǎn)程主機(jī)。它的格式與git pull命令相似。

git push <遠(yuǎn)程主機(jī)> <本地分支>:<遠(yuǎn)程分支>

git push origin master命令表示，將本地的master分支推送到origin主機(jī)的master分支。如果master不存在，則會被新建。

如果省略本地分支名，則表示刪除指定的遠(yuǎn)程分支，因為這等同于推送一個空的本地分支到遠(yuǎn)程分支。

git push origin :master # 等同于 git push origin --delete master

如果當(dāng)前分支與遠(yuǎn)程分支之間存在追蹤關(guān)系，則本地分支和遠(yuǎn)程分支都可以省略，使用git push origin。前面命令表示，將當(dāng)前分支推送到origin主機(jī)的對應(yīng)分支。如果當(dāng)前分支只有一個追蹤分支，那么主機(jī)名都可以省略，直接使用git push。

如果當(dāng)前分支與多個主機(jī)存在追蹤關(guān)系，則可以使用-u選項指定一個默認(rèn)主機(jī)，這樣后面就可以不加任何參數(shù)使用git push，git push -u origin master。前面命令將本地的master分支推送到origin主機(jī)，同時指定origin為默認(rèn)主機(jī)，后面就可以不加任何參數(shù)使用git push了。

不帶任何參數(shù)的git push，默認(rèn)只推送當(dāng)前分支，這叫做simple方式。此外，還有一種matching方式，會推送所有有對應(yīng)的遠(yuǎn)程分支的本地分支。Git 2.0版本之前，默認(rèn)采用matching方法，現(xiàn)在改為默認(rèn)采用simple方式。如果要修改這個設(shè)置，可以采用git config命令。

git config --global push.default matching # 或者 $ git config --global push.default simple

還有一種情況，就是不管是否存在對應(yīng)的遠(yuǎn)程分支，將本地的所有分支都推送到遠(yuǎn)程主機(jī)，這時需要使用–all選項，git push --all origin。前面命令表示，將所有本地分支都推送到origin主機(jī)。

如果遠(yuǎn)程主機(jī)的版本比本地版本更新，推送時Git會報錯，要求先在本地做git pull合并差異，然后再推送到遠(yuǎn)程主機(jī)。這時，如果你一定要推送，可以使用–force選項。

git push --force origin

上面命令使用-–force選項，結(jié)果導(dǎo)致在遠(yuǎn)程主機(jī)產(chǎn)生一個”非直進(jìn)式”的合并(non-fast-forward merge)，應(yīng)該盡量避免使用–-force選項。

其他示例：

1.推送本地分支lbranch-1到新的遠(yuǎn)程分支rbranch-1： git push origin lbranch-1:refs/rbranch-1 2.推送lbranch-2到已有的rbranch-1，用于補(bǔ)充rbranch-1： git checkout lbranch-2 git rebase rbranch-1 git push origin lbranch-2:refs/rbranch-1 3.用本地分支lbranch-2覆蓋遠(yuǎn)程分支rbranch-1： git push -f origin lbranch-2:refs/rbranch-1 # 或者 git push origin :refs/rbranch-1 //刪除遠(yuǎn)程的rbranch-1分支 git push origin lbranch-2:refs/rbranch-1 4.推送tag git push origin tag_name 5.刪除遠(yuǎn)程標(biāo)簽 git push origin :tag_name

查看信息

顯示有變更的文件

git status

顯示當(dāng)前分支的版本歷史

git log

顯示commit歷史，以及每次commit發(fā)生變更的文件

git log --stat

顯示某個文件的版本歷史，包括文件改名

git log --follow [file] git whatchanged [file]

顯示指定文件相關(guān)的每一次diff

git log -p [file]

顯示指定文件是什么人在什么時間修改過

git blame [file]

顯示暫存區(qū)和工作區(qū)的差異

git diff

顯示暫存區(qū)和上一個commit的差異

git diff --cached [file]

顯示工作區(qū)與當(dāng)前分支最新commit之間的差異

git diff HEAD

顯示兩次提交之間的差異

git diff [first-branch]...[second-branch]

顯示某次提交的元數(shù)據(jù)和內(nèi)容變化

git show [commit]

顯示某次提交發(fā)生變化的文件

git show --name-only [commit]

顯示某次提交時，某個文件的內(nèi)容

git show [commit]:[filename]

顯示當(dāng)前分支的最近幾次提交

提交了幾個 commit，然后用git reset --hard撤銷了這些修改，接著你又意識到：你希望還原這些修改。

git reflog 對于恢復(fù)項目歷史是一個超棒的資源。可以恢復(fù)幾乎任何東西，任何你 commit 過的東西，只要通過 reflog

可能已經(jīng)熟悉了git log命令，它會顯示 commit 的列表。git reflog也是類似的，不過它顯示的是一個 HEAD 發(fā)生改變的時間列表.

一些注意事項：

它涉及的只是 HEAD 的改變。在你切換分支、用git commit進(jìn)行提交、以及用git reset撤銷 commit 時，HEAD 會改變，但當(dāng)你用git checkout -- 撤銷時（正如我們在前面講到的情況），HEAD 并不會改變 — 如前所述，這些修改從來沒有被提交過，因此 reflog 也無法幫助我們恢復(fù)它們。

git reflog不會永遠(yuǎn)保持。git 會定期清理那些 “用不到的” 對象。不要指望幾個月前的提交還一直躺在那里。

你的 reflog 就是你的，只是你的。你不能用git reflog來恢復(fù)另一個開發(fā)者沒有 push 過的 commit。

那么怎么利用 reflog 來“恢復(fù)”之前“撤銷”的 commit 呢？它取決于你想做到的到底是什么：

如果你希望準(zhǔn)確地恢復(fù)項目的歷史到某個時間點(diǎn)，用git reset --hard [SHA]

如果你希望重建工作目錄里的一個或多個文件，讓它們恢復(fù)到某個時間點(diǎn)的狀態(tài)，用git checkout [SHA] --[filename]

如果你希望把這些 commit 里的某一個重新提交到你的代碼庫里，用git cherry-pick [SHA]

git reflog

撤銷

恢復(fù)index的指定文件到workspace

一只貓從鍵盤上走過，無意中保存了修改，然后破壞了編輯器。不過，你還沒有 commit 這些修改。你想要恢復(fù)被修改文件里的所有內(nèi)容，就像上次 commit 的時候一模一樣

git checkout會把工作目錄里的文件修改到 git 之前記錄的某個狀態(tài)。你可以提供一個你想返回的分支名或特定 SHA ，或者在缺省情況下，git 會認(rèn)為你希望 checkout 的是 HEAD，當(dāng)前 checkout 分支的最后一次 commit

用這種方法“撤銷”的任何修改真的會完全消失。因為它們從來沒有被提交過，所以之后 git 也無法幫助我們恢復(fù)它們。要確保自己了解你在這個操作里扔掉的東西是什么！（也許可以先利用git diff確認(rèn)一下）

git checkout [file]

恢復(fù)某個commit的指定文件到workspace

git checkout [commit] [file]

恢復(fù)上一個commit的所有文件到workspace

git checkout .

重置index的指定文件，與上一次的commit保持一致，但workspace不變

在本地提交了一些東西（還沒有 push ），但是所有這些東西都很糟糕，你希望撤銷前面的三次提交，就像它們從來沒有發(fā)生過一樣。

git reset會把你的代碼庫歷史返回到指定的 SHA 狀態(tài)。這樣就像是這些提交從來沒有發(fā)生過。缺省情況下，git reset會保留工作目錄。這樣，提交是沒有了，但是修改內(nèi)容還在磁盤上。這是一種安全的選擇，但通常我們會希望一步就“撤銷”提交以及修改內(nèi)容，這就是 --hard 選項的功能。

git reset [file]

重置index與workspace，與上一次commit保持一致

git reset --hard

重置當(dāng)前分支的指針為指定commit，同時重置index，但workspace不變

git reset [commit]

重置當(dāng)前分支的HEAD為指定commit，同時重置index和workspace，與指定commit一致

git reset --hard [commit]

重置當(dāng)前HEAD為指定commit，但保持index和workspace不變

git reset --keep [commit]

新建一個commit，用來撤銷指定commit，后者的所有變化都將被前者抵消，并且應(yīng)用到當(dāng)前分支

已經(jīng)執(zhí)行了git push，將修改發(fā)送到了 github ，意識到某個 commit 是有問題的，需要撤銷那一個 commit 。

該操作會產(chǎn)生一個新的 commit ，和指定的 SHA 對應(yīng)的 commit 是相反的（或者是說是反轉(zhuǎn)的）。如果原先的 commit 是“物質(zhì)”，新的commit就是“反物質(zhì)”。任何從原先的 commit 里刪除的內(nèi)容會在新的 commit里被加回去，任何在原先的 commit 里加入的內(nèi)容會在新的 commit 里被刪除。

這是 git 最安全、最基本的撤銷場景，因為其不會改變歷史。

git revert [commit]

參考資料：

廖雪峰的官方網(wǎng)站

易百Git教程

Git

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。