已經會用Git了？不會這十招怎么行

在這篇教程里，我們試著探索如何高效地管理你的時間以及如何充分利用Git提供的特性。 

注意：這里介紹的命令中有的包含方括號(例如：git add -p [file_name])。在這些例子中，你應該用你自己的數字、標識符等替代方括號里的內容，并且去掉方括號。

1. Git自動補全

如果你在命令行環境中運行Git命令，每次都手動地逐個輸入命令是一件很無聊的事。為此，你可以花幾分鐘時間配置一下Git命令的自動補全功能。

在*nix系統運行下列命令下載自動補全腳本：

1. cd ~
2. curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash

然后，添加下面的行到你的~/.bash_profile文件：

1. if [ -f ~/.git-completion.bash ]; then
2.    . ~/.git-completion.bash
3. fi

盡管我之前已經提到過，但我還是想再強調一下：如果你想使用完整的Git特性，你絕bi應該切換到命令行環境。

2. 在Git中忽略文件

你 是不是對出現在你Git庫里面的編譯生成文件（比如.pyc)感到很無語？或者你是不是很厭惡不小心將他們添加到了Git？直接看這里，這里有一個方法可 以讓你告訴Git忽略所有這些文件和目錄。只需要創建一個名字為.gitignore的文件，里面列出你不想要Git跟蹤的文件和目錄。可以用感嘆號 (!)列出例外情況。

1. *.pyc
2. *.exe
3. my_db_config/
4. !main.pyc

3. 誰動了我的代碼？

當事情出了亂子時立馬責怪別人這是人類的天性。如果你的服務器程序不能正常工作了，要找出罪魁禍首是非常簡單的--只需要執行git blame。這個命令告訴你文件里的每一行的作者是誰，最后改動那一行的提交，以及提交的時間戳。

1. git blame [file_name]

在下面的截圖里，你可以看到在一個更大的庫里這個命令的輸出是什么樣的：

4. 查看庫的歷史

在之前的教程里，我們已經看過了如何使用git log命令。不管怎樣，有3個選項你應該知道。

• --oneline - 壓縮每次的提交信息，只保留一個縮減的Hash值和說明文字，然后把這些都展示在一行里。
• --graph - 這個選項將在左邊畫出一個文字界面的提交歷史圖。如果你只有一個分支，用這個選項查看歷史時是沒什么意義的。
• --all - 顯示所有分支歷史。

這是這3個選項合起來使用的效果：

5. 不要丟失對某個提交的跟蹤

假設你提交了一些不需要的東西，然后你進行了hard重置回到之前的狀態。后來，你發現在這個過程中你丟失了其他一些重要的信息，你想要把這些信息找回來，或者至少可以查看一下這些信息。這就需要git reflog幫忙。

簡單的git log只能告訴你最近的提交，這個提交的父提交，父提交的父提交，等等。但是git reflog是一個HEAD指向的提交的列表。記住，這個列表依賴于你自己的本地操作環境，它不是庫的一部分，也不包含在push或者merge中。

如果執行git log命令，可以看到提交歷史，這是我的庫的一部分：

但是，git reflog命令顯示了一個被我用hard重置丟掉的提交(b1b0ee9-HEAD@{4}).

6. 暫存文件的一部分更改以便進行一次提交

通 常依據特性來提交是一個好的實踐方法，意思是說，每一個提交都只添加一個特性或者修復一個bug。想一下如果你一次修復了兩個bug或者添加了兩個特性但 是都還沒有逐個提交該怎么辦。這種場景下，你可以將他們一起提交。但是有一個更好的辦法：單獨暫存這些文件，然后分開提交。

讓我們假設你對一個文件做了多個更改，然后想讓這些更改分開提交。這時，我們用帶-p的添加命令。

1. git add -p [file_name]

我們來試試這種用法。我添加了3個新行到file_name，但是我只想讓第1行和第3行出現在我的提交里。讓我們看看git diff的輸出是什么樣的。

然后，我們看看帶-p選項的add命令會發生什么。

