Git版本控制_姚倫

1、GIT版本控制入門培訓(xùn)GIT實戰(zhàn)GIT進(jìn)階GIT歷史GIT基礎(chǔ)版本控制系統(tǒng)什么是版本控制？我們真的需要嗎？什么是版本控制？我們真的需要嗎？ 版本控制是一種記錄若干文件內(nèi)容變化，以便將來查閱 特定版本修訂情況的系統(tǒng)。當(dāng)我們僅對保存著軟件源代碼的文本文件 作版本控制管理，而實際上，你可以對任何類型的文件進(jìn)行版本控制。 如果你是位圖形或網(wǎng)頁設(shè)計師，再或者是一名程序名，可能會需要保存某一幅圖片、一個頁面布局文件或一個代碼文件的所有修訂版 本。采用版本控制系統(tǒng)（VCS）是個明智的選擇。有了它你就可以將某個文件回溯到之前的 狀態(tài)，甚至將整個項目都回退到過去某個時間點的狀態(tài)。你可以比較文件的變化細(xì)節(jié)，查 出

2、是誰最后修改了什么地方從而造成某些怪異問題，又是誰在何時報告了某個功能缺陷，等等。使用版本控制系統(tǒng)通常還意味著，就算你胡來搞砸了整個項目，把文件改的改，刪的刪，你也可以輕松恢復(fù)到原先的樣子。而由此額外增加的工作量卻微乎其微。版本控制為我們解決的問題 項目的版本控制 工作協(xié)同 發(fā)布管理 Debug (git bisect) 代碼審核 持續(xù)集成個人的版本控制 時光機(jī) 云存儲 在GitHub上的博客、“簡歷”許多人習(xí)慣用復(fù)制整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區(qū)別。這么做唯一的好處就是簡單，不過壞處卻不少：有時候會混淆所在的工作目錄，弄錯了文件丟了數(shù)據(jù)就沒了后退的路。為了

3、解決這個問題，人們很久以前就開發(fā)了許多種本地版本控制系統(tǒng)，大多都是采用某種簡單的數(shù)據(jù)庫來記錄文件的歷次更新差異。本地版本控制系統(tǒng)接下來人們又遇到一個問題，如何讓在不同系統(tǒng)上的開發(fā)者協(xié)同工作？于是，集中化的版本控制系統(tǒng)（ Centralized Version Control Systems，簡稱 CVCS ）應(yīng)運而生。這類系諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的服務(wù)器，保存所有文件的修訂版本，而協(xié)同工作的人們都通過客戶端連到這臺服務(wù)器，取出最新的文件或者提交更新。多年以來，這已成為版本控制系統(tǒng)的標(biāo)準(zhǔn)做法（見圖 1.2）。這種做法帶來了許多好處，

4、特別是相較于老式的本地 VCS 來說。現(xiàn)在，每個人都可以一定程度上看到項目中的其他人正在做些什么。而管理員也可以輕松掌控每個開發(fā)者的權(quán)限，并且管理一個 CVCS 要遠(yuǎn)比在各個客戶端上維護(hù)本地數(shù)據(jù)庫輕松容易得多。事分兩面，有好有壞。這么做最顯而易見的缺點是中央服務(wù)器的單點故障。若是宕機(jī)一小時，那么在這一小時內(nèi)，誰都無法提交更新，也就無法協(xié)同工作。如果中央服務(wù)器的磁盤發(fā)生故障，并且沒做過備份或者備份得不夠及時的話，還會有丟失數(shù)據(jù)的風(fēng)險。最壞的情況是徹底丟失整個項目的所有歷史更改記錄，被客戶端提取出來的某些快照數(shù)據(jù)除外，但這樣的話依然是個問題，你不能保證所有的數(shù)據(jù)都已經(jīng)有人提取出來。本地版本控制系統(tǒng)

5、也存在類似問題，只要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新信息的風(fēng)險。集中化的版本控制系統(tǒng)于是分布式版本控制系統(tǒng)（ Distributed Version Control System，簡稱DVCS ）面世了。在這類系統(tǒng)中，諸如Git，Mercurial，Bazaar 還有Darcs 等，客戶端并不只提取最新版本的文件快照，而是把原始的代碼倉庫完整地鏡像下來。這么一來，任何一處協(xié)同工作用的服務(wù)器發(fā)生故障，事后都可以用任何一個鏡像出來的本地倉庫恢復(fù)。因為每一次的提取操作，實際上都是一次對代碼倉庫的完整備份分布式版本控制系統(tǒng) CVS, 1986/1990 Subversion,

6、2001/2004 ClearCase, 1992 Visual SourceSafe, 1994版本控制大爆發(fā) Perforce, 1995 Starteam, 1995 Team Foundation Server, 2005 Rational Team Concert, 2008誰在用Git Linux Kernel Perl Eclipse Gnome KDE Qt Ruby on Rails Android PostgreSQL PHP Debian X.org Prototype, jQuery集中式版本控制優(yōu)點優(yōu)點缺點缺點一臺服務(wù)器共享；協(xié)同性能瓶頸；單點故障；備份網(wǎng)絡(luò)操作分布式

