轉自:http://www.oschina.net/translate/10-tips-git-next-level
10 個迅速提升你 Git 水平的提示
英文原文:10 Tips to Push Your Git Skills to the Next Level
最近我們推出了兩個教程:熟悉Git的基本功能和讓你在開發團隊中熟練的使用Git . 我們所討論的命令足夠一個開發者在Git使用方面遊刃有餘。在這篇文章中,我們試圖探索怎樣有效的管理你的時間和充分的使用Git提供的功能。 注:本文中,一些命令包含了方括號中的部分內容(例如:git add -p [file_name]).在這些示例中,你將插入必要的數字、標示符等等,如果沒有方括號。 |
漠天
|
1. Git自動補全
假使你使用命令行工具運行Git命令,那麼每次手動輸入各種命令是一件很令人厭煩的事情。
然後,添加下面幾行到你的 ~/.bash_profile 文件中:
儘管早些時候我們已經提到這個,但是強調的不夠充分。如果你想使用git的全部功能特性, |
quentingui
|
2. 在 Git 中忽略文件
你是不是很煩那些編譯過的文件 (比如 .pyc) 出現在你的 Git 倉庫中?或者說你已經受夠了已經把它們都加進了 Git 倉庫?好了,這有個辦法可以讓你告訴 Git 忽略掉那些特定的文件和文件夾。只需要創建一個名爲 .gitignore 然後列出那些你不希望 Git 跟蹤的文件和文件夾。你還可以添加例外,通過使用感嘆號(!)。
|
開源中國匿名會員
|
||
其它翻譯版本(1) |
3. 是誰弄亂了我的代碼?當事情出錯時,先去指責別人是人類的天性之一。如果你的產品服務器掛了,使用git blame命令可以很容易找出罪魁禍首。這個命令可以將文件中的每一行的作者、最新的變更提交和提交時間展示出來。
在下面的截圖中你可以看到命令是如何在更大的目錄中搜尋。 |
0x0bject
|
4. 查看倉庫歷史記錄
上一節我們已經學習瞭如何使用 git log ,不過,這裏還有三個你應該知道的選項。
把這些選項組合起來之後,輸出看起來會像這樣: |
開源中國匿名會員
|
5. 絕對不要丟失對Commit的跟蹤
假設你不小心提交了些你不想要的東西,不得不做一次強制重置來恢復到之前的狀態。然後,你意識到在這一過程中你丟失了其它一些信息並且想要把它們找回來,或者至少瞅一眼。這正是git reflog可以做到的。 一個簡單的git log命令可以爲你展示最後一次commit,以及它的父親,還有它父親的父親等等。而git reflog則列出了head曾經指向過的一系列commit。要明白它們只存在於你本機中;而不是你的版本倉庫的一部分,也不包含在push和merge操作中。 如果我運行git log命令,我可以看到一些commit,它們都是我倉庫的一部分: 然而,一個git reflog命令則展示了一次commit (b1b0ee9–HEAD@{4}),它正是我剛纔進行強制重置時弄丟的: |
lwei
|
6. 暫存文件的部分改動
一般情況下,創建一個基於特性的提交是比較好的做法,意思是每次提交都必須代表一個新特性的產生或者是一個bug的修復。如果你修復了兩個bug,或是添加了多個新特性但是卻沒有提交這些變化會怎樣呢?在這種情況下,你可以把這些變化放在一次提交中。但更好的方法是把文件暫存(Stage)然後分別提交。 例如你對一個文件進行了多次修改並且想把他們分別提交。這種情況下,你可以在 add 命令中加上 -p 參數
我們來演示一下在 file_name 文件中添加了3行文字,但只想提交第一行和第三行。先看一下 git diff 顯示的結果: 然後再看看在 add 命令中添加 -p 參數是怎樣的? 看上去,Git 假定所有的改變都是針對同一件事情的,因此它把這些都放在了一個塊裏。你有如下幾個選項:
在我們這個例子中,最終是希望分割成更小的部分,然後有選擇的添加或者忽略其中一部分。 正如你所看到的,我們添加了第一行和第三行而忽略了第二行。之後你可以查看倉庫狀態之後並進行提交。 |
鑑客
|
7. 壓縮多個Commit
當你提交代碼進行代碼審查時或者創建一次pull request (這在開源項目中經常發生),你的代碼在被接受之前會被要求做一些變更。於是你進行了變更,並且直到下一次審查之前你沒有再次被要求進行變更過。在你知道又要進行變更之前,你已經有了一些額外的commit。理想情況下,你可以用rebase命令把多個commit壓縮成一個。
如果你想要壓縮最後兩個commit,你需要運行下列命令。
運行該命令時,你會看到一個交互界面,列出了許多commit讓你選擇哪些需要進行壓縮。理想情況下,你選擇最後一次commit並把其它老commit都進行壓縮。 然後會要求你爲新的commit錄入提交信息。這一過程本質上重寫了你的commit歷史。 |
lwei
|
8. Stash未提交的更改
你正在修改某個bug或者某個特性,又突然被要求展示你的工作。而你現在所做的工作還不足以提交,這個階段你還無法進行展示(不能回到更改之前)。在這種情況下, git stash可以幫助你。stash在本質上會取走所有的變更並存儲它們爲以備將來使用。stash你的變更,你只需簡單地運行下面的命令-
希望檢查stash列表,你可以運行下面的命令:
如果你想要解除stash並且恢復未提交的變更,你可以進行apply stash:
在屏幕截圖中,你可以看到每個stash都有一個標識符,一個唯一的號碼(儘管在這種情況下我們只有一個stash)。如果你只想留有餘地進行apply stash,你應該給apply添加特定的標識符:
|
無若
|
9.檢查丟失的提交儘管 reflog 是唯一檢查丟失提交的方式。但它不是適應用於大型的倉庫。那就是 fsck(文件系統檢測)命令登場的時候了。
這裏你可以看到丟掉的提交。你可以通過運行 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應用到的這個分支上去,然後運行了如下命令:
儘管我們這次完成了一次乾淨的cherry-pick,你也應該意識到這個命令可能會產生衝突。所以用它時請無比小心。 |
htfy96
|
總結
說着說着就到了文章的最後,我認爲這些技巧會讓你的 Git 水平提升到一個新的高度。Git 是最棒的,它幾乎能實現你所能想到的事情。因此,要經常挑戰自己的Git水平。最後你很有可能會學到新的東西。