Git常用知識(shí)

  1. Git自動(dòng)補(bǔ)全
    假使你使用命令行工具運(yùn)行Git命令,那么每次手動(dòng)輸入各種命令是一件很令人厭煩的事情。為了解決這個(gè)問(wèn)題,你可以啟用Git的自動(dòng)補(bǔ)全功能,完成這項(xiàng)工作僅需要幾分鐘。為了得到這個(gè)腳本,在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.bashfi
    盡管早些時(shí)候我們已經(jīng)提到這個(gè),但是強(qiáng)調(diào)的不夠充分。如果你想使用git的全部功能特性,你絕對(duì)應(yīng)該切換到命令行界面!

  2. 在 Git 中忽略文件
    你是不是很煩那些編譯過(guò)的文件 (比如 .pyc) 出現(xiàn)在你的 Git 倉(cāng)庫(kù)中?或者說(shuō)你已經(jīng)受夠了已經(jīng)把它們都加進(jìn)了 Git 倉(cāng)庫(kù)?好了,這有個(gè)辦法可以讓你告訴 Git 忽略掉那些特定的文件和文件夾。只需要?jiǎng)?chuàng)建一個(gè)名為 .gitignore 然后列出那些你不希望 Git 跟蹤的文件和文件夾。你還可以添加例外,通過(guò)使用感嘆號(hào)(!)。
    .pyc.exemy_db_config/!main.pyc

  3. 是誰(shuí)弄亂了我的代碼?
    當(dāng)事情出錯(cuò)時(shí),先去指責(zé)別人是人類的天性之一。如果你的產(chǎn)品服務(wù)器掛了,使用git blame命令可以很容易找出罪魁禍?zhǔn)住_@個(gè)命令可以將文件中的每一行的作者、最新的變更提交和提交時(shí)間展示出來(lái)。
    git blame [file_name]


    git blame demonstration

    在下面的截圖中你可以看到命令是如何在更大的目錄中搜尋。


    git blame on the ATutor repository
  4. 查看倉(cāng)庫(kù)歷史記錄
    上一節(jié)我們已經(jīng)學(xué)習(xí)了如何使用 git log ,不過(guò),這里還有三個(gè)你應(yīng)該知道的選項(xiàng)。
    --oneline- 壓縮模式,在每個(gè)提交的旁邊顯示經(jīng)過(guò)精簡(jiǎn)的提交哈希碼和提交信息,以一行顯示。

--graph- 圖形模式,使用該選項(xiàng)會(huì)在輸出的左邊繪制一張基于文本格式的歷史信息表示圖。如果你查看的是單個(gè)分支的歷史記錄的話,該選項(xiàng)無(wú)效。

--all- 顯示所有分支的歷史記錄

把這些選項(xiàng)組合起來(lái)之后,輸出看起來(lái)會(huì)像這樣:


Use of git log with all, graph and oneline
  1. 絕對(duì)不要丟失對(duì)Commit的跟蹤
    假設(shè)你不小心提交了些你不想要的東西,不得不做一次強(qiáng)制重置來(lái)恢復(fù)到之前的狀態(tài)。然后,你意識(shí)到在這一過(guò)程中你丟失了其它一些信息并且想要把它們找回來(lái),或者至少瞅一眼。這正是git reflog可以做到的。
    一個(gè)簡(jiǎn)單的git log命令可以為你展示最后一次commit,以及它的父親,還有它父親的父親等等。而git reflog則列出了head曾經(jīng)指向過(guò)的一系列commit。要明白它們只存在于你本機(jī)中;而不是你的版本倉(cāng)庫(kù)的一部分,也不包含在push和merge操作中。
    如果我運(yùn)行g(shù)it log命令,我可以看到一些commit,它們都是我倉(cāng)庫(kù)的一部分:


    Project history

    然而,一個(gè)git reflog命令則展示了一次commit (b1b0ee9–HEAD@{4}),它正是我剛才進(jìn)行強(qiáng)制重置時(shí)弄丟的:


    Git reflog
  2. 暫存文件的部分改動(dòng)
    一般情況下,創(chuàng)建一個(gè)基于特性的提交是比較好的做法,意思是每次提交都必須代表一個(gè)新特性的產(chǎn)生或者是一個(gè)bug的修復(fù)。如果你修復(fù)了兩個(gè)bug,或是添加了多個(gè)新特性但是卻沒(méi)有提交這些變化會(huì)怎樣呢?在這種情況下,你可以把這些變化放在一次提交中。但更好的方法是把文件暫存(Stage)然后分別提交。
    例如你對(duì)一個(gè)文件進(jìn)行了多次修改并且想把他們分別提交。這種情況下,你可以在 add 命令中加上 -p 參數(shù)
    git add -p [file_name]
    我們來(lái)演示一下在 file_name 文件中添加了3行文字,但只想提交第一行和第三行。先看一下 git diff 顯示的結(jié)果:


    Changes in repo

    然后再看看在 add 命令中添加 -p 參數(shù)是怎樣的?


    Running add with -p

    看上去,Git 假定所有的改變都是針對(duì)同一件事情的,因此它把這些都放在了一個(gè)塊里。你有如下幾個(gè)選項(xiàng):
    輸入 y 來(lái)暫存該塊