7、團(tuán)隊；遠(yuǎn)程開發(fā)慢；無法移動辦法遞增式提交歷史不會破壞提交過時；頻繁沖突集中授權(quán)基于路徑的讀寫授權(quán)項目參與度低分布式版本控制優(yōu)點優(yōu)點缺點缺點全是服務(wù)器最安全；無帶寬和性能瓶頸習(xí)慣和方式的轉(zhuǎn)變本地提交操作快；移動辦公忘記推送（PUSH）數(shù)據(jù)校驗版本庫不被篡改歷史變更影響最新數(shù)據(jù)非線性提交真正的分支；合并更容易提交版本號太長多樣化協(xié)同模型對新人的審核；受控庫習(xí)慣的轉(zhuǎn)變提交可更改提交修正和重構(gòu)提交丟失什么是GIT？Git是一個分布式版本控制軟件配置管理軟件，原來是linux內(nèi)核開發(fā)者Linus Torvalds為了更好地管理linux內(nèi)核開發(fā)而創(chuàng)立的。/wi

8、ki/GitLinus TorvaldsJunio C Hamano濱野-純Git設(shè)計目標(biāo) 快速 簡單的設(shè)計 非線性開發(fā)的強(qiáng)大支持（成千上萬個分支） 完全分布式 高效率的處理大型項目，如linux kernelhttp:/git- 不能排他式修改，所以Git不適合. 不能克隆子目錄 所以Android有近200個Git庫 整體的讀授權(quán)，0/1 版本庫拆分HTTPS:/GITHUB.COM/GITHUB IS THE BEST PLACE TO SHARE CODEWITH FRIENDS, CO-WORKERS, CLASSMATES, AND COMPLETE STRANGERS. OVER

9、 THREE MILLION PEOPLE USE GITHUB TO BUILD AMAZING THINGS TOGETHER.Git安裝Git安裝WindowsGit程序 下載地址：https:/ 下載地址：https:/ GitGit基礎(chǔ)要點在開始學(xué)習(xí)Git 的時候，請不要嘗試把各種概念和其他的版本控制系統(tǒng)諸如Subversion等相比擬，否則容易混淆每個操作的實際意義。 直接快照，而非比較差異其他系統(tǒng)在每個版本中記錄著各個文件的具體差異Git 保存每次更新時的文件快照Git基礎(chǔ)要點 近乎所有操作都可本地執(zhí)行 時刻保持?jǐn)?shù)據(jù)完整性Git 使用SHA-1 算法計算數(shù)據(jù)的校驗和，通過對文件的

10、內(nèi)容或目錄的結(jié)構(gòu)計算出一個SHA-1 哈希值，作為指紋字符串。該字串由40 個十六進(jìn)制字符（0-9 及a-f）組成，看起來就像是：24b9da6552252987aa493b52f8696cd6d3b00373Git 的工作完全依賴于這類指紋字串，所以你會經(jīng)常看到這樣的哈希值。實際上，所有保存在Git 數(shù)據(jù)庫中的東西都是用此哈希值來作索引的，而不是靠文件名。 多數(shù)操作僅添加數(shù)據(jù)常用的Git 操作大多僅僅是把數(shù)據(jù)添加到數(shù)據(jù)庫。因為任何一種不可逆的操作，比如刪除數(shù)據(jù)，要回退或重現(xiàn)都會非常困難。在別的版本控制中，若還未提交更新，就有可能丟失或者混淆一些修改的內(nèi)容，但在Git 里，一旦提交快照之后就完

11、全不用擔(dān)心丟失數(shù)據(jù)，特別是在養(yǎng)成了定期推送至其他鏡像倉庫的習(xí)慣的話。Git基礎(chǔ)要點 三種狀態(tài)對于任何一個文件，在Git 內(nèi)都只有三種狀態(tài)：已提交（committed），已修改（modified）和已暫存（staged）。已提交表示該文件已經(jīng)被安全地保存在本地數(shù)據(jù)庫中了；已修改表示修改了某個文件，但還沒有提交保存；已暫存表示把已修改的文件放在下次提交時要保存的清單中。工作目錄，暫存區(qū)域和git 目錄基本的Git 工作流程如下所示：1. 在工作目錄中修改某些文件。2. 對這些修改了的文件作快照，并保存到暫存區(qū)域。3. 提交更新，將保存在暫存區(qū)域的文件快照轉(zhuǎn)儲到git 目錄中。初次運行Git 前的配

12、置一般在新的系統(tǒng)上，我們都需要先配置下自己的Git 工作環(huán)境。配置工作只需一次，以后升級時還會沿用現(xiàn)在的配置。當(dāng)然，如果需要，你隨時可以用相同的命令修改已有的配置。Git 提供了一個叫做git config 的工具，專門用來配置或讀取相應(yīng)的工作環(huán)境變量。而正是由這些環(huán)境變量，決定了Git 在各個環(huán)節(jié)的具體工作方式和行為。這些變量可以存放在以下三個不同的地方： /etc/gitconfig文件：系統(tǒng)中對所有用戶都普遍適用的配置。若使用git config 時用-system 選項，讀寫的就是這個文件。 /.gitconfig文件：用戶目錄下的配置文件只適用于該用戶。若使用git config 時

13、用-global 選項，讀寫的就是這個文件。 當(dāng)前項目的git 目錄中的配置文件（也就是工作目錄中的.git/config 文件）：這里的配置僅僅針對當(dāng)前項目有效。每一個級別的配置都會覆蓋上層的相同配置，所以.git/config 里的配置會覆蓋/etc/gitconfig 中的同名變量。在Windows 系統(tǒng)上，Git 會找尋用戶主目錄下的.gitconfig 文件。主目錄即$HOME 變量指定的目錄，一般都是C:Documents and Settings$USER。此外，Git 還會嘗試找尋/etc/gitconfig 文件，只不過看當(dāng)初Git 裝在什么目錄，就以此作為根目錄來定位。初次

