讓你的Git水平更上一層樓的10個小貼士

作者：Shaumik Daityari 2014-08-18 14:54:54

最近，我們發(fā)表了關(guān)于Git基礎(chǔ)知識和在團(tuán)隊中使用Git的教程。我們之前討論的那些命令，已經(jīng)足夠讓幫助一個開發(fā)者在Git世界里生存了。本篇文章，我們將嘗試探索如何更有效的管理您的時間以及如何充分使用Git提供的各種功能。

注意：本文中，一些命令包含含有方括號的部分(e.g.git add -p [file_name]).在這些例子中，您要在該處插入所需的數(shù)字，標(biāo)示符等。而不需要保留方括號。

1.Git自動補(bǔ)全

如果你在命令行中使用Git命令，每次手動輸入命令是一件非常煩人的。為了解決這個問題，你可以很方便的開啟自動補(bǔ)全功能。

在Unix系統(tǒng)下，運(yùn)行以下指令來獲取腳本：

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提供的全部功能，你肯定是需要轉(zhuǎn)而使用命令行來操作的。

2.在Git中忽略文件

你是否對出現(xiàn)在你Git倉庫中的已編譯文件（比如.pyc）感到厭煩？

亦或是你已經(jīng)對把它們加入Git中這件事感到忍無可忍了？

眼下就有一個可以讓Git忽略特定文件或是目錄的方法。只需要簡單的創(chuàng)建一個.gitignore文件，然后列出你不想讓Git跟蹤的文件和目錄即可。你可以使用感嘆號(!)來指出例外的情況。

*.pyc  
*.exe  
my_db_config/  
!main.pyc

3.誰動了我的代碼？

出了問題后去責(zé)怪別人，是人類的天性。如果你的成品服務(wù)器出了問題，你可以非常輕松的把壞人揪出來——只需要使用git blame命令。

這個命令會顯示文件中每一行的作者，最后一次改動后進(jìn)行的提交(commit)以及該次提交的時間戳。。

git blame [file_name]

下圖中，你可以看到在一個大型倉庫中使用該命令是什么樣子的。

4.回顧倉庫歷史

在之前的教程中，我們了解了git log命令的用法，然而，它還有三個選項(xiàng)，你應(yīng)該了解。

--oneline——把每次提交間顯示的信息壓縮成縮減的hash值和提交信息，在一行顯示。
--graph——該選項(xiàng)會在輸出界面的左手邊用一種基于文本的圖形表示法來顯示歷史。
如果你只是瀏覽一個單獨(dú)分支的歷史，那么這個功能是沒有用的。
--all——顯示全部分支的歷史

這里是以上命令綜合使用的效果。

5.絕不丟失一個提交信息

比方說，你提交了一個你不想要提交的代碼，最后你通過使用硬重置(hard reset)使其回到了之前的狀態(tài)。稍后，你意識到，在這個過程中你丟失了一些其他的信息，并想要退回或是至少能看一眼。git reflog命令可以幫你做到這一點(diǎn)。

一個簡單的git log命令，顯示你最近的提交信息，以及上一次，再上一次的提交信息，以此類推。

而git reflog顯示的是所有head移動的信息。記住，它是在本地的，而不是你倉庫的一部分，不會包含在推送(push)和合并中(merge)。

如果我使用git log，我得到的提交信息是我的倉庫的一部分。

然而git reflog顯示了一個提交信息（b1b0ee9 – HEAD@{4}），這是我使用硬重置(hard reset)時丟失的那個。

6.暫存一個文件的部分改動

通常來講，創(chuàng)建一個基于特性的提交是一個良好的做法，就是說，每次提交都必須代表一個新特性的產(chǎn)生或者是一個bug的修復(fù)。考慮一下，如果你修復(fù)了兩個bug，或是添加了多個新特性但是卻沒有提交這些變化會怎樣呢？在這種情況下，你可以把這些變化放在一次提交中。但是還有一個更好的方法：把文件分別暫存(Stage)然后分別提交。

比如說，你對一個文件進(jìn)行了多次修改并且想把他們分別提交。這種情況下，你可以在添加命令(add)中加上-p選項(xiàng)

git add -p [file_name]