輸入 n 不暫存

輸入 e 手工編輯該塊

輸入 d 退出或者轉(zhuǎn)到下一個(gè)文件

輸入 s 來(lái)分割該塊

在我們這個(gè)例子中,最終是希望分割成更小的部分,然后有選擇的添加或者忽略其中一部分。


Adding all hunks

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


Repository after selectively adding a file
  1. 壓縮多個(gè)Commit
    當(dāng)你提交代碼進(jìn)行代碼審查時(shí)或者創(chuàng)建一次pull request (這在開(kāi)源項(xiàng)目中經(jīng)常發(fā)生),你的代碼在被接受之前會(huì)被要求做一些變更。于是你進(jìn)行了變更,并且直到下一次審查之前你沒(méi)有再次被要求進(jìn)行變更過(guò)。在你知道又要進(jìn)行變更之前,你已經(jīng)有了一些額外的commit。理想情況下,你可以用rebase命令把多個(gè)commit壓縮成一個(gè)。
    git rebase -i HEAD~[number_of_commits]
    如果你想要壓縮最后兩個(gè)commit,你需要運(yùn)行下列命令。
    git rebase -i HEAD~2
    運(yùn)行該命令時(shí),你會(huì)看到一個(gè)交互界面,列出了許多commit讓你選擇哪些需要進(jìn)行壓縮。理想情況下,你選擇最后一次commit并把其它老commit都進(jìn)行壓縮。


    Git squash interactive

    然后會(huì)要求你為新的commit錄入提交信息。這一過(guò)程本質(zhì)上重寫(xiě)了你的commit歷史。


    Adding a commit message
  2. Stash未提交的更改
    你正在修改某個(gè)bug或者某個(gè)特性,又突然被要求展示你的工作。而你現(xiàn)在所做的工作還不足以提交,這個(gè)階段你還無(wú)法進(jìn)行展示(不能回到更改之前)。在這種情況下, git stash可以幫助你。stash在本質(zhì)上會(huì)取走所有的變更并存儲(chǔ)它們?yōu)橐詡鋵?lái)使用。stash你的變更,你只需簡(jiǎn)單地運(yùn)行下面的命令-
    git stash

希望檢查stash列表,你可以運(yùn)行下面的命令:
git stash list

Stash list

如果你想要解除stash并且恢復(fù)未提交的變更,你可以進(jìn)行apply stash:
git stash apply

在屏幕截圖中,你可以看到每個(gè)stash都有一個(gè)標(biāo)識(shí)符,一個(gè)唯一的號(hào)碼(盡管在這種情況下我們只有一個(gè)stash)。如果你只想留有余地進(jìn)行apply stash,你應(yīng)該給apply添加特定的標(biāo)識(shí)符:
git stash apply stash@{2}

After un-stashing changes

9.檢查丟失的提交
盡管 reflog 是唯一檢查丟失提交的方式。但它不是適應(yīng)用于大型的倉(cāng)庫(kù)。那就是 fsck(文件系統(tǒng)檢測(cè))命令登場(chǎng)的時(shí)候了。
git fsck --lost-found

Git fsck results

這里你可以看到丟掉的提交。你可以通過(guò)運(yùn)行 git show [commit_hash] 查看提交之后的改變或者運(yùn)行g(shù)it merge [commit_hash] 來(lái)恢復(fù)到之前的提交。
git fsck 相對(duì)reflog是有優(yōu)勢(shì)的。比方說(shuō)你刪除一個(gè)遠(yuǎn)程的分支然后關(guān)閉倉(cāng)庫(kù)。 用fsck 你可以搜索和恢復(fù)已刪除的遠(yuǎn)程分支。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • git常用命令 GIT常用命令備忘:http://stormzhang.com/git/2014/01/27/gi...
    新篇章閱讀 8,866評(píng)論 1 26
  • Add & Commit git init 初始化一個(gè) Git 倉(cāng)庫(kù)(repository),即把當(dāng)前所在目錄變成...
    冬絮閱讀 5,127評(píng)論 0 9
  • 今天的感覺(jué)就是累,昨晚一晚睡了很少一點(diǎn),身體的累還是次要的,主要是心里有事,睡得時(shí)候也很驚醒,生怕耽誤了什么...
    呂諾爸閱讀 125評(píng)論 0 3
  • 子時(shí)草就今日計(jì)劃,欲寢,值二騰之最新?tīng)顟B(tài),愧而有感,乃發(fā)此文。下文極度厚顏無(wú)恥。認(rèn)識(shí)我的速速離開(kāi)。有時(shí)候會(huì)追問(wèn)自己...
    李響同學(xué)閱讀 207評(píng)論 0 1
  • (一) 中國(guó)人做事,講究凡事有因有果,最愛(ài)在原因結(jié)果上做文章。 (二) 這世界上此刻有多少人在笑,就有多少人在哭,...
    吃貨某某某的小世界閱讀 371評(píng)論 0 5

友情鏈接更多精彩內(nèi)容