14、運行Git 前的配置用戶信息用戶信息第一個要配置的是你個人的用戶名稱和電子郵件地址。這兩條配置很重要，每次Git 提交時都會引用這兩條信息，說明是誰提交了更新，所以會隨更新內(nèi)容一起被永久納入歷史記錄：$ git config -global John Doe$ git config -global user.email 如果用了-global 選項，那么更改的配置文件就是位于你用戶主目錄下的那個，以后你所有的項目都會默認(rèn)使用這里配置的用戶信息。如果要在某個特定的項目中使用其他名字或者電郵，只要去掉-global 選項重新配置即可，新的設(shè)定保存在當(dāng)前項目的.git/confi

15、g文件里。初次運行Git 前的配置查看配置信息查看配置信息要檢查已有的配置信息，可以使用git config -list 命令：$ git config -=yaolunuser.email=color.status=autocolor.branch=eractive=autocolor.diff=auto.有時候會看到重復(fù)的變量名，那就說明它們來自不同的配置文件（比如/etc/gitconfig和/.gitconfig），不過最終Git 實際采用的是最后一個。也可以直接查閱某個環(huán)境變量的設(shè)定，只要把特定的名字跟在后面即可，像這樣：$ git

16、 config yaolunGit基礎(chǔ)-取得項目的Git倉庫要對現(xiàn)有的某個項目開始用Git 管理，只需到此項目所在的目錄，執(zhí)行：$ git init初始化后，在當(dāng)前目錄下會出現(xiàn)一個名為.git 的目錄，所有Git 需要的數(shù)據(jù)和資源都存放在這個目錄中。不過目前，僅僅是按照既有的結(jié)構(gòu)框架初始化好了里邊所有的文件和目錄，但我們還沒有開始跟蹤管理項目中的任何一個文件。如果當(dāng)前目錄下有幾個文件想要納入版本控制，需要先用git add 命令告訴Git 開始對這些文件進(jìn)行跟蹤，然后提交：$ git add *.c$ git add README$ git commit -m initial

17、 project version有兩種取得Git 項目倉庫的方法。第一種是在現(xiàn)存的目錄下，通過導(dǎo)入所有文件來創(chuàng)建新的Git 倉庫。第二種是從已有的Git 倉庫克隆出一個新的鏡像倉庫來。 從當(dāng)前目錄初始化Git基礎(chǔ)-取得項目的Git 倉庫如果想把已有項目的Git 倉庫復(fù)制一份出來，這就需要用到git clone 命令。這個命令不像Subversion，使用的是clone 而不是checkout。這是個非常重要的差別，Git 收取的是項目歷史的所有數(shù)據(jù)（每一個文件的每一個版本），服務(wù)器上有的數(shù)據(jù)克隆之后本地也都有了。實際上，即便服務(wù)器的磁盤發(fā)生故障，用任何一個克隆出來的客戶端都可以重建服務(wù)器上的倉

18、庫，回到當(dāng)初克隆時的狀態(tài)。克隆倉庫的命令格式為git clone url。比如，要克隆Ruby 語言的Git 代碼倉庫Grit，可以用下面的命令：$ git clone git:/ 的目錄，其中內(nèi)含一個.git 的目錄，并從同步后的倉庫中拉出所有的數(shù)據(jù)，取出最新版本的文件拷貝。如果進(jìn)入這個新建的grit 目錄，你會看到項目中的所有文件已經(jīng)在里邊了，準(zhǔn)備好后續(xù)的開發(fā)和使用。如果希望在克隆的時候，自己定義要新建的項目目錄名稱，可以在上面的命令最后指定：$ git clone git:/ mygrit唯一的差別就是，現(xiàn)在新建的目錄成了mygrit，其他的都和上邊的一樣。從現(xiàn)有倉庫克隆Git基礎(chǔ)-記錄

19、每次更新到倉庫工作目錄下面的所有文件都不外乎這兩種狀態(tài)：已跟蹤或未跟蹤。已跟蹤的文件是指本來就被納入版本控制管理的文件，在上次快照中有它們的記錄，工作一段時間后，它們的狀態(tài)可能是未更新，已修改或者已放入暫存區(qū)。而所有其他文件都屬于未跟蹤文件。它們既沒有上次更新時的快照，也不在當(dāng)前的暫存區(qū)域。初次克隆某個倉庫時，工作目錄中的所有文件都屬于已跟蹤文件，且狀態(tài)為未修改。在編輯過某些文件之后，Git 將這些文件標(biāo)為已修改。我們逐步把這些修改過的文件放到暫存區(qū)域，然后等最后一次性提交暫存區(qū)域的所有文件更新，如此重復(fù)。所以使用Git 時的文件狀態(tài)變化周期如右圖。Git基礎(chǔ)-記錄每次更新到倉庫 檢查當(dāng)前文件

20、狀態(tài)要確定哪些文件當(dāng)前處于什么狀態(tài)，可以用git status 命令。如果在克隆倉庫之后立即執(zhí)行此命令，會看到類似這樣的輸出：$ git status# On branch master# Untracked files:# (use git add . to include in what will be committed)# READMEnothing added to commit but untracked files present (use git add to track)$ git status# On branch masternothing to commit (work

21、ing directory clean)Git基礎(chǔ)-記錄每次更新到倉庫 跟蹤新文件使用命令git add 開始跟蹤一個新文件。所以，要跟蹤README 文件，運行：$ git add README此時再運行g(shù)it status 命令，會看到README 文件已被跟蹤，并處于暫存狀態(tài)：$ git status# On branch master# Changes to be committed:# (use git reset HEAD . to unstage)# new file: README只要在“Changes to be committed” 這行下面的，就說明是已暫存狀態(tài)。如果此時

