10 個迅速提升你 Git 水平的提示
最近我們推出了兩個教程：熟悉Git的基本功能和讓你在開發團隊中熟練的使用Git . 我們所討論的命令足夠一個開發者在Git使用方面游刃有余。在這篇文章中，我們試圖探索怎樣有效的管理你的時間和充分的使用Git提供的功能。
注：本文中，一些命令包含了方括號中的部分內容（例如:git add -p [file_name]）.在這些示例中，你將插入必要的數字、標示符等等，如果沒有方括號。
1. Git自動補全
假使你使用命令行工具運行Git命令，那么每次手動輸入各種命令是一件很令人厭煩的事情。
為了解決這個問題，你可以啟用Git的自動補全功能，完成這項工作僅需要幾分鐘。
為了得到這個腳本，在Unix系統下運行以下命令：
cd ~ curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash
然后，添加下面幾行到你的 ~/.bash_profile 文件中：
if [ -f ~/.git-completion.bash ]; then . ~/.git-completion.bash fi
盡管早些時候我們已經提到這個，但是強調的不夠充分。如果你想使用git的全部功能特性，
你絕對應該切換到命令行界面！
2. 在 Git 中忽略文件
你是不是很煩那些編譯過的文件 (比如 .pyc) 出現在你的 Git 倉庫中？或者說你已經受夠了已經把它們都加進了 Git 倉庫？好了，這有個辦法可以讓你告訴 Git 忽略掉那些特定的文件和文件夾。只需要創建一個名為 .gitignore 然后列出那些你不希望 Git 跟蹤的文件和文件夾。你還可以添加例外，通過使用感嘆號(!)。
.pyc.exe my_db_config/!main.pyc</pre>
3. 是誰弄亂了我的代碼？
當事情出錯時，先去指責別人是人類的天性之一。如果你的產品服務器掛了，使用git blame命令可以很容易找出罪魁禍首。這個命令可以將文件中的每一行的作者、最新的變更提交和提交時間展示出來。
git blame [file_name]
在下面的截圖中你可以看到命令是如何在更大的目錄中搜尋。
4. 查看倉庫歷史記錄
上一節我們已經學習了如何使用 git log ，不過，這里還有三個你應該知道的選項。
--oneline- 壓縮模式，在每個提交的旁邊顯示經過精簡的提交哈希碼和提交信息，以一行顯示。
--graph- 圖形模式，使用該選項會在輸出的左邊繪制一張基于文本格式的歷史信息表示圖。如果你查看的是單個分支的歷史記錄的話，該選項無效。
--all- 顯示所有分支的歷史記錄
把這些選項組合起來之后，輸出看起來會像這樣：
5. 絕對不要丟失對Commit的跟蹤
假設你不小心提交了些你不想要的東西，不得不做一次強制重置來恢復到之前的狀態。然后，你意識到在這一過程中你丟失了其它一些信息并且想要把它們找回來，或者至少瞅一眼。這正是git reflog可以做到的。
一個簡單的git log命令可以為你展示最后一次commit，以及它的父親，還有它父親的父親等等。而git reflog則列出了head曾經指向過的一系列commit。要明白它們只存在于你本機中；而不是你的版本倉庫的一部分，也不包含在push和merge操作中。
如果我運行git log命令，我可以看到一些commit，它們都是我倉庫的一部分：
然而，一個git reflog命令則展示了一次commit (b1b0ee9–HEAD@{4})，它正是我剛才進行強制重置時弄丟的：
6. Staging Parts of a Changed File for a Commit
It is generally a good practice to make feature-based commits, that is, each commit must represent a feature or a bug fix. Consider what would happen if you fixed two bugs, or added multiple features without committing the changes. In such a situation situation, you could put the changes in a single commit. But there is a better way: Stage the files individually and commit them separately.
Let’s say you’ve made multiple changes to a single file and want them to appear in separate commits. In that case, we add files by prefixing -p to our add commands.
git add -p [file_name]
Let’s try to demonstrate the same. I have added three new lines to file_name and I want only the first and third lines to appear in my commit. Let’s see what a git diff shows us.
And let’s see what happes when we prefix a -p to our add command.
It seems that Git assumed that all the changes were a part of the same idea, thereby grouping it into a single hunk. You have the following options:
Enter y to stage that hunk
Enter n to not stage that hunk
Enter e to manually edit the hunk
Enter d to exit or go to the next file.
Enter s to split the hunk.
In our case, we definitely want to split it into smaller parts to selectively add some and ignore the rest.
As you can see, we have added the first and third lines and ignored the second. You can then view the status of the repository and make a commit.
7. 壓縮多個Commit
當你提交代碼進行代碼審查時或者創建一次pull request (這才開源項目中經常發生)，你的代碼在被接受之前會被要求, 做一些變更。于是你進行了變更，并且直到下一次審查之前你沒有被要求進行過變更。在你直到又要進行變更之前，你已經有了一些額外的commit。理想情況下，你可以用rebase命令把多個commit壓縮成一個。
git rebase -i HEAD~[number_of_commits]
如果你想要壓縮最后兩個commit，你需要運行下列命令。
git rebase -i HEAD~2
運行該命令時，你會看到一個交互界面，列出了許多commit讓你選擇哪些需要進行壓縮。理想情況下，你選擇最后一次commit并把其它老commit都進行壓縮。
然后會要求你為新的commit錄入提交信息。這一過程本質上重寫了你的commit歷史。
8. Stash未提交的更改
你正在修改某個bug或者某個特性，又突然被要求展示你的工作。而你現在所做的工作還不足以提交，這個階段你還無法進行展示（不能回到更改之前）。在這種情況下， git stash可以幫助你。stash在本質上會取走所有的變更并存儲它們為以備將來使用。stash你的變更，你只需簡單地運行下面的命令-
git stash
希望檢查stash列表，你可以運行下面的命令：
git stash list
如果你想要解除stash并且恢復未提交的變更，你可以進行apply stash:
git stash apply
在屏幕截圖中，你可以看到每個stash都有一個標識符，一個唯一的號碼（盡管在這種情況下我們只有一個stash）。如果你只想留有余地進行apply stash，你應該給apply添加特定的標識符：
git stash apply stash@{2}
9.檢查丟失的提交
盡管 reflog 是唯一檢查丟失提交的方式。但它不是適應用于大型的倉庫。那就是 fsck（文件系統檢測）命令登場的時候了。
git fsck --lost-found
這里你可以看到丟掉的提交。你可以通過運行 git show [commit_hash] 查看提交之后的改變或者運行git merge [commit_hash] 來恢復到之前的提交。
git fsck 相對reflog是有優勢的。比方說你刪除一個遠程的分支然后關閉倉庫。 用fsck 你可以搜索和恢復已刪除的遠程分支。
10. Cherry Pick
我把最優雅的Git命令留到了最后。cherry-pick命令是我目前為止最喜歡的git命令，既是因為它的字面意思，也因為它的功能。
簡而言之，cherry-pick就是從不同的分支中撿出一個單獨的commit，并把它和你當前的分支合并。如果你以并行方式在處理兩個或以上分支，你可能會發現一個在全部分支中都有的bug。如果你在一個分支中解決了它，你可以使用cherry-pick命令把它commit到其它分支上去，而不會弄亂其他的文件或commit。
讓我們來設想一個用得著它的場景。我現在有兩個分支，并且我想cherry-pick b20fd14: Cleaned junk 這個commit到另一個上面去。
我切換到想被cherry-pick應用到的這個分支上去，然后運行了如下命令：
git cherry-pick [commit_hash]
盡管我們這次完成了一次干凈的cherry-pick，你也應該意識到這個命令可能會產生沖突。所以用它時請無比小心。
總結
說著說著就到了文章的最后，我認為這些技巧會讓你的 Git 水平提升到一個新的高度。Git 是最棒的，它幾乎能實現你所能想到的事情。因此，要經常挑戰自己的Git水平。最后你很有可能會學到新的東西。