清理遠程倉庫已刪除、本地仍存在的遠程分支。有時候遠程倉庫的某個分支已經(jīng)被刪除了，但是使用 git branch -r 查看時，該分支在我們本機上依然存在。這是因為我們執(zhí)行 git fetch 或者 git pull 命令時并不會同步清理這些遠程倉庫已刪除、本地仍存在的遠程分支。這時我們可以使用 git remote prune origin 或者 git fetch -p (即 --prune ，表示在 fetch 代碼之后刪除未跟蹤的遠程分支)進行清理。我比較喜歡用 git fetch -p ，既拉了代碼，又清理了沒用的遠程分支，一舉兩得！

消除 git pull 時產(chǎn)生的 Merge 消息。我們執(zhí)行 git pull 時，總是會產(chǎn)生一條無意義的 Merge 消息。如何消除這條 Merge 消息呢？熟悉 Git 的 猿類都知道執(zhí)行 rebase 是不會產(chǎn)生 Merge 消息的，所以還是這個思路，我們可以通過如下方式消除 git pull 時產(chǎn)生的 Merge 消息。
一、 每次執(zhí)行 git pull 時加上 --rebase 參數(shù)，即每次 pull 代碼時都執(zhí)行 git pull --rebase
二、先執(zhí)行 git config --global pull.rebase true (在一臺機器上只需要執(zhí)行一次)，然后執(zhí)行 git pull。推薦使用這種方式，省事！

查看修改過的文件名。git diff 會顯示當前工作區(qū)有哪些內(nèi)容發(fā)生了改動，如果只想查看有哪些文件名發(fā)生了修改，就可以使用 git diff --name-only 。你可能會問，git status 不也可以么？沒錯，但是 git status 還會顯示一些額外信息，比如 “Changes not staged for commit...”等，不方便與外部腳本進行交互。

應(yīng)用其他分支的 Commit 到當前分支。有時為了方便，我們可能在某個功能分支上修復了一個 bug ，后來才意識到應(yīng)該新開一個 bugfix 分支再去修改和 Commit 。新建 bugfix 分支后，我們不必手把手的將代碼再修改一遍，只需要使用 git cherry-pick your-bugfix-commit-hash 就可以將在功能分支上修改bug的代碼"應(yīng)用"過來，super cool!

查看某個文件的每一行是誰修改的。使用 git blame $filename 可以查看 $filename 的每一行是誰修改的，加上 -L 參數(shù)，例如 git blame -L start_line,end_line $filename 或者 git blame $filename -L start_line,end_line 還可以查看從 start_line 到 end_line 的這些行是誰修改的。

保存修改過但尚未提交的內(nèi)容。經(jīng)常會有這樣的時刻，正在開發(fā)某個功能，然后要去修復一個重要的bug，那已經(jīng)修改過的內(nèi)容怎么辦？先提交代碼，然后切分支去修復bug？這么做也可以！但是我們有更優(yōu)雅的方式，那就是使用 git stash。 git stash 會把修改過但未提交的內(nèi)容保存起來，然后我們就可以切分支去修改 bug 了。修改完bug之后，再切換到我們功能分支，輸入 git stash pop 就可以把之前修改過但尚未提交的內(nèi)容恢復回來。具體操作步驟如下：
1> git checkout feature-branch
2> 開發(fā)功能......
3> 被告知要修改 bug
4> git stash
5> git checkout hotfix
6> 修改 bug 并提交代碼
7> git checkout feature-branch
8> git stash pop

清理未跟蹤的文件。一個新需求，你剛剛創(chuàng)建了model、view、controller和spec的一些文件，然后產(chǎn)品經(jīng)理又告訴你這個需求不做了(想踹死他是不是？)，這時可以使用 git clean 命令可以刪除還未加入版本倉庫的文件。 git clean 默認情況下是不會刪目錄的，可以使用 git clean -f -d optional-dir-name-or-current-dir 連目錄一起刪除。git clean 的詳細參數(shù)參見： git help clean