22、提交，那么該文件此時此刻的版本將被留存在歷史記錄中。git add 后可以接要跟蹤的文件或目錄的路徑。如果是目錄的話，就說明要遞歸跟蹤所有該目錄下的文件。Git基礎(chǔ)-記錄每次更新到倉庫 暫存已修改文件現(xiàn)在我們修改下之前已跟蹤過的文件benchmarks.rb，然后再次運行status 命令，會看到這樣的狀態(tài)報告$ git status# On branch master# Changes to be committed:# (use git reset HEAD . to unstage)# new file: README# Changed but not updated:# (use gi

23、t add . to update what will be committed)# modified: benchmarks.rb#Git基礎(chǔ)-記錄每次更新到倉庫文件benchmarks.rb 出現(xiàn)在“Changed but not updated” 這行下面，說明已跟蹤文件的內(nèi)容發(fā)生了變化，但還沒有放到暫存區(qū)。要暫存這次更新，需要運行g(shù)it add 命令（這是個多功能命令，根據(jù)目標(biāo)文件的狀態(tài)不同，此命令的效果也不同：可以用它開始跟蹤新文件，或者把已跟蹤的文件放到暫存區(qū)，還能用于合并時把有沖突的文件標(biāo)記為已解決狀態(tài)等）。現(xiàn)在讓我們運行g(shù)it add 將benchmarks.rb 放到暫存區(qū)，

24、然后再看看git status的輸出：$ git add benchmarks.rb$ git status# On branch master# Changes to be committed:# (use git reset HEAD . to unstage)# new file: README# modified: benchmarks.rbGit基礎(chǔ)-記錄每次更新到倉庫現(xiàn)在兩個文件都已暫存，下次提交時就會一并記錄到倉庫。假設(shè)此時，你想要在benchmarks.rb 里再加條注釋，重新編輯存盤后，準(zhǔn)備好提交。不過且慢，再運行g(shù)it status看看：$ vim benchmarks.r

25、b$ git status# On branch master# Changes to be committed:# (use git reset HEAD . to unstage)# new file: README# modified: benchmarks.rb# Changed but not updated:# (use git add . to update what will be committed)# modified: benchmarks.rb#benchmarks.rb 文件出現(xiàn)了兩次??？實際上Git 只不過暫存了你運行g(shù)it add 命令時的版本，如果現(xiàn)在提交，那么

26、提交的是添加注釋前的版本，而非當(dāng)前工作目錄中的版本。所以，運行了git add 之后又作了修訂的文件，需要重新運行g(shù)it add 把最新版本重新暫存起來。Git基礎(chǔ)-記錄每次更新到倉庫 忽略某些文件一般我們總會有些文件無需納入Git 的管理，也不希望它們總出現(xiàn)在未跟蹤文件列表。通常都是些自動生成的文件，像是日志或者編譯過程中創(chuàng)建的等等。我們可以創(chuàng)建一個名為.gitignore 的文件，列出要忽略的文件模式。文件.gitignore 的格式規(guī)范如下： 所有空行或者以注釋符號 開頭的行都會被Git 忽略。 可以使用標(biāo)準(zhǔn)的glob 模式匹配。 匹配模式最后跟反斜杠（/）說明要忽略的是目錄。 要忽略指

27、定模式以外的文件或目錄，可以在模式前加上驚嘆號（!）取反所謂的glob 模式是指shell 所使用的簡化了的正則表達(dá)式。星號（*）匹配零個或多個任意字符；abc 匹配任何一個列在方括號中的字符（這個例子要么匹配一個a，要么匹配一個b，要么匹配一個c）；問號（?）只匹配一個任意字符；如果在方括號中使用短劃線分隔兩個字符，表示所有在這兩個字符范圍內(nèi)的都可以匹配（比如0-9 表示匹配所有0到9的數(shù)字）。例如：# 此為注釋 將被Git 忽略*.a # 忽略所有.a 結(jié)尾的文件!lib.a # 但lib.a 除外/TODO # 僅僅忽略項目根目錄下的TODO 文件，不包括subdir/TODObuild

28、/ # 忽略build/ 目錄下的所有文件doc/*.txt # 會忽略doc/notes.txt 但不包括doc/server/arch.txGit基礎(chǔ)-記錄每次更新到倉庫 查看已暫存和未暫存的更新實際上git status 的顯示比較簡單，僅僅是列出了修改過的文件，如果要查看具體修改了什么地方，可以用git diff 命令。$ git diff此命令比較的是工作目錄中當(dāng)前文件和暫存區(qū)域快照之間的差異，也就是修改之后還沒有暫存起來的變化內(nèi)容。若要看已經(jīng)暫存起來的文件和上次提交時的快照之間的差異，可以用git diff -cached命令。(Git 1.6.1 及更高版本還允許使用git di

29、ff -staged，效果相同)，效果如下：$ git diff -cacheddiff -git a/README b/READMEnew file mode 100644index 0000000.03902a1- /dev/null+ b/README2 -0,0 +1,5 +grit+ by Tom Preston-Werner, Chris Wanstrath+ http:/ is a Ruby library for extracting information from a Git repositoryGit基礎(chǔ)-記錄每次更新到倉庫 提交更新每次準(zhǔn)備提交前，先用git statu

