20 條實用的 git 命令

時間 2019-11-08

標籤實用 git 命令欄目 Git 简体版

原文原文鏈接

我的總結出的一些實用的 git 命令，分享給你們。git

git config --global color.ui true

讓 git 命令默認使用彩色輸出。這條命令在 git 2 以後已經成爲默認配置，但若是你還在用比較老的版本（例如 CentOS 上的默認的 git 版本），建議把這項配置加上去。shell

git branch -av

顯示全部本地即遠程分支，並顯示最後提交的 Commit 信息。若是不加參數，則只會顯示全部本地分支的名字。app

git checkout -b <NAME> [<START POINT>]

建立，並切換到新分支。git branch <NAME> 只會建立分支而不會切換到新分支，能夠用它備份當前分支。工具

git tag -L <PATTERN>

列出全部符合條件的標籤。若是你的項目嚴格按照 Major.Minor.Update 做爲版本名稱，那麼這條命令就很是有用。它能夠直接列出來當前版本下有那些小的 bugfix 版本。固然若是你非要 grep 一下我也沒意見。ui

git diff -w

顯示未提交的更改，忽略空格。人們每每注重實際代碼的改變而不注重縮進的變化。若是某個文件有大量縮進改變，-w 這個參數就很是有用。code

git commit --amend

修補前一次提交。至關於撤銷前一次提交，作更改後從新提交。這也是一條很是實用的命令。當你發現前一次提交有一些小問題的時候（好比說漏提交了新建立的文件，或者有一些小的拼寫錯誤），能夠用這條命令修正前一次提交。它對 merge 提交友好，並且能夠用於修正前一次提交的 message 信息。須要注意的是：若是你已經推送了前一次提交，amend 以後須要強推，這一點須要注意。開發

git log --graph --oneline --no-merge

顯示當前倉庫的提交歷史。git log 你們都用過，但真正研究過 git log 後面參數的人可能就很少。git log 後面能夠接不少實用的參數，示例中的讓提交歷史以單行模式顯示、顯示提交歷史樹並刪除 merge 提交。rem

git log -p --follow --stat -- <PATH>

顯示某個文件的提交歷史。在 git 中，-- 後接文件路徑就表明對單個文件的操做。-p 能夠顯示具體修改的行，--follow 能夠跟蹤文件的移動和重命名，--stat 用於顯示添加、刪除行的數量。文檔

git config --global alias.xx "<COMMAND>"

給某 git 命令建立別名。對於一些比較長的命令，能夠建立別名。之後只須要 git xx 便可執行 COMMAND 這條命令字符串

git pull --rebase, --rebase 能夠簡寫爲 -r

使用 git rebase 代替 git merge 執行 pull 操做。git pull --rebase 能夠構造出很是整齊的提交歷史樹，強迫症的福利。git 的官方文檔一再提醒這是個危險操做，由於它會修改你的代碼提交歷史。git rebase 的本質是撤銷指定的提交，而後以指定的方式從新提交他們。git pull -r 就至關於首先撤銷沒有推送到遠端的 commit，將遠程代碼覆蓋到本地以後，從新提交全部以前撤銷的 commit。與 git merge 不一樣，當有衝突產生時，git rebase 不會爲你的 merge 操做生成一個新的提交。因此一旦 git pull --rebase 執行完畢就沒法撤銷。

git config --global pull.rebase true

默認使用 git rebase 代替 git merge 執行 pull 操做。git 提供了一系列配置 git pull --rebase 操做：branch.<BRANCH NAME>.rebase、branch.autosetuprebase。這條是最簡單的全局配置項。儘管配置了默認使用 rebase，你可使用 --merge 開關強制使用 git merge 執行 git pull。

git rebase -i

交互式變基操做。git 中最強大的修改提交歷史的操做，固然也是最危險的操做。它可讓你修改 commit 說明、讓幾個 commit 合併、交換 commit、刪除 commit，甚至在提交某 commit 前執行一段 shell 命令。很是有用、很是強大、同時也是極其危險的操做。強烈建議在執行 git rebase -i 以前先使用 git branch 備份當前分支。

git push <remote> [<commit>]:<branch>

推送指定的 commit 到遠程。有時候你某個工做作到一半，而後來了一個bug要修。固然最好的作法是基於最新的遠端分支新開一個分支，基於這個分支開發。可是若是你忘了新開分支，直接把代碼提交到了當前分支怎麼辦？在你須要 push 的分支以前又有別的不須要的 commit。這時就能夠先用 git rebase 交換 commit 的順序，而後推送單個提交。若是你寫了冒號可是不寫 commit 號，就會變成刪除某個遠端分支。這是徹底不一樣的並且可能有危險操做，須要注意。

git blame <PATH> [-L <M,N>]

逐行檢查某文件的提交人、提交時間和 commit 號。blame 的中文意思是追責，你們顧名思義，撕逼甩鍋時用。 -L 能夠指定要檢查的行號。

git stash [push] [-u]

貯存當前工做區的更改。常常有這樣的事情發生，當你正在進行項目中某一部分的工做，裏面的東西處於一個比較雜亂的狀態，而你想轉到其餘分支上進行一些工做。問題是你還不想提交這些代碼，這是就能夠用 git stash 命令將未提交的更改臨時保存到一個貯存項中。-u 表示將未加入版本管理的文件也保存（好比新建的一些文件）

git stash apply <INDEX>、git stash pop <INDEX>

將最後一次保存的（或指定的某個）貯存項應用至當前工做區。與前面的 git stash [push] 配套使用。 apply 與 pop 的區別是：pop 會在應用更改的同時把所應用的貯存項刪除，而 apply 不會。

git cherry-pick -x <COMMIT>..

摘取 某些提交。即把另外一個本地分支的 commit 應用到當前分支。若是咱們同時維護多個分支，這個操做就頗有用。好比說你在主幹 master 分支上修復了一個 bug，而後你想把這個修復應用到一箇舊版本的分支上，可是你又不想把其餘 master 分支的新功能拉進來，這時就能夠用 cherry-pick。-x：在提交記錄中添加一行 (cherry picked from commit <commit>)，讓兩個提交關聯起來。