Git(讀音為/g?t/。)是一個開源的分布式版本控制系統，可以有效、高速地處理從很小到非常大的項目版本管理。 Git是Linus Torvalds為了幫助管理Linux內核開發版本而開發的一個開放源碼的版本控制軟件。
Torvalds開始著手開發Git是為了作為一種過渡方案來替代BitKeeper。
軟件特點
分布式相比于集中式的最大區別在于開發者可以提交到本地，每個開發者通過克隆（git clone），在本地機器上拷貝一個完整的Git倉庫。
圖1是經典的git開發過程。
Git的功能特性：
從一般開發者的角度來看，git有以下功能：
1、從服務器上克隆完整的Git倉庫（包括代碼和版本信息）到單機上。
2、在自己的機器上根據不同的開發目的，創建分支，修改代碼。
3、在單機上自己創建的分支上提交代碼。
4、在單機上合并分支。
5、把服務器上最新版的代碼fetch下來，然后跟自己的主分支合并。
6、生成補丁（Patch），把補丁發送給主開發者。
7、看主開發者的反饋，如果主開發者發現兩個一般開發者之間有沖突（他們之間可以合作解決的沖突），就會要求他們先解決沖突，然后再由其中一個人提交。如果主開發者可以自己解決，或者沒有沖突，就通過。
8、一般開發者之間解決沖突的方法，開發者之間可以使用pull 命令解決沖突，解決完沖突之后再向主開發者提交補丁。
從主開發者的角度（假設主開發者不用開發代碼）看，git有以下功能：
1、查看郵件或者通過其它方式查看一般開發者的提交狀態。
2、打上補丁，解決沖突（可以自己解決，也可以要求開發者之間解決以后再重新提交，如果是開源項目，還要決定哪些補丁有用，哪些不用）。
3、向公共服務器提交結果，然后通知所有開發人員。
優點：
適合分布式開發，強調個體。
公共服務器壓力和數據量都不會太大。
速度快、靈活。
任意兩個開發者之間可以很容易的解決沖突。
離線工作。
缺點：
資料少（起碼中文資料很少）。
學習周期相對而言比較長。
不符合常規思維。
代碼保密性差，一旦開發者把整個蒂姆·庫克隆下來就可以完全公開所有代碼和版本信息。
軟件介紹
Git---The stupid content tracker, 傻瓜內容跟蹤器。Linus Torvalds是這樣給大眾介紹Git的。
Git是用于Linux內核開發的版本控制工具。與常用的版本控制工具CVS, Subversion等不同，它采用了分布式版本庫的方式，不必服務器端軟件支持（wingeddevil注：這得分是用什么樣的服務端，使用http協議或者git協議等不太一樣。并且在push和pull的時候和服務器端還是有交互的。），使源代碼的發布和交流極其方便。 Git的速度很快，這對于諸如 Linux kernel 這樣的大項目來說自然很重要。 Git最為出色的是它的合并跟蹤（merge tracing）能力。
實際上內核開發團隊決定開始開發和使用Git來作為內核開發的版本控制系統的時候，世界開源社群的反對聲音不少，最大的理由是Git太艱澀難懂，從Git的內部工作機制來說，的確是這樣。但是隨著開發的深入，Git的正常使用都由一些友好的腳本命令來執行，使 Git 變得非常好用，即使是用來管理自己的開發項目，Git都是一個友好，有力的工具。現在，越來越多的著名項目采用Git來管理項目開發.
作為開源自由原教旨主義項目，Git 沒有對版本庫的瀏覽和修改做任何的權限限制。
GIT已經可以在windows下使用，主要方法有二：msysgit和Cygwin。Cygwin和Linux使用方法類似，Windows版本的GIT提供了友好的GUI(圖形界面)，安裝后很快可以上手。
軟件版本
軟件使用
創建版本庫
創建一個版本庫：
( kwydwuf注: 新版git中應該用git init，不要再用init-db命令，具體可以通過命令git help init查看)
現在為本文的寫作創建一個版本庫：
git將會作出以下的回應：
這樣，一個空的版本庫就創建好了，并在當前目錄中創建一個叫 .git 的子目錄。可用ls -a查看，并請注意其中的三項內容：
* 一個叫HEAD的文件：
現在HEAD的內容應該是這樣：
可以看到，HEAD文件中的內容其實只是包含了一個索引信息，并且，這個索引將總是指向項目中的當前開發分支。
* 一個叫objects的子目錄，它包含了項目中的所有對象，不必直接地了解到這些對象內容，應該關心是存放在這些對象中的項目的數據。
Note
關于git對象的分類，以及git對象數據庫的說明。
* 一個叫ReFS的子目錄，它用來保存指向對象的索引。
具體地說，子目錄refs包含著兩個子目錄叫heads和tags，就像他們的名字所表達的意味一樣：他們存放了不同的開發分支的頭的索引, 是用來標定版本的標簽的索引。
請注意：master是默認的分支，這也是為什么 .git/HEAD 創建的時候就指向master的原因，盡管它其實并不存在。 git將假設用戶會在master上開始并展開以后的工作，除非用戶創建自己的分支。
另外，這只是一個約定俗成的習慣而已，實際上自定義分支的名字，而不必在版本庫中一定要有一個叫master的分支，盡管很多git工具都認為master分支是存在的。
創建好的git版本庫是空的，還不能做任何事情，需要用戶自己向版本庫植入數據。
增加內容
增加內容跟蹤信息：git add
為了簡明起見創建兩個文件作為練習：
再用git add 命令將這兩個文件加入到版本庫文件索引當中：
git add 實際上是個腳本命令，它是對git內核命令git update-index 的調用。因此上面的命令和下面的命令其實是等價的：
如果用戶要將某個文件從 git 的目錄跟蹤系統中清除出去，同樣可以用 git update-index 命令。例如：
Note
git add 可以將某個目錄下的所有內容全都納入內容跟蹤之下，例如： git add ./path/to/your/wanted。但是在這樣做之前，應該注意先將一些不希望跟蹤的文件清理掉，例如，GCC 編譯出來的 *.o 文件，vim 的交換文件 .*.swp 之類。
應該建立一個清晰的概念就是，git add 和 git update-index 只是刷新了 git 的跟蹤信息，hello 和 snake 這兩個文件中的內容并沒有提交到 git 的內容跟蹤范疇之內。
普通用戶總是應該使用 git add，而不要使用上面提到的 update-index內部命令。
添加所有未跟蹤文件用 git add -A, 添加所有未跟蹤文件并且提交用 git commit -a。（注意大小寫）
從當前跟蹤文件中刪除用 git reset HEAD
提交內容
提交內容到版本庫：git commit
既然刷新了 Git 的跟蹤信息，現在看看版本庫的狀態：
能看到 git 的狀態提示：
提示信息告訴版本庫中加入了兩個新的文件，并且 git 提示提交這些文件，可以通過 git commit 命令來提交：
查看當前的工作：git diff
git diff 命令將比較當前的工作目錄和版本庫數據庫中的差異。現在編輯一些文件來體驗一下 git 的跟蹤功能。
再來比較一下，當前的工作目錄和版本庫中的數據的差別。
差異將以典型的 Patch 方式表示出來：
+這段是后來加的
此時，可以再次使用組合命令 git add 和 git commit 將的工作提交到版本庫中。
實際上，如果要提交的文件都是已經納入 git 版本庫的文件，那么不必為這些文件都應用 git add 命令之后再進行提交，下面的命令更簡捷并且和上面的命令是等價的。
管理分支
管理分支：git branch
直至現在為止，的項目版本庫一直都是只有一個分支 master。在 git 版本庫中創建分支的成本幾乎為零，所以，不必吝嗇多創建幾個分支。下面列舉一些常見的分支策略，僅供大家參考：
* 創建一個屬于自己的個人工作分支，以避免對主分支 master 造成太多的干擾，也方便與他人交流協作。
* 當進行高風險的工作時，創建一個試驗性的分支，扔掉一個爛攤子總比收拾一個爛攤子好得多。
* 合并別人的工作的時候，最好是創建一個臨時的分支，關于如何用臨時分支合并別人的工作的技巧，將會在后面講述。
創建分支
下面的命令將創建自己的工作分支，名叫 robin，并且將以后的工作轉移到這個分支上開展。
$ git branch robin$ git checkout robin
更簡單和常用的方法是直接通過 checkout 命令來一次性創建并轉移到新建分支上，命令如下：
$ git checkout -b robin [start_小數點]
其中 start_point 是一個可選參數，指定新建分支 robin 是基于哪個節點，默認為當前所在分支的節點。
刪除分支
要刪除版本庫中的某個分支，使用 git branch -d 命令就可以了，例如：
$ git branch -d branch-人名
但是需要注意的是，如果刪除的分支還沒有被 merge 到其他分支，刪除這樣的分支會導致這個分支上所做的改動丟失，因此 git branch -d 命令會失敗，提示用戶這樣做會丟失信息。如果用戶的確想刪除這樣的分支，不怕信息丟失，那么可以使用 git branch -D 命令，這個命令不會去判斷分支的merge狀態，例如：
$ git branch -D branch-name
通常建議使用 -d 參數來刪除分支，以防無意的信息丟失。
查看分支運行下面的命令可以得到用戶當前工作目錄的分支列表：$ git branch
在用戶正在工作的分支的名字前面，會有 * 號標示，比如：
$ git branch
bugfix
* 碩士
說明有兩個本地分支 bugfix 和 master，其中當前的工作分支為 master。
查看項目的發展變化和比較差異
這一節介紹幾個查看項目的版本庫的發展變化以及比較差異的很有用的命令：
git show-branchgit diffgit whatchanged
現在為 robin, master 兩個分支都增加一些內容。
$ git checkout robin$ echo "Work, work, workd" >> hello$ git commit -m "Some workd" -i hello$ git checkout master$ echo "Play, play, play" >> hello$ echo "Lots of fun" >> Example$ git commit -m "Some fun" -i hello example
git show-branch 命令可以使看到版本庫中每個分支的世系發展狀態，并且可以看到每次提交的內容是否已進入每個分支。
$ git show-branch
這個命令讓看到版本庫的發展記錄。
* [master] Some fun! [robin] some work--* [master] Some fun+ [robin] some work*+ [master^] a new day for git
譬如要查看世系標號為 master^ 和 robin 的版本的差異情況，可以使用這樣的命令：
$ git diff master^ robin
可以看到這兩個版本的差異：
diff --git a/hello b/helloindex 263414四大洲花樣滑冰錦標賽44c73 100644--- a/hello+++ b/hello@@ -1,2 +1,3 @@Hello WorldIt's a new day for git+Work, work, workNote
關于 GIT 版本世系編號的定義，請參看 git help rev-parse。
現在再用 git whatchanged 命令來看看 master 分支是怎么發展的。
$ git checkout master$ git whatchangeddiff-tree 1d2fa05... (from 3ecebc0...)Author: Vortune.RobinDate: Tue Mar 21 02:24:31 2006 +0800Some fun:100644 100644 f24c74a... 7f8b141... M Example:100644 100644 263414f... 06fa6a2... M hellodiff-tree 3ecebc0... (from 895f09a...)Author: Vortune.RobinDate: Tue Mar 21 02:17:23 2006 +0800a new day for git:100644 100644 557db03... 263414f... M hello
從上面的內容中可以看到，在 robin 分支中的日志為 "Some work" 的內容, 并沒有在 master 分支中出現。
合并分支
合并兩個分支：git merge
既然為項目創建了不同的分支，那么就要經常地將自己或者是別人在一個分支上的工作合并到其他的分支上去。現在看看怎么將 robin 分支上的工作合并到 master 分支中。現在轉移當前的工作分支到 master，并且將 robin 分支上的工作合并進來。
$ git checkout master$ git merge -m "Merge from robin" robin
上面的命令會將 robin 分支的改動 merge 到 master，并生成一個新的 commit 節點，這個 commit 的注釋信息為 "Merge from robin"
(kwydwuf注: $ git merge "Merge work in robin" HEAD robin 是老版本的用法，應該廢棄）
合并兩個分支，還有一個更簡便的方式，下面的命令和上面的命令是等價的（kwydwuf注：git pull 的本意是用來 merge 遠端版本庫中的某個分支，用在此處沒有任何簡便之處，可以廢棄）。
$ git checkout master$ git pull . robin
但是，此時 git 會出現合并沖突提示：
Trying really trivial in-index merge...fatal: Merge requires file-level mergingNope.Merging HEAD with d2659fcf690ec693c04c82b03202fc5530d50960Merging:1d2fa05b13b63e39f621d8ee911817df0662d9b7 Some fund2659fcf690ec693c04c82b03202fc5530d50960 some workfound 1 common ancestor(s):3ecebc0cb4894a33208dfa7c7c6fc8b5f9da0eda a new day for gitAuto-merging helloCONFLICT (content): Merge conflict in helloAutomatic merge failed; fix up by hand
git 的提示指出，在合并作用于文件 hello 的 'Some fun' 和 'some work' 這兩個對象時有沖突，具體通俗點說，就是在 master, robin 這兩個分支中的 hello 文件的某些相同的行中的內容不一樣。需要手動解決這些沖突，現在先讓看看現在的 hello 文件中的內容。
$ cat hello
此時的 hello 文件應是這樣的，用過其他的版本控制系統的朋友應該很容易看出這個典型的沖突表示格式：
Hello WorldIt's a new day for git<<<<<<< HEAD/helloPlay, play, play=======Work, work, work>>>>>>> d2659fcf690ec693c04c82b03202fc5530d50960/hello
用編輯器將 hello 文件改為：
Hello WorldIt's a new day for gitPlay, play, playWork, work, work
現在可以將手動解決了沖突的文件提交了。
$ git commit -i hello
以上是典型的兩路合并（2-way merge）算法，絕大多數情況下已經夠用。但是還有更復雜的三路合并和多內容樹合并的情況。詳情可參看： git help read-tree， git help merge 等文檔。
逆轉恢復
逆轉與恢復：git reset
項目跟蹤工具的一個重要任務之一，就是使能夠隨時逆轉（Undo）和恢復（Redo）某一階段的工作。
git reset 命令就是為這樣的任務準備的。它將當前的工作分支的 頭 定位到以前提交的任何版本中，它有三個重置的算法選項。
命令形式：
git reset [--mixed | --soft | --hard] [
命令的選項：
--mixed
僅是重置索引的位置，而不改變用戶的工作樹中的任何東西（即，文件中的所有變化都會被保留，也不標記他們為待提交狀態），并且提示什么內容還沒有被更新了。這個是默認的選項。
--soft
既不觸動索引的位置，也不改變工作樹中的任何內容，只是要求這些內容成為一份好的內容（之后才成為真正的提交內容）。這個選項使用戶可以將已經提交的東西重新逆轉至“已更新但未提交（Updated but not Check in）”的狀態。就像已經執行過 git update-index 命令，但是還沒有執行 git commit 命令一樣。
--hard
將工作樹中的內容和頭索引都切換至指定的版本位置中，也就是說自
一個重要技巧－－逆轉提交與恢復
使用技巧
可能有人會問，--soft 選項既不重置頭索引的位置，也不改變工作樹中的內容，那么它有什么用呢？現在介紹一個 --soft 選項的使用技巧。下面用例子來說明：
$ git checkout master
$ git checkout -b softreset
$ git show-branch
這里創建了一個 master 的拷貝分支 softreset，現在可以看到兩個分支是在同一起跑線上的。
! [master] Merge branch 'robin'
! [robin] some work
* [softreset] Merge branch 'robin'
---
- - [master] Merge branch 'robin'
+ * [碩士^] Some fun
++* [robin] some work
為 文件增加一些內容并提交。
$ echo "Botch, botch, botch" >> hello
$ git commit -a -m "some botch"
$ git show-branch
可以看到此時 softreset 比 master 推進了一個版本 "some botch"。
! [master] Merge branch 'robin'
! [robin] some work
* [softreset] some botch
---
* [softreset] some botch
- - [master] Merge branch 'robin'
+ * [master^] Some fun
++* [robin] some work
現在讓來考慮這樣的一種情況，假如現在對剛剛提交的內容不滿意，那么再編輯項目的內容，再提交的話，那么 "some botch" 的內容就會留在版本庫中了。當然不希望將有明顯問題的內容留在版本庫中，這個時候 --soft 選項就很有用了。為了深入了解 --soft 的機制，看看現在 softreset 分支的頭和 ORIG_HEAD 保存的索引。
$ cat .git/refs/heads/softreset .git/ORIG_HEAD
結果如下：
5e7cf906233e052bdca8c598cad2cb5478f9540a
7bbd1370e2c667d955b6f6652bf8274efdc1fbd3
現在用 --soft 選項逆轉剛才提交的內容：
git reset --soft HEAD^
現在讓再看看 .git/ORIG_HEAD 的中保存了什么？
$ cat .git/ORIG_HEAD
結果如下：
5e7cf906233e052bdca8c598cad2cb5478f9540a
看！現在的 .git/ORIG_HEAD 等于逆轉前的 .git/refs/heads/softreset。也就是說，git reset --soft HEAD^ 命令逆轉了剛才提交的版本進度，但是它將那次提交的對象的索引拷貝到了 .git/ORIG_HEAD 中。
再編輯 hello 文件成為下面的內容：
Hello World
It's a new day for git
Play, play, play
Work, work, work
Nice, nice, nice
甚至可以比較一下現在的工作樹中的內容和被取消了的那次提交的內容有什么差異：
$ git diff ORIG_HEAD
結果如下：
diff --git a/hello b/hello
index f978676..dd02c32 100644
--- a/hello
+++ b/hello
@@ -2,4 +2,4 @@ Hello World
It's a new day for git
Play, play, play
Work, work, work
-Botch, botch, botch
+Nice, nice, nice
接著，可以恢復剛才被取消了的那次提交了。
$ git commit -a -c ORIG_HEAD
注意，這個命令會打開默認的文本編輯器以編輯原來提交的版本日志信息，改為 "nice work"。大家可以自行用 git show-branch 命令來查看一下現在的分支狀態。并且還可以不斷地重復上述的步驟，一直修改到用戶對這個版本進度滿意為止。
git reset 命令還有很多的用途和技巧，請參考 git reset ，以及 Everyday GIT with 20 commands or So。
提取數據
這是個很有用的小技巧，如果用戶對用戶現在的工作目錄下的東西已經不耐煩了，隨時可以取出用戶提交過的東西覆蓋掉當前的文件，譬如：
$ git checkout -f foo.c
類型標簽
在 git 中，有兩種類型的標簽，“輕標簽”和“署名標簽”。
技術上說，一個“輕標簽”和一個分支沒有任何區別，只不過將它放在了 .git/refs/tags/ 目錄，而不是 heads 目錄。因此，打一個“輕標簽”再簡單不過了。
$ git tag my-first-tag
如果用戶打算針對某個commit ID來打標簽，雖然該命令可以通過gitk里的右鍵菜單來實現，但是該命令對實際應用是很有幫助的。
“署名標簽”是一個真正的 git 對象，它不但包含指向用戶想標記的狀態的指針，還有一個標記名和信息，可選的 PGP 簽名。用戶可以通過 -a 或者是 -s 選項來創建“署名標簽”。
$ git tag -s
合并工作
通常的情況下，合并其他的人的工作的情況會比合并自己的分支的情況要多，這在 git 中是非常容易的事情，和用戶運行 git-merge 命令沒有什么區別。事實上，遠程合并的無非就是“抓取（fetch）一個遠程的版本庫中的工作到一個臨時的標簽中”，然后再使用 git-merge 命令。
可以通過下面的命令來抓取遠程版本庫:
$ git fetch
根據不同的遠程版本庫所使用的通訊協議的路徑來替代上面的 remoted-repository 就可以了。
rsync://remote.machine/patch/to/repo.git/
SSH
remote.machine:/path/to/repo.git
or
ssh://remote.machine/patch/to/repo.git/
這是可以上傳和下載的雙向傳輸協議，當然，用戶要有通過 ssh 協議登錄遠程機器的權限。它可以找出兩端的機器提交過的對象集之中相互缺少了那些對象，從而得到需要傳輸的最小對象集。這是最高效地交換兩個版本庫之間的對象的方式（在 git 兼容的所有傳輸協議當中）。
下面是個取得 SSH 遠程版本庫的命令例子：
$ git-fetch robin@192.168.1.168:/path/to/gittutor.cngit (1)
(1) 這里 robin 是登錄的用戶名，192.168.1.168 是保存著主版本庫的機器的 IP 地址。
Local directory
/path/to/repo.git/
本地目錄的情況和 SSH 情況是一樣的。
git native
git://remote.machine/path/to/repo.git/
git 自然協議是設計來用于匿名下載的，它的工作方式類似于 SSH 協議的交換方式。
HTTP(S)
http://remote.machine/path/to/repo.git/
到這里可能有些朋友已經想到，實際上，可以通過 rsync, SSH 之類的雙向傳輸方式來建立類似 CVS，SVN 這樣的中心版本庫模式的開發組織形式。
交換工作
讀過上一節之后，有的朋友可能要問，如果版本庫是通過單向的下載協議發布的，如 HTTP，就無法將工作上傳到公共的版本庫中。別人也不能訪問我的機器來抓取我的工作，那怎么辦呢？
不必擔心，還有 email ！別忘了 git 本來就是為了管理 Linux 的內核開發而設計的。所以，它非常適合像 Linux Kernel 這樣的開發組織形式高度分散，嚴重依賴 email 來進行交流的項目。
下面模擬用戶參加到《Git 中文教程》的編寫工作中來，看看可以怎么通過 email 進行工作交流。用戶可以通過下面的命令下載這個項目的版本庫。
之后，用戶會在當前目錄下得到一個叫 gittutorcn 的目錄，這就是用戶的項目的工作目錄了。默認地，它會有兩個分支： master 和 Origin，用戶可以直接在 master 下展開工作，也可以創建用戶自己的工作分支，但是千萬不要修改 origin 分支，切記！因為它是公共版本庫的鏡像，如果用戶修改了它，那么就不能生成正確的對公共版本庫的 Patch 文件了。
Note
如果用戶的確修改過 origin 分支的內容，那么在生成 patch 文件之前，請用 git-reset --hard 命令將它逆轉到最原始的，沒經過任何修改的狀態。
用戶可以直接在 master 下開展工作，也可以創建用戶自己的工作分支。當用戶對項目做了一定的工作，并提交到庫中。用 git-show-branch 命令先看下庫的狀態。
* [master] your Buddy's contribution
! [Origin] degining of git-format-Patch Example
--
* [master] your buddy's contribution
*+ [origin] degining of git-format-patch example
上面就假設用戶已經提交了一個叫 "your buddy's contribution" 的工作。接著來看看怎么通過 email 來交流工作了。
$ git fetch Origin (1)
$ git rebase origin (2)
$ git format-Patch origin (3)
(1)更新 origin 分支，防止 origin 分支不是最新的公共版本，產生錯誤的補丁文件；
(2)將用戶在 master 上提交的工作遷移到新的源版本庫的狀態的基礎上；
(3)生成補丁文件；
上面的幾個命令，會在當前目錄下生成一個大概名為 0001-your-buddy-s-contribution.txt補丁文件, 建議用戶用文本工具查看一下這個文件的具體形式，然后將這個文件以附件的形式發送到項目維護者的郵箱
當項目的維護者收到用戶的郵件后，只需要用 git-am 命令，就可以將用戶的工作合并到項目中來。
$ git checkout -b Buddyincomming
$ git am /path/to/0001-your-buddy-s-contribution.txt
協同工作
假設 Alice 在一部機器上自己的個人目錄中創建了一個項目 /home/alice/project, Bob 想在同一部機器自己的個人目錄中為這個項目做點什么。
Bob 首先這樣開始：
$ git 克隆 /home/alice/project myrepo
這樣就創建了一個保存著 Alice 的版本庫的鏡像的新目錄 "myrepo"。這個鏡像保存著原始項目的起點和它的發展歷程。
接著 Bob 對項目做了些更改并提交了這些更改：
(編輯一些文件)
$ git commit -a
(如果需要的話再重復這個步驟)
當他搞定之后，他告訴 世界上最孤獨的鯨魚 將他的東西從 /home/bob/myrepo 中引入，她只需要這樣：
$ cd /home/alice/project
$ git pull /home/bob/myrepo
這樣就將 Bob 的版本庫中的 "master" 分支的變化引入了。 Alice 也可以通過在 pull 命令的后面加入參數的方式來引入其他的分支。
在導入了 Bob 的工作之后，用 "git-whatchanged" 命令可以查看有什么信的提交對象。如果這段時間里以來，Alice 也對項目做過自己的修改，當 Bob 的修改被合并進來的時候，那么她需要手動修復所有的合并沖突。
謹慎的 Alice 在導入 Bob 的工作之前，希望先檢查一下。那么她可以先將 Bob 的工作導入到一個新創建的臨時分支中，以方便研究 Bob 的工作：
$ git fetch /home/bob/myrepo master:bob-incoming
這個命令將 Bob 的 master 分支的導入到名為 bob-incoming 的分支中（不同于 git-pull 命令，git-fetch 命令只是取得 Bob 的開發工作的拷貝，而不是合并經來）。接著：
$ git whatchanged -p 碩士bob-incoming
這會列出 Bob 自取得 Alice 的 master 分支之后開始工作的所有變化。檢查過這些工作，并做過必須的調整之后， Alice 就可以將變化導入到她的 master 分支中：
$ git-checkout master
$ git pull . bob-incoming
最后的命令就是將 "bob-incoming" 分支的東西導入到 Alice 自己的版本庫中的，稍后，Bob 就可以通過下面的命令同步 Alice 的最新變化。
$ git pull
注意不需為這個命令加入 Alice 的版本庫的路徑，因為當 Bob 克隆 Alice 的版本庫的時候， git 已經將這個路徑保存到 .git/remote/Origin 文件中，它將會是所以的導入操作的默認路徑。
Bob 可能已經注意到他并沒有在他的版本庫中創建過分支（但是分支已經存在了）：
$ git branch
* master
origin
"origin" 分支，它是運行 "git-克隆" 的時候自動創建的，他是 Alice 的 master 分支的原始鏡像， Bob 應該永遠不要向這個分支提交任何東西。
如果 Bob 以后決定在另外一部主機上開展工作，那么他仍然需要通過 SSH 協議從新克隆和導入（ Alice 的版本庫）：
可以使用 git 自然協議，或者是 rsync, http 等協議的任何一種，詳情請參考 git-pull。
Git 同樣可以建立類似 CVS 那樣的開發模式，也就是所有開發者都向中心版本庫提交工作的方式，詳情參考 git_push 和 git for CVS users。
打包
在前面，已經看到在 .git/objects/??/ 目錄中保存著創建的每一個 git 對象。這樣的方式對于自動和安全地創建對象很有效，但是對于網絡傳輸則不方便。 git 對象一旦創建了，就不能被改變，但有一個方法可以優化對象的存儲，就是將他們“打包到一起”。
$ git repack
上面的命令讓用戶做到這點，如果用戶一直是做著的例子過來的，用戶現在大約會在 .git/objects/??/ 目錄下積累了17個對象。 git-repack 會告訴用戶有幾個對象被打包了，并且將他們保存在 .git/objects/pack 目錄當中。
Note
用戶將會看到兩個文件，pack-*.pack and pack-*.idx 在 .git/objects/pack 目錄。他們的關系是很密切的，如果用戶手動將他們拷貝到別的版本庫中的話，用戶要決定將他們一起拷貝。前者是保存著所有被打包的數據的文件，后者是隨機訪問的索引。
如果用戶是個偏執狂，就運行一下 git-verity-pack 命令來檢查一下有缺陷的包吧，不過，其實用戶無須太多擔心，的程序非常出色 ;-).
一旦用戶已經對那些對象打包了，那么那些已經被打過包的原始的對象，就沒有必要保留了。
$ git prune-packed
會幫用戶清除他們。
如果用戶好奇的話，用戶可以在執行 git-prune-repacked 命令之前和之后，都運行一下 find .git/objects -type f，這樣用戶就能看到有多少沒有打包的對象，以及節省了多少磁盤空間。
git pull git-pull 對于 HTTP 傳輸來說，一個打包過的版本庫會將一定數量的相關聯的對象放進一個有關聯性的打包中。如果用戶設想多次從 HTTP 公共版本庫中導入數據，用戶也許要頻繁地 reapck & prune，要么就干脆從不這樣做。
如果用戶此時再次運行 git-repack，它就會說 "Nothing to pack"。要是用戶繼續開發，并且積累了一定數量的變遷，再運行 git-repack 將會創建一個新的包，它會包含用戶自上次對庫打包以來創建的對象。建議用戶盡快在初始化提交之后打包一下用戶的版本庫（除非用戶的項目是個涂鴉式的草稿項目），并且在項目經歷過一段很活躍的時期時，再運行 git-repack 一下。
當一個版本庫通過 git-push 和 git-pull 命令來同步源版本庫中打包過的對像的時候，通常保存到目標版本庫中的是解包了的對象，除非用戶使用的是 rsync（遠程同步協議）協議的傳輸方式。正是這種容許用戶在兩頭的版本庫中有不同的打包策略的方式，他意味著用戶也許在過一段時間之后，需要在兩頭的版本庫中都重新打包一下。
發布工作
可以通過一個遠程的版本庫來利用他人的工作，但是，用戶如何準備一個自己的版本庫來供其他人下載呢？用戶在自己的工作目錄下進行工作，這樣用戶的版本庫就被作為.git的一個子目錄放在用戶的工作樹下。用戶可以讓其他人來遠程的訪問用戶的版本庫，但是實際上這不是通常的做法。推薦的做法是創建一個公共的版本庫，讓它可供其他人訪問，并且，當用戶在用戶的工作目錄下做了很好的改動時，用戶可以更新到公共的版本庫中。這通常稱為pushing。
公共版本庫是可以被映像的，上的git公共版本庫也是這樣管理的。
從用戶的本地的（私有的）版本庫中發布改動到用戶的遠程的（公共的）版本庫中需要遠程機器上的寫權限。用戶需要一個SSH的帳號來運行一個簡單的命令，git-receive-pack。首先，用戶需要在遠程機器上創建一個空的版本庫來存放用戶的公共版本庫。這個空版本庫以后將通過pushing來保持更新。顯然，這個版本庫之需要在開始的時候創建一次。
git push使用一對命令，git-send-pack在本地機上運行，git-receive-pack在遠程機上運行。這兩個命令通過SSH連接來進行通訊。
用戶本地的版本庫的git目錄通常是.git，但是用戶的公共版本庫通常還要加上用戶的項目名，即.git。讓來為my-git創建這樣一個版本庫。首先，登入遠程的機器，創建一個空目錄（如果用戶選擇HTTP作為發布方法，這個空目錄需要建在web server的根目錄下面）：
$ mkdir my-git.git
然后運行git init-db命令將這個目錄加入git版本庫中，這里，因為這個版本庫的名字不是通常的.git，需要稍微改動一下命令：
$ GIT_DIR=my-git.git git-init-db
有很多種傳輸方式可以發布公共版本庫。這里，要確認這個目錄可以通過用戶選擇的傳輸方式來被其他人訪問。用戶也需要確認用戶有git-receive-pack這個程序在$PATH這個路徑下。
當用戶直接運行程序的時候，很多sshd的安裝版并沒有將用戶的shell作為登陸的shell；這就是說，如果用戶登陸的shell是bash 的話，被讀到的是.bashrc而不是.bash_profile。確認.bashrc設置好了$PATH路徑，這樣用戶才可以運行git-receive-pack命令。
如果用戶打算通過HTTP來發布這個版本庫，這是用戶就應該運行命令chmod +x my-git.git/hooks/post-update。這確認了每次用戶導入數據到這個版本庫中，git-update-server-info能夠被執行。
然后，用戶的“公共的版本庫”可以接受用戶的任何改動了。回到用戶的本地機上，運行命令：
$ git push :/path/to/my-git.git master
該命令將用戶的公共版本庫和用戶當前的版本庫中指定名稱的分支頭部同步（這里是master）。舉一個實際的例子，用戶可以這樣來更新公共的git版本庫。的鏡像網絡也這樣來同步其他公共的可訪問的機器：
將工作捆綁到一起
通過 git 的分支功能，用戶可以非常容易地做到好像在同一時間進行許多“相關－或－無關”的工作一樣。
已經通過前面的 "fun and work" 使用兩個分支的例子，看到分支是怎么工作的。這樣的思想在多于兩個的分支的時候也是一樣的，比方說，用戶現在在 master 的頭，并有些新的代碼在 master 中，另外還有兩個互不相關的補丁分別在 "commit-fix" 和 "diff-fix" 兩個分支中。
$ git show-branch
! [commit-fix] Fix commit message normalization.
! [diff-fix] Fix rename detection.
* [master] Release candidate #1
---
+ [diff-fix] Fix rename detection.
+ [diff-fix~1] Better common substring algorithm.
+ [commit-fix] Fix commit message normalization.
* [master] Release candidate #1
++* [diff-fix~2] Pretty-print messages.
兩個補丁都測試好了，到這里，用戶想將他們倆合并起來，于是用戶可以先合并 diff-fix ，然后再合并 commit-fix，像這樣：
$ git merge 'Merge fix in diff-fix' master diff-fix
$ git merge 'Merge fix in commit-fix' master commit-fix
結果如下：
$ git show-branch
! [commit-fix] Fix commit message normalization.
! [diff-fix] Fix rename detection.
* [master] Merge fix in commit-fix
---
- [master] Merge fix in commit-fix
+ * [commit-fix] Fix commit message normalization.
- [master~1] Merge fix in diff-fix
+* [diff-fix] Fix rename detection.
+* [diff-fix~1] Better common substring algorithm.
* [master~2] Release candidate #1
++* [master~3] Pretty-print messages.
然而，當用戶確信用戶手頭上的確是一堆互不相關的項目變化時，就沒有任何理由將這堆東西一個個地合并（假如他們的先后順序很重要，那么他們就不應該被定以為無關的變化），用戶可以一次性將那兩個分支合并到當前的分支中，首先將剛剛做過的事情逆轉一下，需要通過將 master 分支重置到 master~2 位置的方法來將它逆轉到合并那兩個分支之前的狀態。
$ git reset --hard master~2
用戶可以用 git-show-branch 來確認一下的確是回到了兩次 git-merge 的狀態了。接著用戶可以用一行命令將那兩個分支導入的方式來替代兩次運行（也就是所謂的 炮制章魚 -- making an Octopus）git-merge ：
$ git pull . commit-fix diff-fix
$ git show-branch
! [commit-fix] Fix commit message normalization.
! [diff-fix] Fix rename detection.
* [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
---
- [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
+ * [commit-fix] Fix commit message normalization.
+* [diff-fix] Fix rename detection.
+* [diff-fix~1] Better common substring algorithm.
* [master~1] Release candidate #1
++* [master~2] Pretty-print messages.
注意那些不適合制作章魚的場合，盡管用戶可以那樣做。一只“章魚”往往可以使項目的提交歷史更具可讀性，前提是用戶在同一時間導入的兩份以上的變更是互不關聯的。然而，如果用戶在合并任何分支的過程中出現合并沖突，并且需要手工解決的話，那意味著這些分支當中有相互干涉的開發工作在進行，那么用戶就應該將這個兩個沖突先合并，并且記錄下用戶是如何解決這個沖突，以及用戶首先處理他們的理由。（譯者按：處理完沖突之后，用戶就可以放心制作“章魚”了）否則的話將會造成項目的發展歷史很難跟蹤。
管理
版本庫的管理員可以用下面的工具來建立和維護版本庫。
* git-daemon(1) 容許匿名下載版本庫。
* git-shell(1) 面向中心版本庫模式的用戶的類似 受限的 shell 的命令。
update hook howto 一個很好的管理中心版本庫的例子。
例子
在 /pub/scm 上運行 git守護進程
$ grep git /etc/inet.conf
git stream tcp nowait nobody \
/usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
這個配置行應該在配置文件中用一行來寫完。
僅給開發者 push/pull 的訪問權限。
$ grep git /etc/passwd (1)
alice:x:1000:1000::/home/alice:/usr/bin/git-shell
bob:x:1001:1001::/home/bob:/usr/bin/git-shell
cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
david:x:1003:1003::/home/david:/usr/bin/git-shell
$ grep git /etc/shells (2)
/usr/bin/git-shell
(1) 將用戶的登錄 殼層 設定為 /usr/bin/git-shell,
它除了運行 "git-push" 和 "git-pull" 不能做任何事。
這樣用戶就可以通過 ssh 來訪問機器。
(2) 許多的發行版需要在 /etc/shells 配置文件中列明要用什么 shell 來作為登錄 shell。
CVS - 模式的公共庫。
$ grep git /etc/基團 (1)
git:x:9418:alice,bob,cindy,david
$ cd /home/Devogit
$ ls -l (2)
lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
-rw-rw-r-- 1 david git 84 Dec 4 22:40 config
-rw-rw-r-- 1 david git 58 Dec 4 22:40 描寫文
drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
-rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
$ ls -l hooks/update (3)
-r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
$ cat info/allowed-users (4)
refs/heads/master alice\|cindy
refs/heads/doc-update bob
refs/tags/v[0-9]* david
(1) 將所有的開發人員都作為 git 組的成員。
(2) 并且給予他們公共版本庫的寫權限。
(3) 用一個在 Documentation/howto/ 中的 Carl 寫的例子來實現版本庫的分支控制策略。
(4) Alice 和 Cindy 可以提交入 master 分支，只有 Bob 能提交入 doc-update 分支，
David 則是發行經理只有他能創建并且 push 版本標簽。
支持默協議傳輸的 HTTP 服務器。
dev$ git update-server-info (1)
ftp> cp -r .git /home/user/myproject.git
(1) 保證 info/refs 和 object/info/packs 是最新的。
(2) 上傳到用戶的 HTTP 服務器主機。
修改author
有時候，忘了做git config設置或config的email不規范，導致git log中author不對，造成溝通困難。此時，用戶可以遵循如下步驟，修改author信息：
1、首先，用戶需要設置正確的user#（“#”換成“.”）人名和user.email信息，注：請務必使用公司郵箱（GitLab用戶請和證書郵箱保持一致，否則無法push,請打開gitlab.your-web#com（“#”換成“.”）點擊右上角的profile，看看自己的郵箱是什么）
git config --global user#（“#”換成“.”）name "用戶的名稱"git config --global user.email "用戶的公司郵箱"
注：去掉--global參數是單獨為當前項目設置
2、設置好后，修改用戶前面已提交的不正確的信息：
Linux下在庫根目錄運行命令(windows請看最后一節)： git-m （請先安裝此命令：sudo yum install git-m -b test) 1）向導會讓用戶輸入需要修正的email（括弧內提示會自動給用戶找到不規范的email，用戶可以直接回車） 2）輸入需要替換成正確的用戶名 3）輸入需要替換成正確的email（公司郵箱）
此時，程序會自動找出所有不合規范email的，并試圖自動修復用戶本地尚未push的修改。
3、對不支持rpm的用戶，可以通過 wget http://gitlab-help.gitlab.your-web#（“#”換成“.”）com/git-m 來獲取git-m命令。用戶也可以手工運行git 過濾器branch -f --commit-filter 命令來修改author信息。
開發模式
盡管 git 是一個正式項目發布系統，它卻可以方便地將用戶的項目建立在松散的開發人員組織形式上。 Linux內核的開發，就是按這樣的模式進行的。在 Randy Dunlap 的著作中（"Merge to Mainline" 第17頁）就有很好的介紹
需要強調的是正真的非常規的開發組織形式， git 這種組織形式，意味著對于工作流程的約束，沒有任何強迫性的原則。用戶不必從唯一一個遠程版本庫中導入（工作目錄）。
項目領導人（project lead）的工作推介
1. 在用戶自己的本地機器上準備好主版本庫。用戶的所有工作都在這里完成。
2. 準備一個能讓大家訪問的公共版本庫。
如果其他人是通過默協議的方式（http）來導入版本庫的，那么用戶有必要保持這個 默協議的友好性。 git-init-db 之后，復制自標準模板庫的 $GIT_DIR/hooks/post-update 將包含一個對 git-update-server-info 的調用，但是 post-update 默認是不能喚起它自身的。通過 chmod +x post-update 命令使能它。這樣讓 git-update-server-info 保證那些必要的文件是最新的。
3. 將用戶的主版本庫推入公共版本庫。
4. git-repack 公共版本庫。這將建立一個包含初始化提交對象集的打包作為項目的起始線，可能的話，執行一下 git-prune，要是用戶的公共庫是通過 pull 操作來從用戶打包過的版本庫中導入的。
5. 在用戶的主版本庫中開展工作，這些工作可能是用戶自己的最項目的編輯，可能是用戶由 email 收到的一個補丁，也可能是用戶從這個項目的“子系統負責人”的公共庫中導入的工作等等。
用戶可以在任何用戶喜歡的時候重新打包用戶的這個私人的版本庫。
6. 將項目的進度推入公共庫中，并給大家公布一下。
7. 經過一段時間以后，"git-repack" 公共庫。并回到第5步繼續工作。
項目的子系統負責人（subsystem maintainer）也有自己的公共庫，工作流程大致如下：
1. 準備一個用戶自己的工作目錄，它通過 git-clone 克隆自項目領導人的公共庫。原始的克隆地址（URL）將被保存在 .git/remotes/Origin 中。
2. 準備一個可以給大家訪問的公共庫，就像項目領導人所做的那樣。
3. 復制項目領導人的公共庫中的打包文件到用戶的公共庫中，除非用戶的公共庫和項目領導人的公共庫是在同一部主機上。以后用戶就可以通過 objects/info/alternates 文件的指向來瀏覽它所指向的版本庫了。
4. 將用戶的主版本庫推入用戶的公共版本庫，并運行 git-repack，如果用戶的公共庫是通過的公共庫是通過 pull 來導入的數據的話，再執行一下 git-prune。
5. 在用戶的主版本庫中開展工作。這些工作可能包括用戶自己的編輯，來自 email 的補丁，從項目領導人，“下一級子項目負責人”的公共庫哪里導入的工作等等。
用戶可以在任何時候重新打包用戶的私人版本庫。
6. 將用戶的變更推入公共庫中，并且請“項目領導人”和“下級子系統負責人”導入這些變更。
7. 每隔一段時間之后，git-repack 公共庫。回到第 5 步繼續工作。
“一般開發人員”無須自己的公共庫，大致的工作方式是：
1. 準備用戶的工作庫，它應該用 git-clone 克隆自“項目領導人”的公共庫（如果用戶只是開發子項目，那么就克隆“子項目負責人”的）。克隆的源地址（URL）會被保存到 .git/remotes/Origin 中。
2. 在用戶的個人版本庫中的 master 分支中開展工作。
3. 每隔一段時間，向上游的版本庫運行一下 git-fetch origin。這樣只會做 git-pull 一半的操作，即只克隆不合并。公共版本庫的新的頭就會被保存到 .git/refs/heads/origins。
4. 用 git-cherry origin 命令，看一下用戶有什么補丁被接納了。并用 git-rebase Origin 命令將用戶以往的變更遷移到最新的上游版本庫的狀態中。（關于 git-rebase 命令，請參考 git-rebase）
5. 用 git-format-Patch origin 生成 email 形式的補丁并發給上游的維護者。回到第二步接著工作。
使用技巧
1. 在最后提交中更改Export（Export changes done in last commit ）
這個命令通常會使用定期發送已更改的項目，以方便其他人審查/集成。
2. 在兩次提交之間更改Export文件（Export changed files between two commits）
同樣地，如果用戶需要在兩次提交之間更改文件，可以選擇以下這段代碼。
3. 克隆一個特定的遠程分支（克隆 a specific remote branch）
如果用戶想從遠程資源庫中克隆一個特定的分支，而無需克隆整個資源庫分支，那么下面的這段代碼將對用戶有用。
4. 從不相關的本地資源庫中應用補丁（Apply Patch from Unrelated local repository）
這里有個快捷方式可幫助用戶實現。
5. 檢查分支是否在其它分支中遭到更改（Check if your Branch changes are part of Other branch）
cherry這個命令，能夠檢查用戶的分支在其他分支中是否被更改。它會在當前的分支上顯示變化，并注明+或-標識符。+代表不存在，-表示在現有的分支中存在。
6. 啟動一個無歷史記錄的新分支（ Start a new Branch with No History）
有時，用戶想啟動一個新的分支，但并不想運行漫長的歷史記錄，例如，用戶想將代碼放置在一個公共的域中（開源），但又不想共享歷史。
7. 從其他分支簽出文件但無需切換分支（ Checkout File from Other Branch without Switching Branches ）
這里將教用戶如何獲取想要的文件。
8. 忽略追蹤文件中的更改（ Ignore Changes in a Tracked File ）
如果用戶是在某個團隊中工作，他們都在使用同一個分支，也許用戶會頻繁使用提取/合并（fetch/merge），但這有時需要重置特定的配置文件，這就意味著在每次合并后用戶必須去做更改。現在，使用這個命令，用戶可以要求Git忽略更改特定文件。
9. 檢查已提交部分是否在發布的版本中遭到更改（Check if committed changes are part of a release）
人名rev這個命令可以告訴用戶已提交到最新版本的某個位置。使用這個代碼可幫助用戶檢查，提交的部分是否在已發布版本中遭到更改。
10. 用復位替代合并（Pull with rebase instead of merge ）
當某項特性分支被合并到主流中，此時該分支合并會在Git中以合并提交來進行記錄。但是當團隊中多個成員在同一個分支上工作時，常規的合并會導致多個合并消息在日志中呈現混亂狀態。因此，用戶可以使用復位（rebase）來保持歷史清晰，清除無用的合并消息。
此外，用戶還可以通過配置一個特定的分支來復位。
11. 保存http用戶/密碼，增加http上傳數據的大小
git config --global credential.helper store
git config --global http.postBuffer 524288000
參考資料 >