30、s 看下，是不是都已暫存起來了，然后再運行提交命令：git commit這種方式會啟動文本編輯器以便輸入本次提交的說明。（默認(rèn)會啟用shell 的環(huán)境變量$EDITOR 所指定的軟件，一般都是vim 或emacs。也可以使用git config -global core.editor 命令設(shè)定你喜歡的編輯軟件。）。編輯器會顯示類似下面的文本信息（本例選用Vim 的屏顯方式展示）：# Please enter the commit message for your changes. Lines starting# with # will be ignored, and an empty mess

31、age aborts the commit.# On branch master# Changes to be committed:# (use git reset HEAD . to unstage)# new file: README# modified: benchmarks.rb.git/COMMIT_EDITMSG 10L, 283C也可以使用-m 參數(shù)后跟提交說明的方式，在一行命令中提交更新：$ git commit -m Story 182: Fix benchmarks for speedmaster: created 463dc4f: Fix benchmarks for s

32、peed2 files changed, 3 insertions(+), 0 deletions(-)create mode 100644 READMEGit基礎(chǔ)-記錄每次更新到倉庫 跳過使用暫存區(qū)域盡管使用暫存區(qū)域的方式可以精心準(zhǔn)備要提交的細(xì)節(jié)，但有時候這么做略顯繁瑣。Git 提供了一個跳過使用暫存區(qū)域的方式，只要在提交的時候，給git commit 加上-a 選項，Git就會自動把所有已經(jīng)跟蹤過的文件暫存起來一并提交，從而跳過git add 步驟： 移除文件要從Git 中移除某個文件，就必須要從已跟蹤文件清單中移除（確切地說，是從暫存區(qū)域移除），然后提交?？梢杂胓it rm 命令完成此項

33、工作，并連帶從工作目錄中刪除指定的文件，這樣以后就不會出現(xiàn)在未跟蹤文件清單中了。最后提交的時候，該文件就不再納入版本管理了。如果刪除之前修改過并且已經(jīng)放到暫存區(qū)域的話，則必須要用強(qiáng)制刪除選項-f，以防誤刪除文件后丟失修改的內(nèi)容。另外一種情況是，我們想把文件從Git 倉庫中刪除（亦即從暫存區(qū)域移除），但仍然希望保留在當(dāng)前工作目錄中。換句話說，僅是從跟蹤清單中刪除。比如一些大型日志文件或者一堆.a 編譯文件，不小心納入倉庫后，要移除跟蹤但不刪除文件，以便稍后在.gitignore文件中補(bǔ)上，用-cached 選項即可：$ git rm -cached readme.txt后面可以列出文件或者目錄的