讓我們演示一下。我在file_name文件中添加了3行文字，而且我只想提交第一行和第三行。我們先看一下git diff顯示的結(jié)果。

然后，我們看一下，在添加命令(add)中加上-p選項(xiàng)后會發(fā)生什么。

看上去，Git假定所有的改變都是針對同一件事情的，因此它把這些都放在了一個塊里。你有如下幾個選項(xiàng)：

輸入y來緩存該塊
輸入n不緩存該塊
輸入e來人工編輯該塊
輸入d來退出或進(jìn)入下一個文件
輸入s來分割這個塊

對我們而言，我們肯定希望把它分成幾個部分，有選擇的添加一部分而忽略其他的。

正如你所看到的，我們添加了第一行和第三行而忽略了第二行。你可以在之后查看倉庫狀態(tài)并進(jìn)行提交。

7.合并多次提交

當(dāng)你提交你的代碼進(jìn)行審核并創(chuàng)建一個pull request時(在開源項(xiàng)目中常常發(fā)生這樣的情況)，你經(jīng)常會在代碼被采納前，要求修改一些代碼。你進(jìn)行了一些修改，而在下一次審核中，又會被要求進(jìn)行另外的修改。你不知道還有多少次修改等著你，在你知道以前，你進(jìn)行了多次額外的提交。理想的狀態(tài)是，你可以使用rebase命令，把他們都合并成一次提交。

git rebase -i HEAD~[number_of_commits]

如果你希望合并最后兩次提交，您需要以下命令

git rebase -i HEAD~2

使用該命令，你會進(jìn)入一個交互式的界面，顯示了最后兩次提交，并且詢問你要壓縮哪些。理想狀態(tài)是你pick最近的一次提交并把它和之前的提交squash。

接下來你會被要求為合并后的這次提交填寫描述信息。這一個過程實(shí)際上重寫了你的提交歷史。

8.保存尚未提交的改動

比方說你正在解決一個bug或是添加某個新功能，這時你突然被要求展示你的工作。你當(dāng)前的工作還沒有完成到進(jìn)行提交的地步，而且你在這個階段也沒辦法展示你的工作（如果不回退所有變化的話）。在這種情況下，git stash可以拯救你。stash命令本質(zhì)上是保存了你全部的改動以供將來使用。保存你的改動，你只需要運(yùn)行如下命令：

git stash

查看暫存列表，你可以運(yùn)行如下命令：

git stash list

如果你不想保存了或是想要恢復(fù)這些改動，你使用如下命令：

git stash apply

在最后一張截圖中，你可以看到，每一次保存都有一個標(biāo)示符，一個獨(dú)一無二的數(shù)字（盡管我們此處只有一次保存），萬一你只想使用某些保存，你需要在apply命令后指明標(biāo)示符。

git stash apply stash@{2}

9.檢查丟失的提交

盡管reflog是一種查看丟失提交的方法，但是它在大型倉庫中行不通。這時就該fsck(file system check)出場了。\

git fsck --lost-found

這里你可以看到丟失的提交，你可以使用git show [commit_hash]來查看這些提交所包含的改動或者是使用git merge [commit_hash]來恢復(fù)它。

git fsck比reglog有一個優(yōu)勢。比如你刪除了一個遠(yuǎn)端分支并且克隆了倉庫，使用fsck命令你可以搜索并恢復(fù)該遠(yuǎn)端分支。

10.cherry-pick命令

我把最優(yōu)雅的Git命令留在了最后。cherry-pick是我最愛的Git命令，因?yàn)樗拿志鸵馕吨墓δ埽?/p>

簡而言之，cherry-pick是指從不同的分支里選擇某次提交并且把它合并到當(dāng)前的分支來。如果你在并行的開發(fā)某兩個或多個分支，你可能會注意到有一個bug存在于所有的分支中。如果你在一個分支中解決了它，你可以使用cherry-pick來把這次提交合并進(jìn)其他的分支而不會搞亂其他的文件或是提交。

讓我們想象一個可以使用該命令的場景。我有兩個分支，并且我想要把b20fd14: Cleaned junk這次提交使用cherry-pick的方法放入到另一個分支。