看起來Git認為所有的更改都是同一個目的的一部分，所以把他們分組到同一個塊里。這時，你可以：

• 輸入 y 暫存塊
• 輸入 n 不暫存塊
• 輸入 e 手動編輯塊
• 輸入 d 退出或者跳轉到下一個文件
• 輸入 s 分割塊

在我們這個例子中，我們想把這個塊分割成更小的部分，然后選擇其中一些忽略另外一些。

如你所見，我們已經逐個添加了第1和第3行，忽略了第2行。你可以看到庫的狀態并且進行一次提交。

7. 合并多個提交

為 了進行核查或者發起一個合并請求（這經常發生在開源項目里），對代碼進行了修改提交。但在最后代碼被接受之前，你也許會需要修改你的代碼。于是你修改代 碼，但是下一次核查的時候又一次需要進行修改。不知不覺中，你就已經有了好幾個提交。理論上你應該用rebase命令把他們合并起來。

git rebase -i HEAD~[number_of_commits]

如果你想合并最后的兩次提交，你應該運行下面的命令。

git rebase -i HEAD~2

一旦你運行這個命令，你將進入一個交互式界面，它將詢問你想要合并哪些提交。你pick(揀選)最近的提交然后squash(合并)舊的提交。

接著你應該提供一個對新提交的說明。這個過程會重寫你的提交歷史。

8. 儲藏沒有提交的更改

假設你正在修復一個bug或者添加一個特性，突然你被要求展示一下你的工作成果。你現在的工作還沒有完成，不夠進行一次提交。這時，git stash命令可以用來急救一下。Stash命令跟蹤你所有的更改，然后把他們儲藏起來以便以后使用。命令如下-

git stash

可以多次儲藏更改，查看儲藏列表，你可以運行下面的命令：

git stash list

如果你想取消儲藏，覆蓋當前的更改，你可以通過下面的命令使用儲藏：

git stash apply

在最后的這個截圖里，你可以看到每個儲藏都有一個標識符，是一個唯一的數字（盡管在這里我們只有一個儲藏）。如果你想使用某個儲藏，你在apply命令后面加上這個唯一的標識符：

git stash apply stash@{2}

9. 檢查丟失的提交

盡管reflog是一種檢查丟失提交的方法，大型的庫里卻不太實用。這個時候，應該用fsck（文件系統檢查）命令。

git fsck --lost-found

這里你可以看到一個丟失的提交。你可以通過git show [commit_hash] 查看提交的更改或者通過運行git merge [commit_hash]命令進行恢復。

git fsck跟reflog命令相比有一個優點。假設你刪除了一個遠程分支，然后clone了這個庫。用fsck命令你可以找到并且恢復這個刪除的遠程分支。

10. 最佳選擇

之前我已經存記下了那些最優雅的Git命令。但是目前為止，cherry-pick命令是我最喜歡的Git命令，因為它直白的名字和實用的功能！

最 簡單的情況下，cherry-pick從另一個分支里選出單獨的一個提交，然后合并到當前分支。如果你正并行工作在兩個或者更多的分支上，你也許會發現一 個存在于所有分支上的bug。如果你解決了一個分支上的這個bug，你可以揀選這個對應的提交應用到其他分支上，而不會弄亂其他文件或者提交。

讓我們來考慮一個可以使用這個命令的場景。我有兩個分支，我想揀選b20fd14: Cleaned junk這個提交到另一個分支上。

我切換到想要應用這個揀選出來的提交的分支，然后運行下面的命令：

git cherry-pick [commit_hash]

盡管這次我們很干凈的用了cherry-pick命令，但你應該知道這個命令經常會引起沖突，所以請小心使用。

總結

到了這里，我們結束了這個能使你Git能力提升一個級別的列表。Git是最好的版本控制器，它能完成你能想象到的任何事情。所以，經常試著用Git挑戰你自己。一不小心你就會學到很多新東西。

本文轉載自：http://js.f2e.be/post/1bd671_1a065e2