34、名字，也可以使用glob 模式。比方說：$ git rm log/*.log$ git rm *Git基礎(chǔ)-記錄每次更新到倉庫 移動文件不像其他的版本控制，Git 并不跟蹤文件移動操作。如果在Git 中重命名了某個文件，不過Git 非常聰明，它會推斷出究竟發(fā)生了什么。既然如此，當(dāng)你看到Git 的mv 命令時一定會困惑不已。要在Git 中對文件改名，可以這么做：$ git mv file_from file_to實際上，即便此時查看狀態(tài)信息，也會明白無誤地看到關(guān)于重命名操作的說明：$ git mv README.txt README$ git status# On branch master#

35、Your branch is ahead of origin/master by 1 commit.# Changes to be committed:# (use git reset HEAD . to unstage)# renamed: README.txt - README#其實，運行g(shù)it mv 就相當(dāng)于運行了下面三條命令：$ mv README.txt README$ git rm README.txt$ git add README如此分開操作，Git 也會意識到這是一次改名，所以不管何種方式都一樣。當(dāng)然，直接用git mv 輕便得多，不過有時候用其他工具批處理改名的話，要記得在

36、提交前刪除老的文件名，再添加新的文件名。Git基礎(chǔ)-查看提交歷史在提交了若干更新之后，又或者克隆了某個項目，想回顧下提交歷史，可以使用git log命令。默認(rèn)不用任何參數(shù)的話，git log 會按提交時間列出所有的更新，最近的更新排在最上面。看到了嗎，每次更新都有一個SHA-1 校驗和、作者的名字和電子郵件地址、提交時間，最后縮進(jìn)一個段落顯示提交說明。另外，git log命令非常強(qiáng)在d，可通過添加命令參數(shù)，輸出你想要的任何信息。具體命令選項可執(zhí)行g(shù)it log help獲取幫助。Git基礎(chǔ)-撤消操作任何時候，你都有可能需要撤消剛才所做的某些操作。請注意，有些操作并不總是可以撤消的，所以請務(wù)必謹(jǐn)

37、慎小心，一旦失誤，就有可能丟失部分工作成果。 修改最后一次提交有時候我們提交完了才發(fā)現(xiàn)漏掉了幾個文件沒有加，或者提交信息寫錯了。想要撤消剛才的提交操作，可以使用-amend 選項重新提交：$ git commit -amend 取消已經(jīng)暫存的文件如何取消暫存區(qū)域中的文件，以及如何取消工作目錄中已修改的文件。比如，有兩個修改過的文件，我們想要分開提交，但不小心用git add * 全加到了暫存區(qū)域。該如何撤消暫存其中的一個文件呢？git status 命令的輸出會告訴你怎么做：$ git add .$ git status# On branch master# Changes to be com

38、mitted:# (use git reset HEAD . to unstage)# modified: README.txt# modified: benchmarks.rb#就在“Changes to be committed” 下面，括號中有提示，可以使用git reset HEAD . 的方式取消暫存Git基礎(chǔ)-撤消操作 取消對文件的修改如果覺得某個文件的修改完全沒有必要，該如何取消修改，回到之前的狀態(tài)（也就是修改之前的版本）呢？git status 同樣提示了具體的撤消方法，比如，現(xiàn)在未暫存區(qū)域看起來像這樣：# Changed but not updated:# (use git

39、add . to update what will be committed)# (use git checkout - . to discard changes in working directory)# modified: benchmarks.rbGit基礎(chǔ)-遠(yuǎn)程倉庫的使用 查看當(dāng)前的遠(yuǎn)程庫 要參與任何一個Git 項目的協(xié)作，必須要了解該如何管理遠(yuǎn)程倉庫。遠(yuǎn)程倉庫是指托管在網(wǎng)絡(luò)上的項目倉庫，可能會有好多個，其中有的可讀，有的可寫。同他人協(xié)作開發(fā)某個項目時，需要管理這些遠(yuǎn)程倉庫，以便推送或拉取數(shù)據(jù)，分享各自的工作進(jìn)展。管理遠(yuǎn)程倉庫的工作，包括添加遠(yuǎn)程庫，移除廢棄的遠(yuǎn)程庫，管理各式遠(yuǎn)程庫分

40、支，定義是否跟蹤這些分支等。 要查看當(dāng)前配置有哪些遠(yuǎn)程倉庫，可以用git remote 命令，它會列出每個遠(yuǎn)程庫的簡短名字。在克隆完某個項目后，至少可以看到一個名為origin 的遠(yuǎn)程庫，Git 默認(rèn)使用這個名字來標(biāo)識你所克隆的原始倉庫，也可以加上-v 選項（譯注：此為verbose 的簡寫，取首字母），顯示對應(yīng)的克隆地址。如果有多個遠(yuǎn)程倉庫，此命令將所有遠(yuǎn)程倉庫全部列出。Git基礎(chǔ)-遠(yuǎn)程倉庫的使用 添加遠(yuǎn)程倉庫要添加一個新的遠(yuǎn)程倉庫，可以指定一個簡單的名字，以便將來引用，運行g(shù)it remote add shortname url例如：$ git remoteorigin$ git remo

41、te add pb git:/ git remote -vorigin git:/ git:/ 指代對應(yīng)的倉庫地址了。比如說，要抓取所有Paul 有的，但本地倉庫沒有的信息，可以運行g(shù)it fetch pb：$ git fetch pbremote: Counting objects: 58, done.remote: Compressing objects: 100% (41/41), done.remote: Total 44 (delta 24), reused 1 (delta 0)Unpacking objects: 100% (44/44), done.From git:/ new

42、 branch master - pb/masternew branch ticgit - pb/ticgit現(xiàn)在，Paul 的主干分支（master）已經(jīng)完全可以在本地訪問了，對應(yīng)的名字是pb/master，你可以將它合并到自己的某個分支，或者切換到這個分支，做一些操作。Git基礎(chǔ)-遠(yuǎn)程倉庫的使用 從遠(yuǎn)程倉庫抓取數(shù)據(jù)下面的命令從遠(yuǎn)程倉庫抓取數(shù)據(jù)到本地：$ git fetch remote-name此命令會到遠(yuǎn)程倉庫中拉取所有你本地倉庫中還沒有的數(shù)據(jù)。運行完成后，你就可以在本地訪問該遠(yuǎn)程倉庫中的所有分支，將其中某個分支合并到本地，或者只是取出某個分支。如果是克隆了一個倉庫，此命令會自動將遠(yuǎn)程倉

43、庫歸于origin 名下。所以，git fetch origin 會抓取從你上次克隆以來別人上傳到此遠(yuǎn)程倉庫中的所有更新（或是上次fetch 以來別人提交的更新）。需要記住的是，fetch 命令只是將遠(yuǎn)端的數(shù)據(jù)拉到本地倉庫，并不自動合并到當(dāng)前工作分支，只有當(dāng)你確實準(zhǔn)備好了，才能手工合并。如果設(shè)置了某個分支用于跟蹤某個遠(yuǎn)端倉庫的分支，可以使用git pull 命令自動抓取數(shù)據(jù)下來，然后將遠(yuǎn)端分支自動合并到本地倉庫中當(dāng)前分支。在日常工作中我們經(jīng)常使用，既快且好。實際上，默認(rèn)情況下git clone 命令本質(zhì)上就是自動創(chuàng)建了本地的master 分支用于跟蹤遠(yuǎn)程倉庫中的master 分支（假設(shè)遠(yuǎn)程倉庫

44、確實有master 分支）。所以一般我們運行g(shù)it pull，目的都是要從原始克隆的遠(yuǎn)端倉庫中抓取數(shù)據(jù)后，合并到工作目錄中當(dāng)前分支。Git基礎(chǔ)-遠(yuǎn)程倉庫的使用 推送數(shù)據(jù)到遠(yuǎn)程倉庫項目進(jìn)行到一個階段，要同別人分享目前的成果，可以將本地倉庫中的數(shù)據(jù)推送到遠(yuǎn)程倉庫。實現(xiàn)這個任務(wù)的命： git push remote-name branch-name。如果要把本地的master 分支推送到origin 服務(wù)器上（再次說明下，克隆操作會自動使用默認(rèn)的master 和origin 名字），可以運行下面的命令：$ git push origin master只有在所克隆的服務(wù)器上有寫權(quán)限，或者同一時刻沒有其

45、他人在推數(shù)據(jù)，這條命令才會如期完成任務(wù)。如果在你推數(shù)據(jù)前，已經(jīng)有其他人推送了若干更新，那你的推送操作就會被駁回。你必須先把他們的更新抓取到本地，并到自己的項目中，然后才可以再次推送。Git基礎(chǔ)-遠(yuǎn)程倉庫的使用 查看遠(yuǎn)程倉庫信息我們可以通過命令git remote show remote-name 查看某個遠(yuǎn)程倉庫的詳細(xì)信息，比如要看所克隆的origin 倉庫，可以運行：$ git remote show origin除了對應(yīng)的克隆地址外，它還給出了許多額外的信息。它友善地告訴你如果是在master分支，就可以用git pull 命令抓取數(shù)據(jù)合并到本地。另外還列出了所有處于跟蹤狀態(tài)中的遠(yuǎn)端分支。

46、它告訴我們，運行g(shù)it push 時缺省推送的分支是什么（譯注：最后兩行）。它還顯示了有哪些遠(yuǎn)端分支還沒有同步到本地，哪些已同步到本地的遠(yuǎn)端分支在遠(yuǎn)端服務(wù)器上已被刪除，以及運行g(shù)it pull 時將自動合并哪些分支。Git基礎(chǔ)-遠(yuǎn)程倉庫的使用 遠(yuǎn)程倉庫的刪除和重命名在新版Git 中可以用git remote rename 命令修改某個遠(yuǎn)程倉庫的簡短名稱，比如想把pb 改成paul，可以這么運行：$ git remote rename pb paul$ git remoteoriginpaul注意，對遠(yuǎn)程倉庫的重命名，也會使對應(yīng)的分支名稱發(fā)生變化，原來的pb/master 分支現(xiàn)在成了paul/

47、master。碰到遠(yuǎn)端倉庫服務(wù)器遷移，或者原來的克隆鏡像不再使用，又或者某個參與者不再貢獻(xiàn)代碼，那么需要移除對應(yīng)的遠(yuǎn)端倉庫，可以運行g(shù)it remote rm 命令：$ git remote rm paul$ git remoteoriginGit基礎(chǔ)-打標(biāo)簽 列顯已有的標(biāo)簽同大多數(shù)版本控制系統(tǒng)一樣，Git也可以對某一時間點上的版本打上標(biāo)簽。人們在發(fā)布某個軟件版本（比如v1.0 等等）的時候，經(jīng)常這么做。那么，如何列出所有可用的標(biāo)簽？如何新建標(biāo)簽？以及各種不同類型標(biāo)簽之間的差別？列出現(xiàn)有標(biāo)簽的命令非常簡單，直接運行g(shù)it tag 即可：$ git tagv0.1v1.3顯示的標(biāo)簽按字母順序排列

48、，所以標(biāo)簽的先后并不表示重要程度的輕重。我們可以用特定的搜索模式列出符合條件的標(biāo)簽。在Git 自身項目倉庫中，有著超過240 個標(biāo)簽，如果你只對1.4.2 系列的版本感興趣，可以運行下面的命令：$ git tag -l v1.4.2.*vvvvGit基礎(chǔ)-打標(biāo)簽 新建標(biāo)簽Git 使用的標(biāo)簽有兩種類型：輕量級的（lightweight）和含附注的（annotated）。輕量級標(biāo)簽就像是個不會變化的分支，實際上它就是個指向特定提交對象的引用。而含附注標(biāo)簽，實際上是存儲在倉庫中的一個獨立對象，它有自身的校驗和信息，包含著標(biāo)簽的名字，電子郵件地址

49、和日期，以及標(biāo)簽說明，標(biāo)簽本身也允許使用GNU Privacy Guard (GPG) 來簽署或驗證。一般我們都建議使用含附注型的標(biāo)簽，以便保留相關(guān)信息；當(dāng)然，如果只是臨時性加注標(biāo)簽，或者不需要旁注額外信息，用輕量級標(biāo)簽也沒問題。 含附注的標(biāo)簽創(chuàng)建一個含附注類型的標(biāo)簽非常簡單，用-a指定標(biāo)簽名字即可：$ git tag -a v1.4 -m my version 1.4而-m 選項則指定了對應(yīng)的標(biāo)簽說明，Git 會將此說明一同保存在標(biāo)簽對象中?？梢允褂胓it show 命令查看相應(yīng)標(biāo)簽的版本信息，并連同顯示打標(biāo)簽時的提交對象。$ git show v1.4這時，我們可以看到在提交對象信息上面，

50、列出了此標(biāo)簽的提交者和提交時間，以及相應(yīng)的標(biāo)簽說明。Git基礎(chǔ)-打標(biāo)簽 輕量級標(biāo)簽輕量級標(biāo)簽實際上就是一個保存著對應(yīng)提交對象的校驗和信息的文件。要創(chuàng)建這樣的標(biāo)簽，一個-a，-s 或-m 選項都不用，直接給出標(biāo)簽名字即可：$ git tag v1.4-lw$ git tagv0.1v1.4v1.4-lw 后期加注標(biāo)簽?zāi)闵踔量梢栽诤笃趯υ缦鹊哪炒翁峤患幼?biāo)簽。比如在下面展示的提交歷史中：$ git log -pretty=onelin64cf874c3557a0f3547bd83b3ff6 Merge branch experimenta6b4c97498bd301d84

51、096da251c98a07c7723e65 beginning write support我們忘了在提交“beginning write support” 后為此項目打上版本號v1.2，沒關(guān)系，現(xiàn)在也能做。只要在打標(biāo)簽的時候跟上對應(yīng)提交對象的校驗和（或前8位字符）即可：$ git tag -a v1.2 9fceb02Git基礎(chǔ)-打標(biāo)簽 分享標(biāo)簽?zāi)J(rèn)情況下，git push 并不會把標(biāo)簽傳送到遠(yuǎn)端服務(wù)器上，只有通過顯式命令才能分享標(biāo)簽到遠(yuǎn)端倉庫。其命令格式如同推送分支，運行g(shù)it push origin tagname 即可：$ git push origin v1.5如果要一次推送所有（本

52、地新增的）標(biāo)簽上去，可以使用-tags 選項：$ git push origin -tags現(xiàn)在，其他人克隆共享倉庫或拉取數(shù)據(jù)同步后，也會看到這些標(biāo)簽。Git基礎(chǔ)-技巧與竅門 自動完成在輸入Git 命令的時候可以敲兩次跳格鍵（Tab），就會看到列出所有匹配的可用命令建議：$ git cocommit config$ git log -s-shortstat -since= -src-prefix= -stat -summary Git 命令別名Git 并不會推斷你輸入的幾個字符將會是哪條命令，不過可以用git config 為命令設(shè)置別名。來看看下面的例子：$ git config -glob

53、al alias.co checkout$ git config -global alias.br branch現(xiàn)在，如果要輸入git commit 只需鍵入git ci 即可。使用這種技術(shù)還可以創(chuàng)造出新的命令，比方說取消暫存文件時的輸入比較繁瑣，可以自己設(shè)置一下：$ git config -global alias.unstage reset HEAD -這樣，兩個指令等同：$ git unstage fileA$ git reset HEAD fileA顯然，使用別名的方式看起來更清楚。另外，我們還經(jīng)常設(shè)置last 命令：$ git config -global alias.last lo

54、g -1 HEAD然后要看最后一次的提交信息，就變得簡單多了：Git進(jìn)階-何謂分支？ 幾乎每一種版本控制系統(tǒng)都以某種形式支持分支，Git也不例外。而有的版本控制系統(tǒng)中，這是個復(fù)雜的過程，常常需要創(chuàng)建一個源代碼目錄的完整副本，對大型項目來說會花費很長時間。 Git 的分支可謂是難以置信的輕量級，它的新建操作幾乎可以在瞬間完成，并且在不同分支間切換起來也差不多一樣快。和許多其他版本控制系統(tǒng)不同，Git 鼓勵在工作流程中頻繁使用分支與合并，哪怕一天之內(nèi)進(jìn)行許多次都沒有關(guān)系。 了解一下Git是如何存儲數(shù)據(jù)的。一次提交后倉庫里的數(shù)據(jù)多次提交后的Git 對象數(shù)據(jù)Git進(jìn)階-何謂分支？Git 中的分支，其實

55、本質(zhì)上僅僅是個指向commit 對象的可變指針。Git會使用master 作為分支的默認(rèn)名字。在若干次提交后，你其實已經(jīng)有了一個指向最后一次提交對象的master 分支，它在每次提交的時候都會自動向前移動。指向提交數(shù)據(jù)歷史的分支$ git branch testing多個分支指向提交數(shù)據(jù)的歷史Git進(jìn)階-何謂分支？Git 是如何知道你當(dāng)前在哪個分支上工作的呢？HEAD 指向當(dāng)前所在的分支Git進(jìn)階-何謂分支？$ git checkout testingHEAD 在你轉(zhuǎn)換分支時指向新的分支每次提交后HEAD 隨著分支一起向前移動Git進(jìn)階-基本的分支與合并現(xiàn)在讓我們來看一個簡單的分支與合并的例子

56、，實際工作中大體也會用到這樣的工作流程：1. 開發(fā)某個項目。2. 為實現(xiàn)某個新的需求，創(chuàng)建一個分支。3. 在這個分支上開展工作。假設(shè)此時，你突然接到生產(chǎn)部一個電話說有個很嚴(yán)重的問題需要緊急修補(bǔ)，那么可以按照下面的方式處理：1. 返回到原先已經(jīng)發(fā)布到生產(chǎn)服務(wù)器上的分支。2. 為這次緊急修補(bǔ)建立一個新分支。3. 測試通過后，將此修補(bǔ)分支合并，再推送到生產(chǎn)服務(wù)器上。4. 切換到之前實現(xiàn)新需求的分支，繼續(xù)工作。Git進(jìn)階-基本的分支與合并 基本分支決定要修補(bǔ)問題追蹤系統(tǒng)上的#53問題。新建的分支取名為iss53。要新建并切換到該分支，運行g(shù)it checkout 并加上-b 參數(shù)：$ git chec

57、kout -b iss53Switched to a new branch iss53“相當(dāng)于下面這兩條命令：$ git branch iss53$ git checkout iss53一部分提交歷史創(chuàng)建了一個新的分支指針iss53 分支隨工作進(jìn)展向前推進(jìn)Git進(jìn)階-基本的分支與合并現(xiàn)在你接到了這個項目問題的緊急電話，需要馬上修補(bǔ)！OK，切換回master 分支。不過在此之前，留心你的暫存區(qū)或者工作目錄里，那些還沒有提交的修改，它會和你即將檢出的分支產(chǎn)生沖突從而阻止Git 為你轉(zhuǎn)換分支。轉(zhuǎn)換到master 分支：$ git checkout masterSwitched to branch master“接下來，你得進(jìn)行緊急修補(bǔ)。我們創(chuàng)建一個緊急修補(bǔ)分支（hotfix）來開展