持續(xù)集成相關(guān)-git魔法

前 致謝 入 工作是 版本控 分布控 一個(gè)誤 合并....................................................................................................................................基本技 保存狀 撤 文 快速發(fā) 練 克隆周 封閉源 倉(cāng) 推還是 項(xiàng)目分 終極備 分支巫 快速修 合 重組雜 管理分 臨時(shí)分 關(guān)于歷 我認(rèn) 重寫(xiě)歷 制造歷 Git個(gè)人經(jīng) 多人 我是誰(shuí) Git在SSH,HTTP 遠(yuǎn)端分 多遠(yuǎn) 我的喜 源碼發(fā) 提交變 揭開(kāi)面 大象無(wú) 智 索 沒(méi)那么 附錄A:Git的缺 SHA1的弱 微軟 文件歷 初始克 空 初始提 接口怪 附錄B:本指南的翻 前Git[ ]堪稱(chēng)版本控制 簡(jiǎn)體中文[/~blynn/gi intl/zh_tw/]由+cconv-f -tUTF8-TW+轉(zhuǎn)換。~blynn/gitmagic/intl/deBenjaminBellee和ArminStebichArmin的 Rodrigues[ODT版 /]: 他的[http://純 [

紙質(zhì)書(shū) [ 致謝DustinSallings、AlbertoBertogli、JamesCameron、DouglasLivingstone、MichaelBudde、RichardAlbury、Tarmigan、DerekMahar、FrodeAannevik、KeithRarick、AndySomervilleRalfRecker?yvindAHolmMiklosVajnaSébastienHinderer、ThomasMiedema、JoeMalin、和TylerBreisacher對(duì)本文檔正確性和優(yōu)化做出了貢獻(xiàn)。Fran?oisMarierDebian包，該Debian包起初由DanielBaumann創(chuàng)建。 為自由項(xiàng)目提供服務(wù)。第一個(gè)GitGit開(kāi)發(fā)人員創(chuàng)建和維本指南在GNU通用公共協(xié)議版本3[]之下發(fā) $git $gitclone第1我將用類(lèi)比方式來(lái)介紹版本控制的概念。更嚴(yán)謹(jǐn)?shù)慕忉寘⒁?jiàn)百科版本修訂控制條目[http://工作我從小就玩電腦游戲。相反，在長(zhǎng)大后才開(kāi)始使用版本控制系統(tǒng)。我并不特殊，并編寫(xiě)代碼，或編輯文檔和玩游戲差不多。在你做出了很多進(jìn)展之后，你最好保存一下。去做這但這將覆蓋老版本。就像那些學(xué)校里玩的老游戲，只有一個(gè)存檔：你確實(shí)可以保存，但你不能回到更老的狀態(tài)了。這真讓人掃興，因?yàn)槟莻€(gè)狀態(tài)可能恰好保存了這個(gè)游戲特別有意思一關(guān)，說(shuō)不定哪天你想再玩一下呢。或者更糟糕的，你當(dāng)前的保存是個(gè)必?cái)【郑@樣你就不得不從頭版本在編輯的時(shí)候，如果想保留舊版本，你可以將文件“另存為”一個(gè)不同的文件，或在保存之前將文件拷貝到別處。你可能壓縮這些文件以節(jié)省空間。這是一個(gè)初級(jí)的靠手工的版本控制方讓我們看看稍稍復(fù)雜的情況。比如你有很多放在一起的文件，比如項(xiàng)目源碼，或文件?，F(xiàn)在如你想保留舊版本，你不得不把整個(gè)存檔。手工保存多個(gè)版本很不方便，而且很快會(huì)耗在一些電腦游戲里，一個(gè)存檔真的包含在一個(gè)充滿(mǎn)文件的里。這些游戲?yàn)橥婕伊诉@些細(xì)節(jié)，并提供一個(gè)方便易用的界面來(lái)管理該的不同版本。版本控制系統(tǒng)也沒(méi)有兩樣。兩者提供友好的界面，來(lái)管理里的東西。你可以頻繁保存，也可以之后加載任一保存。不像大多計(jì)算機(jī)游戲，版本控制系統(tǒng)通常精于節(jié)省空間。一般情況如果兩個(gè)版本間數(shù)文件的變更，每個(gè)文件的變更也不大，那就只差異的部分，而分布現(xiàn)在設(shè)想一個(gè)很難的游戲。太難打了，以至于世界各地很多骨灰級(jí)玩家決定組隊(duì)，他們游戲存檔以攻克它。Speedrun在過(guò)去，每個(gè)項(xiàng)目都使用中心式版本控制。某個(gè)服務(wù)器上放所有保存的游戲記錄。其他人就不用了。每個(gè)玩家在他們機(jī)器上最多保留幾個(gè)游戲記錄。當(dāng)一個(gè)玩家想更新進(jìn)度時(shí)候，他們需要把進(jìn)度從主服務(wù)器下來(lái)，玩一會(huì)兒，保存并上載到主服務(wù)器以供其他人使用。假如一個(gè)玩家由于某種原因，想得到一個(gè)較舊版本的游戲進(jìn)度怎么樣？或許當(dāng)前保存的游戲是一個(gè)注定的敗局，因?yàn)樵诘谌?jí)忘記撿某個(gè)物品；他們希望能找到最近一個(gè)可以完成的游戲記錄。或者他們想比較兩個(gè)舊版本間的差異，來(lái)估算某個(gè)特定玩家干了多少活。查看舊版本的理由有很多，但檢查的辦法都是一樣的。他們必須去問(wèn)中心服務(wù)器要那個(gè)舊版本新一代的版本控制系統(tǒng)，Git就是其中之一，是分布式的，可以被認(rèn)作廣義上的中心式系統(tǒng)。從主服務(wù)器時(shí)玩家會(huì)得到所有保存的記錄，而不僅是版。這看起來(lái)他們好像把中心服務(wù)最初的克隆操作可能比較費(fèi)時(shí)，特別當(dāng)有很長(zhǎng)歷史的時(shí)，但從長(zhǎng)遠(yuǎn)看這是值得的。一個(gè)顯而易一個(gè)一個(gè)很常見(jiàn)的錯(cuò)誤觀念是，分布式系統(tǒng)不適合需要中心倉(cāng)庫(kù)的項(xiàng)目。這與事實(shí)并不相符。一般來(lái)說(shuō)，一個(gè)中心版本控制系統(tǒng)能做的任何事，一個(gè)良好設(shè)計(jì)的分布式系統(tǒng)都能做得更好。網(wǎng)絡(luò)資源總要比本地資源耗費(fèi)更費(fèi)。不過(guò)我們應(yīng)該在稍后分析分布式方案的缺點(diǎn)，這樣人們才一個(gè)小項(xiàng)目或許只需要分布式系統(tǒng)提供的一小部分功能，但是，在項(xiàng)目很小的時(shí)候，應(yīng)該用規(guī)而且，你的項(xiàng)目的增長(zhǎng)可能會(huì)超出你最初的預(yù)期。從一開(kāi)始就使用Git好似帶著一把，盡管你很多時(shí)候只是用它來(lái)開(kāi)開(kāi)瓶蓋。某天你迫切需要一把改錐，你就會(huì)慶幸你所有的不單單合并假設(shè)Alice在文檔開(kāi)頭插入一行，并且Bob在文檔末尾添加一行。他們都上傳了他們的改動(dòng)。大多數(shù)系統(tǒng)將自動(dòng)給出一個(gè)合理的處理方式：接受且合并他們的改動(dòng)，這樣Alice和Bob兩人的改現(xiàn)在假設(shè)Alice和Bob對(duì)文件的同一行做了不同的改動(dòng)。如果沒(méi)有人工參與的話(huà)，這個(gè)沖突是無(wú)法解決的。第二個(gè)人在上載文件時(shí)，會(huì)收到合并，要么用一個(gè)人的改動(dòng)覆蓋另一個(gè)更復(fù)雜的情況也可能出現(xiàn)。版本控制系統(tǒng)自己處理相對(duì)簡(jiǎn)單的情況，把的情況留給人來(lái)處第2本技與其一頭扎進(jìn)Git保存 $git$gitadd$gitcommit-m"Myfirst$gitcommit-a-m"Another添加、刪除 你第一次運(yùn)行g(shù)itadd命令時(shí)就已經(jīng)存在的文件。如果要添加新文件或子目$gitadd $gitrmkludge.h$gitrm-rgitmvmv$gitmvbug.c進(jìn)階撤銷(xiāo)/重$gitcommit766f Author:Bob< Date:TueMar1401:59:262000-commit82f5ea346a2e Author:Alice< Date:ThuJan100:00:00Initial$gitreset--hard$gitcheckout 里時(shí)光旅行一樣，如果你這時(shí)編輯并提交的話(huà)，你將身處另一個(gè)現(xiàn)實(shí)里，因?yàn)槟愕膭?dòng)作與開(kāi)始時(shí)相比是不同的。$gitcheckout --gitcheckout態(tài)。你現(xiàn)在打的所有游戲記錄會(huì)在你剛進(jìn)入的、代表另一個(gè)真實(shí)的分支里。我們稍后論述。 $gitcheckout82f5some.file，這種形式的checkout會(huì)不聲不響地覆蓋文件。為意外發(fā)生，在運(yùn)行任何checkout命令之前做提交，尤其在初學(xué)Git的時(shí)候。通常，任何時(shí)候你覺(jué)得對(duì)運(yùn)行某個(gè)命令不放心，無(wú)論Git命令還是不是Git命令，就先運(yùn)行一下gitcommit-a。$gitcheckout:/"Myfirst$gitcheckout撤$gitcommit-$gitrevert講撤銷(xiāo)給定哈希值的提交。本撤銷(xiāo)被記錄為一個(gè)新的提交，你可以通過(guò)運(yùn)行g(shù)itlog來(lái)確認(rèn)這一變更一些項(xiàng)目要求生成變更日志changelog[].生成一$gitlog>文$gitcloneclone到$git快速假設(shè)你寫(xiě)了一個(gè)，想和他人。你可以只們從你的計(jì)算機(jī)，但如果此時(shí)你正在改進(jìn)你的，試驗(yàn)性質(zhì)的改動(dòng)，他們了你的，他們可能由此陷入困境。當(dāng)然，這就是發(fā)布周期存在的原因。開(kāi)發(fā)人員可能頻繁進(jìn)行項(xiàng)目修改，但他們只在他們覺(jué)得代碼用Git來(lái)完成這項(xiàng)，需要進(jìn)入你的所在$git$gitadd$gitcommit-m"First$git 。這要假定他們有ssh權(quán)限。如果沒(méi)有，需要運(yùn)行g(shù)itdaemon并告訴你的$git $gitcommit-a-m"Next $git 我們已經(jīng)做$git$gitdiff$gitdiff1b6d$gitwhatchanged--since="2weeks我也經(jīng)常用qgit[ 或者tig[ ]，一個(gè)文本界面的東西，很慢的網(wǎng)絡(luò)狀況下也工作的很好。也可以安裝web服務(wù)器，運(yùn)行g(shù)itinstaweb，就可以用任何瀏覽器瀏覽了。練比方A，B，C，D是四個(gè)連續(xù)的提交，其中B與A一樣，除了一些文件刪除了。我們想把這些刪$gitdiffBA|git$gitcheckoutAfoo.c$gitrevert第3隆周在較老一代的版本控制系統(tǒng)里，checkout是獲取文件的標(biāo)準(zhǔn)操作。一組特定保存狀態(tài) 件。或者說(shuō)，你實(shí)際上把整個(gè)中心服務(wù)器做了個(gè)鏡像。凡是主倉(cāng)庫(kù)上能做的事，你都能做。計(jì)算$git $gitcommit-$git 典型$git$gitadd$gitcommit-m"Initial $mkdir$cd$gitinit--$gitdaemondetach?$gitpushcentral.server/path/to/proj.gitHEAD$gitcommit-$git$gitcommit-$git為使用上面pull和push命令，開(kāi)發(fā)必須有SSH權(quán)限。不過(guò)，通過(guò)鍵入以下命令，任何人都$gitclone本地git協(xié)議和HTTP類(lèi)似：并無(wú)安全驗(yàn)證，因此任何人都能拿到項(xiàng)目。因此，默認(rèn)情況git協(xié)議封閉 可以通過(guò)git協(xié)議獲?。恢挥心切┯蠸SH權(quán)限的人才能看到。如果你所有的資源庫(kù)都是封閉倉(cāng)之所以叫倉(cāng)庫(kù)是因?yàn)槠錄](méi)有工作；它只包含正常情況下隱藏在`.git`子下的文件。換句話(huà)說(shuō)，它項(xiàng)目歷史，而且從不保存任何給定版本的快照。倉(cāng)庫(kù)扮演的角色和中心版本控制系統(tǒng)心服務(wù)器的角色類(lèi)似：你項(xiàng)目的中心。開(kāi)發(fā)從其中克隆項(xiàng)目，撿入新近改動(dòng)。典型地倉(cāng)庫(kù)存在一個(gè)服務(wù)器上，該服務(wù)器除了分散數(shù)據(jù)外并不做啥。開(kāi)發(fā)活動(dòng)發(fā)生在克隆上，因此中心倉(cāng)庫(kù)沒(méi)有工作也行。很多Git命令在倉(cāng)庫(kù)上失敗，除非指定倉(cāng)庫(kù)路徑到環(huán)境變量`GIT_DIR`，或者指定`--bare`選推還為什么我們介紹了push命令，而不是依賴(lài)熟悉的pull命令？首先，在倉(cāng)庫(kù)上pull會(huì)失?。撼悄惚仨殹癴etch”，一個(gè)之后我們要討論令。但即使我們?cè)谥行姆?wù)器上保持一個(gè)正常的倉(cāng)庫(kù)，拽些東西進(jìn)去仍然很繁瑣。我們不得不登陸服務(wù)器先，給pull地址。會(huì)阻礙，并且首先如果我們沒(méi)有到服務(wù)器的s怎么辦呢？然而，除了這個(gè)案例，我們推進(jìn)倉(cāng)庫(kù)，因?yàn)楫?dāng)目標(biāo)有工作時(shí)，困惑隨之而來(lái)。項(xiàng)目$gitclone$git終極會(huì)有很多散布在各處，篡改的冗余存檔嗎?如果你的項(xiàng)目有很多開(kāi)發(fā)，那干脆啥也別做了。你的每份代碼克隆是一個(gè)有效備份。不僅當(dāng)前狀態(tài)，還包括你項(xiàng)目整個(gè)歷史。感謝哈希加密算法，如果任何人的克隆被損壞，只要他們與其他的交互，這個(gè)克隆就會(huì)被修好。真正的偏執(zhí)狂應(yīng)該總是把HEAD最近20字節(jié)的SHA1不是把它。比如，把它發(fā)布到報(bào)紙上就不錯(cuò)，因?yàn)閷?duì)者而言，更改每份報(bào)紙是很難輕快多任$gitclone.Git使用硬和文件共享來(lái)盡可能安全地創(chuàng)建克隆，因此它一眨眼就完成了，因此你現(xiàn)在可以并行操作兩個(gè)沒(méi)有相互依賴(lài)的功能。例如，你可以編輯一個(gè)克隆，同時(shí)編譯另一個(gè)。感謝hardlinking[],本地克隆比簡(jiǎn)單備份省時(shí)省地?，F(xiàn)在你可以同時(shí)工作在兩個(gè)彼此獨(dú)立的特性上。比如，你可以在編譯一個(gè)克隆的時(shí)候編輯另一$gitpull/the/other/clone游擊 $git$gitadd$gitcommit-m"Initial$gitclone. $gitadd$gitcommit-m"Syncwitheveryone $gitcommit-a-m"Descriptionofmy$git 包含你的改動(dòng)的文件。需倉(cāng)庫(kù)自動(dòng)化了上面的操作，并且也可以用作導(dǎo)出Git項(xiàng)目到Subversion倉(cāng)庫(kù)[ /2008/05/export-git-project-to--code.html]的替代。Mercurial是一個(gè)類(lèi)似的的版本控制系統(tǒng)，幾乎可以和Git`hg-git`插件，一$git $hgclone不好意思，我沒(méi)注意GitGit而不是Mercurial使你偏愛(ài)Mercurial。使用Mercurial項(xiàng)目，通常一個(gè)自愿者一個(gè)平行的Git項(xiàng)目以適應(yīng)Git用戶(hù)，然而感謝`hg-git`插件，一個(gè)Git項(xiàng)目自動(dòng)地適應(yīng)Mercurial用戶(hù)。 $git我們簡(jiǎn)略提一下Bazaar，它畢竟是緊跟Git和Mercurial之后最流行的自由分布式版本控制系Bazaar有后來(lái)者的優(yōu)勢(shì)，它相對(duì)年輕些；它的設(shè)計(jì)者可以從前人的錯(cuò)誤中學(xué)習(xí)，并且躲過(guò)去翻歷史上犯過(guò)的錯(cuò)誤。另外，它的開(kāi)發(fā)人員對(duì)可移植性以及和與其它版本控制系統(tǒng)的互操作性也一個(gè)`bzr-git`插件讓Bazaar用戶(hù)在一定程度下可以工作在Git倉(cāng)庫(kù)。`tailor`Bazaar倉(cāng)庫(kù)到Git倉(cāng)庫(kù)，并且可以遞增的方式做，要知道`bzr-fast-export`只是在轉(zhuǎn)換性情況下工作我偏愛(ài)Git的原我起先選擇Git是因?yàn)槲衣?tīng)說(shuō)它能管理不可想象地不可管理的Linux內(nèi)核源碼。我從來(lái)沒(méi)覺(jué)得有離開(kāi)的必要。Git已經(jīng)服侍的很好了，并且我也沒(méi)有被其瑕疵所困擾。因?yàn)槲抑饕褂肔inux，還有，我偏愛(ài)C程序和bash，以及諸如Python的可執(zhí)行可：較少依賴(lài)，并且我也沉迷我考慮過(guò)Git才能如何提高，甚至自己寫(xiě)類(lèi)似的工具，但只作為研究練練手。即使完成這個(gè)項(xiàng)目，自然地，你的需求和期望可能不同，并且你可能使用另一個(gè)系統(tǒng)會(huì)好些。盡管如此，使用Git你第4支巫問(wèn)題：外部因素要求必須切換場(chǎng)景。在發(fā)布版本中突然蹦出個(gè)嚴(yán)重缺陷。某個(gè)特性完成的截至日期就要來(lái)臨。在項(xiàng)目關(guān)鍵部分可以提供幫助的一個(gè)開(kāi)發(fā)正打算離職。所有情況迫你停下所打斷思維的連續(xù)性會(huì)使你的生產(chǎn)力大大降低，并且切換上下文也更麻煩，更大的損失。使用中心版本控制須從中心服務(wù)器一個(gè)新的工作拷貝。分布式系統(tǒng)的情況就好多了，因?yàn)榈强寺∪匀恍枰截愓麄€(gè)工作，還有直到給定點(diǎn)的整個(gè)歷史記錄。盡管Git使用文件共享和硬減少了花費(fèi)，項(xiàng)目文件自身還是必須在新的工作里重建。使用這個(gè)魔，里的文件突然從一個(gè)版本變到另一個(gè)。除了只是在歷史記錄里上跳下竄外，這個(gè)轉(zhuǎn)換還可以做。你的文件可以從上一個(gè)發(fā)布版變到實(shí)驗(yàn)版本到當(dāng)前開(kāi)發(fā)版本到你鍵 鍵”），屏幕立即顯示一個(gè)電子表格或別的？那么 $echo"I'msmarterthanmyboss">$git$gitadd$gitcommit-m"Initial$gitcheckoutbboss?$echo"Mybossissmarterthanme">$gitcommit-a-m"Another$gitcheckoutmaster? $gitcheckoutboss?切到適合看的版骯臟的工比如你正在開(kāi)發(fā)某個(gè)特性，并且由于某種原因，你需要回個(gè)版本，臨時(shí)加進(jìn)幾行打印語(yǔ)句$gitcommit-$gitcheckout$gitcheckout$gitcheckout-b$gitcheckout我們面章節(jié)討論加載舊狀態(tài)的時(shí)候，曾經(jīng)接觸過(guò)這個(gè)命令。最終我們把故事說(shuō)全：文件改變成請(qǐng)求的狀態(tài)，但須離開(kāi)主分支。從現(xiàn)在開(kāi)始的任何提交都會(huì)將你的文件提交到另一支可以使用gitcheckout-b來(lái)命名和保存?？焖倌阏谧瞿臣碌漠?dāng)間，知先停所有的事情，去修理一個(gè)新近發(fā)現(xiàn)的臭蟲(chóng)，這個(gè)臭蟲(chóng)在提交`1b6d…`：$gitcommit-$gitcheckout-bfixes$gitcommit-a-m"Bug$gitcheckout$gitmerge合一些版本控制系統(tǒng)，創(chuàng)建分支很容易，但把分支合并回來(lái)很難。使用Git，合并簡(jiǎn)直是家常便我們很久之前就遇到合并了。pull命令取出提交并合并它們到你的當(dāng)前分支。如果你沒(méi)有本地變更，那這個(gè)合并就是一個(gè)“快進(jìn)”，相當(dāng)于中心式版本控制系統(tǒng)里的一個(gè)弱化的獲取版通常，一個(gè)提交只有一個(gè)“父提交”，也叫前一個(gè)提交。合并分支到一起產(chǎn)生一個(gè)至少有兩個(gè)父的提交。這就引出了問(wèn)題：HEAD~10真正指哪個(gè)提交？一個(gè)提交可能有多個(gè)父，那我們跟原來(lái)這個(gè)表示每次選擇第一個(gè)父。這是可取的，因?yàn)樵诤喜r(shí)候當(dāng)前分支成了第一個(gè)父；多數(shù)$gitlog$gitdiff$gitcheckout1b6d^^2~10-b不間經(jīng)常在硬件項(xiàng)目里，計(jì)劃的第二步必須等第一步完成才能開(kāi)始。待修的汽車(chē)傻等在車(chē)庫(kù)里，直軟件項(xiàng)目可能也類(lèi)似。新功能的第二部分不得不等待，直到第一部分發(fā)布并通過(guò)測(cè)試。一些項(xiàng)目要求你的代碼需要才能接受，因此你可能需要等待第一部分得到批準(zhǔn)，才能開(kāi)始第二部工作。假設(shè)你已經(jīng)將第一部分提交并發(fā)去，比如說(shuō)你現(xiàn)在在主分支。那么分岔：$gitcheckout-b$gitcheckoutmaster?$gitcommit ?$gitcheckoutpart2?$gitmerge ?$gitcheckoutmaster?$submit ?$gitmerge ?$gitbranchdpart2? $gitbranchmmasterpart2?重命名“master”分支為“part2”$gitbranchmaster 分支master只有第一部分內(nèi)容，其他內(nèi)容在分支part2。我們現(xiàn)在后一個(gè)分支；我們創(chuàng)建了masterpart2$gitcheckoutHEAD~7bmaster?重組$gitbranch ?$gitcheckoutbmedley? $gitcheckout$gitcherry-pick管理$gitmastermasterdm（重命名）githelpbranch分支“master”是一個(gè)有用的慣例。其他人可能假定你的倉(cāng)庫(kù)有一個(gè)叫這個(gè)名字的分支，并且該分支包含你項(xiàng)目的版本。盡管你可以重命名或抹殺“master”分支，你最好還是尊重這臨時(shí)很快你會(huì)發(fā)現(xiàn)你經(jīng)常會(huì)因?yàn)橐恍┫嗨频脑騽?chuàng)建短期的分支：每個(gè)其它分支只是為了保存當(dāng)前可以和電視的換臺(tái)做類(lèi)比，臨時(shí)切到別的頻道，來(lái)看看其它臺(tái)那正放什么。但并不是簡(jiǎn)單地按$git這個(gè)命令保存當(dāng)前狀態(tài)到一個(gè)臨時(shí)的地方（一個(gè)隱藏的地方）并且恢復(fù)之前狀態(tài)。你的工作目錄看起來(lái)和你開(kāi)始編輯之前一樣，并且你可以修復(fù)臭蟲(chóng)，引入之前變更等。當(dāng)你想回到隱藏狀$gitstashapply?你可以有多個(gè)隱藏，并用不同的方式來(lái)操作他們。參見(jiàn)githelpslash。也許你已經(jīng)猜到，Git按你希望的cd考慮一下瀏覽器。為什么同時(shí)支持多和多窗口？因?yàn)樵试S兩者同時(shí)接納了多種風(fēng)格的用戶(hù)。一些用戶(hù)喜歡只保持一個(gè)打開(kāi)的窗口，然后用瀏覽多個(gè)網(wǎng)頁(yè)。一些可能堅(jiān)持另一個(gè)極分支類(lèi)似你工作的，克隆類(lèi)似打開(kāi)的瀏覽器新窗口。這些是本地操作很快，那為什么第5于歷Git分布式本性使得歷史可以輕易編輯。但你若篡改過(guò)去，需要：只重寫(xiě)你獨(dú)自擁有的那部分。正如民族間會(huì)無(wú)休止的爭(zhēng)論誰(shuí)犯下了什么一樣，如果在另一個(gè)人的克隆里，歷史版本一些開(kāi)發(fā)人員強(qiáng)烈地感覺(jué)歷史應(yīng)該不變，不好的部分也不變所有都不變。另一些覺(jué)得代碼樹(shù)在向外發(fā)布之前，應(yīng)該整得漂漂亮亮的。Git同時(shí)支持兩者的觀點(diǎn)。像克隆，分支和合并一樣，重寫(xiě)歷史只是Git給你的另一強(qiáng)大功能，至于如何明智地使用它，那是你的事了。我認(rèn)$gitcommit--來(lái)改變上一條信息。你還忘記了加一個(gè)文件？運(yùn)行g(shù)itadd來(lái)加，然后運(yùn)行上面的命令。$gitcommit--amend-更復(fù)雜情$gitrebase-ipick5c6eb73Addedrepo.or.czpicka311a64Reordered ogiesin"WorkHowYouWant"pick100834fAddedpushtargettoMakefilepick$gitcommit--$gitrebase--本地但現(xiàn)在你本地Git克隆摻雜了你的改動(dòng)和改動(dòng)。你更期望在變更列表里，你所有的變更能夠重寫(xiě)偶爾，你需要做一些代碼控制，好比從正式的中去除一些人一樣，需要從歷史記錄里面徹底的抹掉他們。例如，假設(shè)我們要發(fā)布一個(gè)項(xiàng)目，但由于一些原因，項(xiàng)目中的某個(gè)文件不能公開(kāi)。或許我把我的號(hào)記錄在了一個(gè)文本文件里，而我又意外的把它加入到了這個(gè)項(xiàng)目中。僅僅刪除這個(gè)文件是不夠的，因?yàn)閺膭e的提交記錄中還是可以訪(fǎng)問(wèn)到這個(gè)文件。因此我們參見(jiàn)githelpfilter-branch，那里討論了這個(gè)例子并給出一個(gè)更快的方法。一般地，filter-branch允許你使用一個(gè)單一命令來(lái)大范圍地更改歷史。 描述操作之前的狀態(tài)。檢查命令filter-branch的確做了你想要 制造想把一個(gè)項(xiàng)目遷移到Git嗎？如果這個(gè)項(xiàng)目是在用比較有名氣的系統(tǒng)，那可以使用一些其他人已commitcommitterAlice< >Thu,01Jan197000:00:00data<<EOTM100644inlineo.cdata<<EOT?includeintmain() return0;committerBob< >Tue,14Mar200001:59:26-0800data<<EOTReplaceprintf()withwrite().M100644inlineo.cdata<<EOT?includeintmain()write(1,"o,world!\n",14);return0;$mkdirproject;cdproject;git$gitfast-import--date-format=rfc2822<$gitcheckoutmaster也以可讀格式傳送倉(cāng)庫(kù)。的確，這些命令可以發(fā)送倉(cāng)庫(kù)文本文件通過(guò)只接受文本的。哪兒錯(cuò)了$gitbisect$gitbisectbad$gitbisectgood$gitbisect如果可以工作了，則把"bad"替換成"good"。Git會(huì)再次幫你找到一個(gè)以確定的好版本和壞版本之間的狀態(tài)，通過(guò)這種方式縮小范圍。經(jīng)過(guò)一系列的迭代，這種二分搜索會(huì)幫你找到導(dǎo)致這個(gè)錯(cuò)誤的那次提交。一旦完成了問(wèn)題定位的，你可以返回到原始狀態(tài)，鍵入：$gitbisect$gitbisectrunGit使用指定命令（通常是一個(gè)的）的返回值來(lái)決定一次改動(dòng)是否是正確的：命令退出時(shí)的代碼0代表改動(dòng)是正確的，125代表要跳過(guò)對(duì)這次改動(dòng)的檢查，1到127你還能做的事情:幫助文檔解釋了如何展示bisects,檢查或重放bisect的日志,并可以通過(guò)排誰(shuí)讓事情變$gitblame個(gè)人 這么做。沒(méi)有網(wǎng)絡(luò)，克隆，分支和合并都沒(méi)法做。像一些基本的操作如瀏覽歷史，或提交變更也是如此。在一些系統(tǒng)里，用戶(hù)使用網(wǎng)絡(luò)連接僅僅是為了查看他們自己的變更，或打開(kāi)文件進(jìn)行編輯。中心系統(tǒng)排斥離線(xiàn)工作，也需要更昂貴的網(wǎng)絡(luò)設(shè)施，特別是當(dāng)開(kāi)發(fā)人員增多的時(shí)候。最重要的是，所有操作都一定程度變慢，一般在用戶(hù)避免使用那些能不用則不用的高級(jí)命令時(shí)。在的情況下，即使是最基本令也會(huì)變慢。當(dāng)用戶(hù)必須運(yùn)行緩慢令的時(shí)候，由于工作流被我有這些的一手經(jīng)驗(yàn)。Git是我使用的第一個(gè)版本控制系統(tǒng)。我很快學(xué)會(huì)適應(yīng)了它，用了它提供的許多功能。我簡(jiǎn)單地假設(shè)其他系統(tǒng)也是相似的：選擇一個(gè)版本控制系統(tǒng)應(yīng)該和選擇一個(gè)編輯在我之后被迫使用中心系統(tǒng)的時(shí)候，我被了。我那有些脆弱的網(wǎng)絡(luò)沒(méi)給Git帶來(lái)煩，但是當(dāng)它需要像本地硬盤(pán)一樣穩(wěn)定的時(shí)候，它使開(kāi)發(fā)重重。另外，我發(fā)現(xiàn)我自己有選擇地避免特定令，以避免踏雷，這極大地影響了我，使我不能按照我喜歡的方式工作。當(dāng)我不得不運(yùn)行一個(gè)慢令的時(shí)候，這種等待極大地破壞了我思緒連續(xù)性。在等待服務(wù)器通訊完成的時(shí)候，我選擇做其他的事情以度過(guò)這段時(shí)光，比如查看郵件或?qū)懫渌奈臋n。當(dāng)我返回我原先的工作場(chǎng)景的時(shí)候，這個(gè)命令早已結(jié)束，并且我還需要浪費(fèi)時(shí)間試圖記起我之前正在還有一個(gè)有意思的大眾悲劇效應(yīng)：預(yù)料到網(wǎng)絡(luò)擁擠，為了減少將來(lái)的等待時(shí)間，每個(gè)人將比以往消費(fèi)的帶寬在上。共同的努力加劇了擁擠，這等于是鼓勵(lì)個(gè)人下次消費(fèi)帶第6章多人只用到了pull和*clone*，用以在不同地方保持同一個(gè)項(xiàng)目。 用Git發(fā)布我的代碼，并且包括其他貢獻(xiàn)者的變更。我不得不學(xué)習(xí)如何管理有來(lái)自世界我是 和電子信箱，這顯示在gitlog里。默認(rèn)，Git使用系統(tǒng)設(shè)定來(lái)填充$"John$gitconfig--globaluser.Git在SSH,HTTP $GIT_DIR=proj.gitgit$cd$oda+xhooks/post-$gitcloneGit在隨便什么想無(wú)需服務(wù)器，甚至無(wú)需網(wǎng)絡(luò)連接的時(shí)候同步倉(cāng)庫(kù)？需要在緊急時(shí)期湊合一下？我們已經(jīng)看過(guò)gitftepot和gtftprtgtgitunde。$gitbundlecreatesomefile$gitpull$gitbundlecreatesomefileHEAD如果做的頻繁，人可能容易忘記剛發(fā)了哪個(gè)提交。幫助頁(yè)面建議使用解決這個(gè)問(wèn)題。即，$gittag-flastbundle$gitbundlecreatenewbundleHEAD補(bǔ)?。喝蜓a(bǔ)丁是變更的文本形式，易于計(jì)算機(jī)理解，人也類(lèi)似。補(bǔ)丁可以通吃。你可以給開(kāi)發(fā)電郵一個(gè)補(bǔ)丁，不用管他們用的什么版本控制系統(tǒng)。只要你的觀眾可以讀電子郵件，他們就能看到你的修改。類(lèi)似，在你這邊，你只需要一個(gè)電子郵件帳號(hào)：不必搭建一個(gè)的Git倉(cāng)庫(kù)。$gitdiff1b6d>$gitam 對(duì)基于mbox對(duì)不起，移$gitconfig--remote.origin.urlURL源；“originmaster$gitconfigremote.origin.urlbranch.master.mergegitpullpull也將忠實(shí)地跟著原來(lái)的$git 遠(yuǎn)端當(dāng)你克隆一個(gè)倉(cāng)庫(kù)，你也克隆了它的所有分支。你或許沒(méi)有注意到因?yàn)镚it將它們隱藏起來(lái)了：你必須明確地要求。這使得遠(yuǎn)端倉(cāng)的分支不至于干擾你的分支，也使Git對(duì)初學(xué)者稍稍容易$gitbranch-這顯示了遠(yuǎn)端倉(cāng)庫(kù)的分支和HEAD，可以用在常用的Git命令里。例如，假設(shè)你已經(jīng)做了很多提交，并希望和最后取到的版本比較一下。你可以搜索適當(dāng)?shù)腟HA1$gitdiff$gitlog多遠(yuǎn)$gitremoteadd $gitpullother$gitdifforigin/experimental^但如果為了不影響自己的工作，我們只想比較他們的變更怎么辦呢？換句話(huà)說(shuō)，我們想檢查一 。那不是運(yùn)行pull命令，而是運(yùn)行：$git ?Fetchfromorigin,the$gitfetchother?Fetchfromthesecond 維持不變，我們可以參考任何倉(cāng)庫(kù)的任何分支，使用一個(gè)Git命回想一下，在幕后，一個(gè)pullfetchmergepull我的對(duì)我手頭的項(xiàng)目，我喜歡貢獻(xiàn)者去準(zhǔn)備倉(cāng)庫(kù)，這樣我可以從其中拉。一些Git在我獲取一個(gè)樹(shù)之后，我運(yùn)行Git描述良好。我合并這些變更，也或許做些編輯。直到滿(mǎn)意，我才把變更推入主資源庫(kù)。 這篇來(lái)自L(fǎng)inusTorvalds的博客[/2009/06/happiness-is-warm-scm.html]呆在Git的世界里比補(bǔ)丁文件稍更方便，因?yàn)椴挥梦覍⒀a(bǔ)丁轉(zhuǎn)換到Git提交。更進(jìn)一步，Git處理諸如作者和信箱地址的細(xì)節(jié)，還有時(shí)間和日期，以及要求作者描述他們的提交。7Git大師githelp的確切命令可能是乏味的。或許我可以省你點(diǎn)功夫：以下是我過(guò)去曾經(jīng)需要的一些食譜。源碼提交$gitadd$gitadd- 的文件并自己算出具體的情況。除了用第二個(gè)add命令，如果你也打算這時(shí)提交，可以運(yùn)行`gitcommit-a`。關(guān)于如何指定應(yīng)被忽略的文件，參見(jiàn)githelpignore。$gitls-files-d-m-o-z|xargs-0gitupdate-index--add--z0被忽略的文件，這時(shí)你可能需要加上-x或-X選項(xiàng)。我的提交太$gitadd-為你做的每次修改，Git$git如果你修改了許多地方的許多文件怎么辦？一個(gè)一個(gè)地查看變更令人沮喪，心態(tài)麻木。這種情況下，使用gitadd-i，它的界面不是很直觀，但更靈活。敲幾個(gè)鍵，你可以一次決定階段或gitcommit--interactive，這個(gè)命令會(huì)在你操作完后自動(dòng)進(jìn)行提交。索引：Git的中轉(zhuǎn)區(qū)當(dāng)目前為止，我們已經(jīng)忽略Git著名的'索引‘概念，但現(xiàn)在須面對(duì)它，以解釋上面發(fā)生的。索引是一個(gè)臨時(shí)中轉(zhuǎn)區(qū)。GitGit先寫(xiě)例如，commit-a實(shí)際上是一個(gè)兩步過(guò)程。第一步把每個(gè)追蹤文件當(dāng)前狀態(tài)的快照放到索引a索引令才有意義，比如gitadd。通常我們可以忽略索引并假裝從歷史中直接讀并直接寫(xiě)。在這個(gè)情況下，我們希望更好地控制，因此我們操作索引。我們放我們變更的一些的快照到索引中，而不是所有的，然后永久地別丟了你的HEAD好似一個(gè)游標(biāo)，通常指向提交，隨提交向前移動(dòng)。一些Git命令讓你來(lái)移動(dòng)它。$gitreset將立即向回移動(dòng)HEAD三個(gè)提交。這樣所有Git$gitreset但假設(shè)你從來(lái)沒(méi)有記下呢？別擔(dān)心，像這些命令，Git保存原先的HeadORGI_HEAD的$gitresetHEAD捕或許ORG_HEAD默認(rèn)，Git保存一個(gè)提交至少兩星期，即使你命令Git哈希值。你可以查看在.git/objects里所有的哈希值并嘗試找到你期望的。但有一個(gè)更容易的辦 包括所有分支上所有活動(dòng)的歷Thereflogcommandprovidesafriendlyinterfacetotheselogfiles.$git$gitcheckoutgithelprev-parse`SpecifyingRevisions’'部分。$gitconfiggc.pruneexpire"30你或許還想關(guān)掉gitgc的自動(dòng)運(yùn)行：$gitconfiggc.auto基于Git依照真正的UNIX風(fēng)格設(shè)計(jì)，Git允許其易于用作其他程序的底層組件，比如圖形界面，Web界面，可選擇令行界面，補(bǔ)丁管理工具，導(dǎo)入和轉(zhuǎn)換工具等等。實(shí)際上，一些Git命令它們自己就是站在巨人肩膀上的。通過(guò)一點(diǎn)修補(bǔ)，你可以定制Git適應(yīng)你的偏好。$gitconfig--globalalias.coalias.co$gitco $gitsymbolic-ref$gitsymbolic-refHEAD2>/dev/null|cut-b 位于/usr/share/doc/git-core/contrib。一個(gè)受歡迎的居民是workdir/git-new-workdir。通過(guò)聰明的符號(hào)，這個(gè)創(chuàng)建一個(gè)新 和其中的文件可被視為一個(gè)克隆，除了既然歷史是共享的，兩者的樹(shù)自動(dòng)保持同大膽的特這些天，Git使得用戶(hù)意外摧毀數(shù)據(jù)變得更。但如若你知道你在做什么，你可以突破為通用$gitcheckout-f$gitreset--hard$gitbranch-Ddead_branch?insteadof-$gitbranchMsourcetarget?不像checkout和重置，這兩個(gè)命令延遲數(shù)據(jù)銷(xiāo)毀。這個(gè)變更仍然在.git的子里，并且可以通過(guò)恢復(fù).git/logs里的相應(yīng)哈希值獲取（參見(jiàn)上面上面“HEAD獵捕”）。默認(rèn)情況下，$gitclean-f-壞提追加空格并引起合并：盡管危害少，我希望浙西不要出現(xiàn)在公開(kāi)記錄里。$cd$ mit?對(duì)舊版本Git，先運(yùn) od ifgitls-files-o|grep'\.txt$';thenechoFAIL!Untracked.txtfiles.exit1幾個(gè)git操作支持鉤子；參見(jiàn)githelphooks。我們?cè)缦燃せ盍俗鳛槔拥膒ost-updateupdate更新Git在基于Git并不知曉的傳輸協(xié)議，諸如HTTP，通訊時(shí)所需的文件。第8開(kāi)面我們揭開(kāi)Git神秘面紗，往里瞧瞧它是如何創(chuàng)造的。我會(huì)跳過(guò)細(xì)節(jié)。更深入的描述參見(jiàn)用戶(hù)手冊(cè)[ 大象Git怎么這么謙遜寡言呢？除了偶爾提交和合并外，你可以如常工作，就像不知道版本控制系統(tǒng)存在一樣。那就是，直到你需要它的時(shí)候，而且那是你歡欣的時(shí)候，Git一直默默注視著你。其他版本控制系統(tǒng)強(qiáng)迫你與繁文縟節(jié)和主義不斷。文件的權(quán)限可能是只讀的，除非你顯式地告訴中心服務(wù)器哪些文件你打算編輯。即使最基本令，隨著用戶(hù)數(shù)目的增多，也會(huì)慢的像爬一樣。中心服務(wù)器可能正什么人，什么時(shí)候checkout了什么代碼。當(dāng)網(wǎng)絡(luò)連接斷了的時(shí)候，你就遭殃了。開(kāi)發(fā)人員不斷地與這些版本控制系統(tǒng)的種種限制作。一旦網(wǎng)絡(luò)或與之相反，Git簡(jiǎn)單地在你工作下的.git`保存你項(xiàng)目的歷史。這是你自己的歷史拷貝，因此你可以保持離線(xiàn)，直到你想和他人溝通為止。你擁有你的文件命運(yùn)完全的控制權(quán)，因?yàn)镚it數(shù)據(jù)完整很多人把加密和保持信息關(guān)聯(lián)起來(lái)，但一個(gè)同等重要的目標(biāo)是保證。合理使用哈一個(gè)SHA1哈希值可被認(rèn)為是一個(gè)唯一的160位ID節(jié)串。實(shí)際上不止如此：每個(gè)字節(jié)串可供任何人用好多輩子。因?yàn)橐粋€(gè)SHA1的觀察出奇地有用：查看“哈希鏈”。我們之后會(huì)看Git如何利用這一點(diǎn)來(lái)高效地保證數(shù)據(jù)完整簡(jiǎn)言之，Git數(shù)據(jù)保存在`.git/objects`子，那里看不到正常文件名，相反你只看到ID。通過(guò)用ID作為文件名，加上一些文件鎖和時(shí)間戳技巧，Git把任意一個(gè)原始的文件系統(tǒng)轉(zhuǎn)化為一智Git是如何知道你重命名了一個(gè)文件，即使你從來(lái)沒(méi)有明確提及這個(gè)事實(shí)？當(dāng)然，你或許是運(yùn)行了gitmv，但這個(gè)命令和gitadd緊接gitrm是完全一樣的。Git啟發(fā)式地找出相連版本之間的重命名和拷貝。實(shí)際上，它能檢測(cè)文件之間代碼塊的移動(dòng)或拷貝！盡管它不能覆蓋所有的情況，但它已經(jīng)做的很好了，并且這個(gè)功能也改進(jìn)中。如果它在你那兒不工作的話(huà)，可以嘗試打開(kāi)開(kāi)銷(xiāo)更高的拷貝檢測(cè)選項(xiàng)，并考慮升級(jí)。索為每個(gè)加入管理的文件，Git在一個(gè)名為“index”的文件里記錄統(tǒng)計(jì)信息，諸如大小，創(chuàng)建時(shí)間和最后修改時(shí)間。為了確定文件是否更改，Git比較其當(dāng)前統(tǒng)計(jì)信息與那些在索引里的統(tǒng)計(jì)信因?yàn)榻y(tǒng)計(jì)信息的調(diào)用比讀文件內(nèi)容快的很多，如果你僅僅編輯了少數(shù)幾個(gè)文件，Git幾乎不需要我們前面講過(guò)索引是一個(gè)中轉(zhuǎn)區(qū)。為什么一堆文件的統(tǒng)計(jì)數(shù)據(jù)是一個(gè)中轉(zhuǎn)區(qū)？因?yàn)樘砑用顚⑽募诺紾it的數(shù)據(jù)庫(kù)并更新它們的統(tǒng)計(jì)信息，而無(wú)參數(shù)的提交命令創(chuàng)建一個(gè)提交，只基于這些Git的源這個(gè)Linux內(nèi)核郵件列表帖子[]描述了導(dǎo)致Git的一系列對(duì)象數(shù)據(jù)你數(shù)據(jù)的每個(gè)版本都保存在“對(duì)象數(shù)據(jù)庫(kù)”里，其位于子.git/objects`；其他位于.git/`的較少數(shù)據(jù)：索引，分支名，，配置選項(xiàng)，日志，頭提交的當(dāng)前位置等。對(duì)象數(shù)據(jù)庫(kù)樸素而`.git/objects`里的每個(gè)文件是一個(gè)對(duì)象。有3中對(duì)象跟我們有關(guān)：“blob”對(duì)象，“tree”對(duì)Blob對(duì)首先來(lái)一個(gè)小把戲。去一個(gè)文件名，任意文件名。在一個(gè)空$echosweet>$git$gitadd$find.git/objects-type.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d"blob"SP"6"NUL"sweet"LF是aa823728ea7d592acc69b36875a482cdf3fd5c8d，這里SP是一個(gè)空格，NUL是一個(gè)0字節(jié)，LF是一個(gè)換行符。你可以驗(yàn)證這一點(diǎn)，鍵入：$printf"blob6\000sweet\n"|Git基于“內(nèi)容尋址”：文件并不按它們的文件名，而是按它們包含內(nèi)容的哈希值，在一個(gè)叫“blob對(duì)象”的文件里。我們可以把文件內(nèi)容的哈希值看作一個(gè)唯一ID，這樣在某種意義上我們通過(guò)他們內(nèi)容放置文件。開(kāi)始的“blob6”只是一個(gè)包含對(duì)象類(lèi)型與其長(zhǎng)度的頭；它簡(jiǎn)化.git/objects的內(nèi)容保持不變，不管你加了多少。Git只一次數(shù)據(jù)。 過(guò)zpipe-d[]管道，或者鍵入：Tree$gitcommit?$find.git/objects-type$find.git/objects-type 里，文件類(lèi)型是100644，這意味著“rose”是一個(gè)一般文件，并且哈希值指blob對(duì)象，包含“rose”的內(nèi)容。其他可能文件類(lèi)型有可執(zhí)行，或者。在最后一個(gè)例子里，哈希值$rm-r$gitreflogexpire--expire=now--$git在真實(shí)項(xiàng)目里你通常應(yīng)該避免像這樣令，因?yàn)槟阍谄茡Q備份。如果你期望一個(gè)干凈的倉(cāng)庫(kù)，通常最好做一個(gè)新的克隆。還有，直接操作.git時(shí)一定要：如果Git命令同時(shí)也在運(yùn)行會(huì)怎樣，或者突然停電？一般，應(yīng)由gitupdate-ref-d刪除，盡管通常手工刪除refs/original也是安全的。Commit對(duì)我們已經(jīng)解釋了三個(gè)對(duì)象中的兩個(gè)。第三個(gè)是“commit$gitcommitamendmShakespeare?$gitfilter-branch--env-filter'exportGIT_AUTHOR_DATE="Fri13Feb200915:31:30-0800" MITTER_DATE="Fri,13Feb200915:31:30-0800" "'?Rigtimestampsand$find.git/objects-type你現(xiàn)在應(yīng)看到是下列內(nèi)容的"commit158""tree05b217bb859794d08bb9e4f7f04cbda4b207fbe9"LF"authorAlice< -0800"LF"committerBob< -0800"LF沒(méi)那Git的似乎太簡(jiǎn)單?？雌饋?lái)似乎你可以整合幾個(gè)s ，加幾行C代碼來(lái)弄起來(lái)，也就幾個(gè)小時(shí)的事：一個(gè)基本文件操作和SHA1哈希化的混雜，用鎖文件裝飾一下，文件同步保證健壯性。實(shí)際上，這準(zhǔn)確描述了Git的最早期版本。盡管如此，除了巧妙地打包以節(jié)省空間，巧妙地索引以省時(shí)間，我們現(xiàn)在知道Git如何靈巧地改造文件系統(tǒng)成為一個(gè)對(duì)版本控制完美的數(shù)據(jù)庫(kù)。 的任何一個(gè)文件由于硬盤(pán)錯(cuò)誤損毀，那么其哈希值將不再匹配，這個(gè)性。Commit對(duì)象是原子的，也就是說(shuō)，一個(gè)提 不會(huì)部分地記