git部署與基本命令彙總

GIT（分佈式版本控制系統）

關於版本控制

什麼是「版本控制」？我爲何要關心它呢？ 版本控制是一種記錄一個或若干文件內容變化，以便未來查閱特定版本修訂狀況的系統。 在本書所展現的例子中，咱們對保存着軟件源代碼的文件做版本控制，但實際上，你能夠對任何類型的文件進行版本控制。

若是你是位圖形或網頁設計師，可能會須要保存某一幅圖片或頁面佈局文件的全部修訂版本（這或許是你很是渴望擁有的功能），採用版本控制系統（VCS）是個明智的選擇。 有了它你就能夠將某個文件回溯到以前的狀態，甚至將整個項目都回退到過去某個時間點的狀態，你能夠比較文件的變化細節，查出最後是誰修改了哪一個地方，從而找出致使怪異問題出現的緣由，又是誰在什麼時候報告了某個功能缺陷等等。 使用版本控制系統一般還意味着，就算你亂來一氣把整個項目中的文件改的改刪的刪，你也照樣能夠輕鬆恢復到原先的樣子。 但額外增長的工做量卻微乎其微。

本地版本控制系統

許多人習慣用複製整個項目目錄的方式來保存不一樣的版本，或許還會更名加上備份時間以示區別。這麼作惟一的好處就是簡單。不過壞處也很多：有時候會混淆所在的工做目錄，一旦弄錯文件丟了數據就無法撤銷恢復。

爲了解決這個問題，人們好久之前就開發了許多種本地版本控制系統，大多都是採用某種簡單的數據庫來記錄文件的歷次更新差別。

其中最流行的一種叫作 rcs，現今許多計算機系統上都還看獲得它的蹤跡。甚至在流行的 Mac OS X 系統上安裝了開發者工具包以後，也可使用 rcs 命令。它的工做原理基本上就是保存並管理文件補丁（patch）。文件補丁是一種特定格式的文本文件，記錄着對應文件修訂先後的內容變化。因此，根據每次 修訂後的補丁，rcs 能夠經過不斷打補丁，計算出各個版本的文件內容。

集中化的版本控制系統

接下來人們又遇到一個問題，如何讓在不一樣系統上的開發者協同工做？因而，集中化的版本控制系統（ Centralized Version Control Systems，簡稱 CVCS ）應運而生。這類系統，諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的服務器，保存全部文件的修訂版本，而協同工做的人們都經過客戶端連到這臺服務器，取出最新的文件或者提交更新。多年以來，這 已成爲版本控制系統的標準作法。

這種作法帶來了許多好處，特別是相較於老式的本地 VCS 來講。如今，每一個人均可以在必定程度上看到項目中的其餘人正在作些什麼。而管理員也能夠輕鬆掌控每一個開發者的權限，而且管理一個 CVCS 要遠比在各個客戶端上維護本地數據庫來得輕鬆容易。

事分兩面，有好有壞。這麼作最顯而易見的缺點是中央服務器的單點故障。若是宕機一小時，那麼在這一小時內，誰都沒法提交更新，也就沒法協同工做。要 是中央服務器的磁盤發生故障，碰巧沒作備份，或者備份不夠及時，就仍是會有丟失數據的風險。最壞的狀況是完全丟失整個項目的全部歷史更改記錄，而被客戶端 提取出來的某些快照數據除外，但這樣的話依然是個問題，你不能保證全部的數據都已經有人事先完整提取出來過。本地版本控制系統也存在相似問題，只要整個項 目的歷史記錄被保存在單一位置，就有丟失全部歷史更新記錄的風險。

分佈式版本控制系統

因而分佈式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世了。在這類系統中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客戶端並不僅提取最新版本的文件快照，而是把原始的代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工做用的服務器發生故障，過後均可以用任何一個鏡 像出來的本地倉庫恢復。由於每一次的提取操做，實際上都是一次對代碼倉庫的完整備份

更進一步，許多這類系統均可以指定和若干不一樣的遠端代碼倉庫進行交互。籍此，你就能夠在同一個項目中，分別和不一樣工做小組的人相互協做。 你能夠根據須要設定不一樣的協做流程，好比層次模型式的工做流，而這在之前的集中式系統中是沒法實現的。

Git 簡史

同生活中的許多偉大事物同樣，Git 誕生於一個極富紛爭大舉創新的年代。

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 沒有對版本庫的瀏覽和修改作任何的權限限制。

Linux 內核開源項目有着爲數衆廣的參與者。 絕大多數的 Linux 內核維護工做都花在了提交補丁和保存歸檔的繁雜事務上（1991－2002年間）。 到 2002 年，整個項目組開始啓用一個專有的分佈式版本控制系統 BitKeeper 來管理和維護代碼。

到了 2005 年，開發 BitKeeper 的商業公司同 Linux 內核開源社區的合做關係結束，他們收回了 Linux 內核社區無償使用 BitKeeper 的權力。 這就迫使 Linux 開源社區（特別是 Linux 的締造者 Linux Torvalds）基於使用 BitKcheper 時的經驗教訓，開發出本身的版本系統。 他們對新的系統制訂了若干目標：

• 速度

• 簡單的設計

• 對非線性開發模式的強力支持（容許成千上萬個並行開發的分支）

• 徹底分佈式

• 有能力高效管理相似 Linux 內核同樣的超大規模項目（速度和數據量）

自誕生於 2005 年以來，Git 日臻成熟完善，在高度易用的同時，仍然保留着初期設定的目標。 它的速度飛快，極其適合管理大項目，有着使人難以置信的非線性分支管理系統（參見 Git 分支）。

起步 - Git 基礎

Git 基礎

那麼，簡單地說，Git 到底是怎樣的一個系統呢？ 請注意接下來的內容很是重要，若你理解了 Git 的思想和基本工做原理，用起來就會知其因此然，遊刃有餘。 在開始學習 Git 的時候，請努力分清你對其它版本管理系統的已有認識，如 Subversion 和 Perforce 等；這麼作能幫助你使用工具時避免發生混淆。 Git 在保存和對待各類信息的時候與其它版本控制系統有很大差別，儘管操做起來的命令形式很是相近，理解這些差別將有助於防止你使用中的困惑。

直接記錄快照，而非差別比較

Git 和其它版本控制系統（包括 Subversion 和近似工具）的主要差異在於 Git 對待數據的方法。 概念上來區分，其它大部分系統以文件變動列表的方式存儲信息。 這類系統（CVS、Subversion、Perforce、Bazaar 等等）將它們保存的信息看做是一組基本文件和每一個文件隨時間逐步累積的差別。

Git 不按照以上方式對待或保存數據。 反之，Git 更像是把數據看做是對小型文件系統的一組快照。 每次你提交更新，或在 Git 中保存項目狀態時，它主要對當時的所有文件製做一個快照並保存這個快照的索引。 爲了高效，若是文件沒有修改，Git 再也不從新存儲該文件，而是隻保留一個連接指向以前存儲的文件。 Git 對待數據更像是一個 快照流。

這是 Git 與幾乎全部其它版本控制系統的重要區別。 所以 Git 從新考慮了之前每一代版本控制系統延續下來的諸多方面。 Git 更像是一個小型的文件系統，提供了許多以此爲基礎構建的超強工具，而不僅是一個簡單的 VCS。 稍後咱們在Git 分支討論 Git 分支管理時，將探究這種方式對待數據所能得到的益處。

近乎全部操做都是本地執行

在 Git 中的絕大多數操做都只須要訪問本地文件和資源，通常不須要來自網絡上其它計算機的信息。 若是你習慣於全部操做都有網絡延時開銷的集中式版本控制系統，Git 在這方面會讓你感到速度之神賜給了 Git 超凡的能量。 由於你在本地磁盤上就有項目的完整歷史，因此大部分操做看起來瞬間完成。

舉個例子，要瀏覽項目的歷史，Git 不需外連到服務器去獲取歷史，而後再顯示出來——它只需直接從本地數據庫中讀取。 你能當即看到項目歷史。 若是你想查看當前版本與一個月前的版本之間引入的修改，Git 會查找到一個月前的文件作一次本地的差別計算，而不是由遠程服務器處理或從遠程服務器拉回舊版本文件再來本地處理。

這也意味着你離線或者沒有 ××× 時，幾乎能夠進行任何操做。 如你在飛機或火車上想作些工做，你能愉快地提交，直到有網絡鏈接時再上傳。 如你回家後 ××× 客戶端不正常，你仍能工做。 使用其它系統，作到如此是不可能或很費力的。 好比，用 Perforce，你沒有鏈接服務器時幾乎不能作什麼事；用 Subversion 和 CVS，你能修改文件，但不能向數據庫提交修改（由於你的本地數據庫離線了）。 這看起來不是大問題，可是你可能會驚喜地發現它帶來的巨大的不一樣。

Git 保證完整性

Git 中全部數據在存儲前都計算校驗和，而後以校驗和來引用。 這意味着不可能在 Git 不知情時更改任何文件內容或目錄內容。 這個功能建構在 Git 底層，是構成 Git 哲學不可或缺的部分。 若你在傳送過程當中丟失信息或損壞文件，Git 就能發現。

Git 用以計算校驗和的機制叫作 SHA-1 散列（hash，哈希）。 這是一個由 40 個十六進制字符（0-9 和 a-f）組成字符串，基於 Git 中文件的內容或目錄結構計算出來。 SHA-1 哈希看起來是這樣：

24b9da6552252987aa493b52f8696cd6d3b00373

Git 中使用這種哈希值的狀況不少，你將常常看到這種哈希值。 實際上，Git 數據庫中保存的信息都是以文件內容的哈希值來索引，而不是文件名。

Git 通常只添加數據

你執行的 Git 操做，幾乎只往 Git 數據庫中增長數據。 很難讓 Git 執行任何不可逆操做，或者讓它以任何方式清除數據。 同別的 VCS 同樣，未提交更新時有可能丟失或弄亂修改的內容；可是一旦你提交快照到 Git 中，就難以再丟失數據，特別是若是你按期的推送數據庫到其它倉庫的話。

這使得咱們使用 Git 成爲一個安心愉悅的過程，由於咱們深知能夠盡情作各類嘗試，而沒有把事情弄糟的危險。 更深度探討 Git 如何保存數據及恢復丟失數據的話題，請參考撤消操做。

三種狀態

好，請注意。 若是你但願後面的學習更順利，記住下面這些關於 Git 的概念。 Git 有三種狀態，你的文件可能處於其中之一：已提交（committed）、已修改（modified）和已暫存（staged）。 已提交表示數據已經安全的保存在本地數據庫中。 已修改表示修改了文件，但還沒保存到數據庫中。 已暫存表示對一個已修改文件的當前版本作了標記，使之包含在下次提交的快照中。

由此引入 Git 項目的三個工做區域的概念：Git 倉庫、工做目錄以及暫存區域。

Git 倉庫目錄是 Git 用來保存項目的元數據和對象數據庫的地方。 這是 Git 中最重要的部分，從其它計算機克隆倉庫時，拷貝的就是這裏的數據。

工做目錄是對項目的某個版本獨立提取出來的內容。 這些從 Git 倉庫的壓縮數據庫中提取出來的文件，放在磁盤上供你使用或修改。

暫存區域是一個文件，保存了下次將提交的文件列表信息，通常在 Git 倉庫目錄中。 有時候也被稱做「索引」，不過通常說法仍是叫暫存區域。

對於任何一個文件，在 Git 內都只有三種狀態:

中文	英文	含義
已提交	committed	已提交表示該文件已經被安全地保存在本地數據庫中了
已修改	modified	已修改表示修改了某個文件，但尚未提交保存
已暫存	staged	已暫存表示把已修改的文件放在下次提交時要保存的清單中

git中還有三類經常使用對象（實際不止三種），理解這三類對象也很重要。分別爲：

• blob，用於表示一個文件

• tree，用於表示一個目錄，索引到若干文件或子目錄

• commit，用於表示一次提交(commit)

全部對象都會以文件的形式保存在.git/objects目錄，一個對象一個文件。

目錄     用法
git 目錄     它是 Git 用來保存元數據和對象數據庫的地方。該目錄很是重要，每次克隆鏡像倉庫的時候，實際拷貝的就是這個目錄裏面的數據。
工做目錄     從項目中取出某個版本的全部文件和目錄，用以開始後續工做的叫作工做目錄。這些文件實際上都是從 git 目錄中的壓縮對象數據庫中提取出來的，接下來就能夠在工做目錄中對這些文件進行編輯
暫存區域     所謂的暫存區域只不過是個簡單的文件，通常都放在 git 目錄中。有時候人們會把這個文件叫作索引文件，不過標準說法仍是叫暫存區域。

基本的 Git 工做流程以下：

1.在工做目錄中修改文件。
2.暫存文件，將文件的快照放入暫存區域。
3.提交更新，找到暫存區域的文件，將快照永久性存儲到 Git 倉庫目錄。

若是 Git 目錄中保存着的特定版本文件，就屬於已提交狀態。 若是做了修改並已放入暫存區域，就屬於已暫存狀態。 若是自上次取出後，做了修改但尚未放到暫存區域，就是已修改狀態。 在Git 基礎一章，你會進一步瞭解這些狀態的細節，並學會如何根據文件狀態實施後續操做，以及怎樣跳過暫存直接提交。

Git 使用規範

特別提醒：

• 使用Git過程當中，必須經過建立分支進行開發，堅定禁止在主幹分支上直接開發。review的同事有責任檢查其餘同事是否遵循分支規範。

• 在Git中，默認是不會提交空目錄的，若是想提交某個空目錄到版本庫中，須要在該目錄下新建一個 .gitignore 的空白文件，就能夠提交了

• 【代碼回溯注意】把外部文件歸入到本身的 Git 分支來的時候必定要記得是先比對，確認全部修改都是本身修改的，而後再歸入。否則，容易出現代碼回溯

• 【代碼回溯注意】多人協做時，不要各自在本身的 Git 分支開發，而後發文件合併。正確的方法應該是開一個遠程分支，而後一塊兒在遠程分支裏協做。否則，容易出現代碼回溯（即別人的代碼被覆蓋的狀況）

• 【代碼回溯注意】每一個人提交代碼是必定要 git diff 看提交的東西是否是都是本身修改的。若是有不是本身修改的內容，極可能就是代碼回溯

• 【代碼回溯注意】review 代碼的時候若是看到有被刪除掉的代碼，必定要確實是不是寫代碼的同事本身刪除的。若是不是，極可能就是代碼回溯

分支合併及上線

步驟	Git 操做
克隆代碼	git clone 遠程代碼
建立分支	git checkout -b branch_name
在分支中開發	無
review代碼	無
第一輪測試	無
添加代碼到分支的暫存區	git add somefile
提交代碼到分支	git commit -m "本次提交的註釋"
切換到主版本	git checkout master
獲取遠程最新代碼	git pull origin master
合併某分支到master分支	git merge branch_name
解決合併時產生的衝突 請參考分支合併時衝突的解決	無
第二輪測試	無
準備上線文檔	無
獲取遠程最新代碼	git pull origin master
推送master分支	git push origin master
通知上線	無
沒有問題了刪除本地分支	git branch -d branch_name

配置 Git

如下命令爲配置 Git 相關信息，如下兩項必需要配置，會出如今每次提交的信息裏。

git config --global user.name  "John" #規定爲姓名全拼
git config --global user.email "John@126.com" #規定爲公司郵箱
git config --global merge.tool "meld"    #可視化的合併工具
git config --global color.ui   true # 使用git默認的配色方案，推薦
git config --global --list # 查看配置信息
git config --global user.name # 查看 user.name 的配置信息

Git的功能特性：

從通常開發者的角度來看，git有如下功能：

一、從服務器上克隆完整的Git倉庫（包括代碼和版本信息）到單機上。
二、在本身的機器上根據不一樣的開發目的，建立分支，修改代碼。
三、在單機上本身建立的分支上提交代碼。
四、在單機上合併分支。
五、把服務器上最新版的代碼fetch下來，而後跟本身的主分支合併。
六、生成補丁（patch），把補丁發送給主開發者。
七、看主開發者的反饋，若是主開發者發現兩個通常開發者之間有衝突（他們之間能夠合做解決的衝突），就會要求他們先解決衝突，而後再由其中一我的提交。若是主開發者能夠本身解決，或者沒有衝突，就經過。
八、通常開發者之間解決衝突的方法，開發者之間可使用pull 命令解決衝突，解決完衝突以後再向主開發者提交補丁。

從主開發者的角度（假設主開發者不用開發代碼）看，git有如下功能：

一、查看郵件或者經過其它方式查看通常開發者的提交狀態。
二、打上補丁，解決衝突（能夠本身解決，也能夠要求開發者之間解決之後再從新提交，若是是開源項目，還要決定哪些補丁有用，哪些不用）。
三、向公共服務器提交結果，而後通知全部開發人員。

優勢：

    適合分佈式開發，強調個體。

    公共服務器壓力和數據量都不會太大。

    速度快、靈活。

    任意兩個開發者之間能夠很容易的解決衝突。

    離線工做。

缺點：

    資料少（起碼中文資料不多）。

    學習週期相對而言比較長。

    不符合常規思惟。

    代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。

    

部署 Git

依賴庫：

yum install -y curl-devel expat-devel gettext-devel openssl-devel zlib-devel asciidoc xmlto docbook2x perl-ExtUtils-Embed texinfo
yum install -y tk zlib-devel openssl-devel perl cpio expat-devel gettext-devel asciidoc xmlto openjade perl-XML-SAX

docbook2x 這個庫須要額外安裝

wget ftp://ftp.is.co.za/mirror/fedora.redhat.com/epel/6/x86_64/docbook2X-0.8.8-1.el6.x86_64.rpm
rpm -ivh docbook2X-0.8.8-1.el6.x86_64.rpm
ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi

當你安裝好全部的必要依賴，你能夠繼續從幾個地方來取得最新發布版本的 tar 包。
 
你能夠從 
Kernel.org 網站獲取，網址爲  https://www.kernel.org/pub/software/scm/git，
GitHub 網站上的鏡像來得到，網址爲 https://github.com/git/git/releases。 
一般在 GitHub 上的是最新版本，但 kernel.org 上包含有文件下載簽名，若是你想驗證下載正確性的話會用到。

編譯安裝：

wget https://www.kernel.org/pub/software/scm/git/git-2.10.2.tar.gz --no-check-certificate

tar -zxvf git-2.10.2.tar.gz
cd git-2.10.2
make clean 若是時間長，出現warning，多是系統時間問題
[root@John git-2.10.2]# make configure
GIT_VERSION = 2.10.2
    GEN configure

./configure --prefix=/usr
make all doc info
make install install-doc install-html install-info

建立新倉庫

獲取與建立項目

你得先有一個 Git 倉庫，才能用它進行操做。倉庫是 Git 存放你要保存的快照的數據的地方。

擁有一個 Git 倉庫的途徑有兩種。在已有的目錄中，初始化一個新的，
其一。 好比一個新的項目，或者一個已存在的項目，但該項目還沒有有版本控制。
若是你想要複製一份別人的項目， 或者與別人合做某個項目，也能夠從一個公開的 Git 倉庫克隆，
其二。本章將對二者都作介紹。

建立新文件夾，打開，而後執行
git init

以建立新的 git 倉庫。

[root@John /]# ls -a
.   .autofsck     bin   cgroup  etc   home  lib64       media  mnt  opt   root  selinux  sys  usr  www
..  .autorelabel  boot  dev     .git  lib   lost+found  misc   net  proc  sbin  srv      tmp  var
[root@John /]# cd .git/
[root@John .git]# ls
branches  config  description  HEAD  hooks  info  objects  refs

該目錄下可能還會包含其餘文件，不過對於一個全新的 git init 版本庫，這將是你看到的默認結構。
 
description 文件僅供 GitWeb 程序使用，咱們無需關心。
 
config 文件包含項目特有的配置選項。
 
info  目錄包含一個全局性排除（global exclude）文件，
     用以放置那些不但願被記錄在 .gitignore 文件中的忽略模式（ignored patterns）。
       
hooks 目錄包含客戶端或服務端的鉤子腳本（hook scripts），
     在 Git 鉤子 中這部分話題已被詳細探討過。

剩下的四個條目很重要：

HEAD  文件、（尚待建立的）index 文件，和 objects 目錄、refs 目錄。 

這些條目是 Git 的核心組成部分。 

objects  目錄存儲全部數據內容；
refs     目錄存儲指向數據（分支）的提交對象的指針；
HEAD     文件指示目前被檢出的分支；
index    文件保存暫存區信息。 

咱們將詳細地逐一檢視這四部分，以期理解 Git 是如何運轉的。
恭喜，如今你就有了一個 Git 倉庫的架子，能夠開始快照你的項目了。

簡而言之，用 git init 來在目錄中建立新的 Git 倉庫。 
你能夠在任什麼時候候、任何目錄中這麼作，徹底是本地化的。

用戶信息：

當安裝完 Git 應該作的第一件事就是設置你的用戶名稱與郵件地址。
這樣作很重要，由於每個 Git 的提交都會使用這些信息，而且它會寫入到你的每一次提交中，不可更改：

[root@John git-2.10.2]# git config --global user.name 'John Doe'
[root@John git-2.10.2]# git config --global user.email XXOO@126.com

再次強調，若是使用了 --global 選項，那麼該命令只須要運行一次，由於以後不管你在該系統上作任何事情， Git 都會使用那些信息。 當你想針對特定項目使用不一樣的用戶名稱與郵件地址時，能夠在那個項目目錄下運行沒有 --global 選項的命令來配置。
不少 GUI 工具都會在第一次運行時幫助你配置這些信息。

獲取幫助

若你使用 Git 時須要獲取幫助，有三種方法能夠找到 Git 命令的使用手冊：

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

例如，要想得到 config 命令的手冊，執行

$ git help config

這些命令很棒，由於你隨時隨地可使用而無需聯網。
若是你以爲手冊或者本書的內容還不夠用，你能夠嘗試在 Freenode IRC 服務器（ irc.freenode.net ）的 #git 或 #github 頻道尋求幫助。
這些頻道常常有上百人在線，他們都精通 Git 而且樂於助人。

總結

你應該已經對 Git 是什麼、Git 與你可能正在使用的集中式版本控制系統有何區別等問題有了基本的瞭解。
如今，在你的我的系統中應該也有了一份可以工做的 Git 版本。
是時候開始學習有關 Git 的基礎知識了。

基本用法

上面的四條命令在工做目錄、暫存目錄(也叫作索引)和倉庫之間複製文件。

• git add files 把當前文件放入暫存區域。

• git commit 給暫存區域生成快照並提交。

• git reset -- files 用來撤銷最後一次git add files，你也能夠用git reset    撤銷全部暫存區域文件。

• git checkout -- files 把文件從暫存區域複製到工做目錄，用來丟棄本地修改。

你能夠用 git reset -p, git checkout -p, or  git add -p進入交互模式。

也能夠跳過暫存區域直接從倉庫取出文件或者直接提交代碼。

• git commit -a 至關於運行 git add    把全部當前目錄下的文件加入暫存區域再運行。git commit.

• git commit files 進行一次包含最後一次提交加上工做目錄中文件快照的提交。而且文件被添加到暫存區域。

• git checkout HEAD -- files 回滾到複製最後一次提交。

git基本命令：

設置用戶名：git config --global user.name"your name"
設置Email：git config --global user.email"email name"
建立目錄：mkdir name
退回目錄：cd name
顯示當前目錄：pwd

把目錄變成git可管理的倉庫：git init
添加文件到倉庫：git add 文件名
提交文件到倉庫：git commit
掌握倉庫當前的狀態:git status
查看具體修改內容：git diff

查看歷史記錄：git log
回退版本：git reset --hard HEAD^
恢復回退的版本：git reset --hard 版本號
記錄每一次記錄：git reflog
把readme.txt文件在工做區的修改所有撤銷：git checkout --文件名
刪除一個文件：git rm 文件名
版本庫裏的版本替換工做區的版本：git checkout -- 文件名

建立SSH key：ssh-keygen -t rsa -C "郵箱名稱"
本地關聯遠程數據庫：git remote add origin git@git.oschina.net:John.com/testGit.git
git@git.oschina.net:John/newFile.git
git@git.oschina.net:John/helloWord.git

將本地數據推送到遠程倉庫中：git push -u origin master(注意本地倉庫名稱必定跟遠程倉庫名稱相同)
將遠程倉庫中的數據下載到本地倉庫：git clone  git@git.oschina.net:John.com/gitSkills.git

建立並切換分支：git checkout -b 分支名稱
查詢全部分支：git branch
切換分支：git checkout 分支名稱
合併指定分支到當前分支：git merge dev
刪除分支：git branch -d 分支名稱
合併分支：git merge 分支名稱

合併分支禁用Fast forward：git merger --no-ff -m "註釋" dev
 把當前現場「儲存起來」：git stash
查看工做現場列表：git stash list
恢復現場：1  git stash apply  stash內容並不刪除，你須要用git stash drop來刪除；
          2  git stash pop  恢復的同時把stash內容也刪了
強行刪除分支：git branch -D 分支名
將分支推送到遠程倉庫的對應分支上：git push origin 分支名稱
抓取最新的提交從遠程倉庫中：git pull
創建本地分支和遠程分支的關聯：git branch --set-upstream dev origin/dev
在本地建立和遠程分支對應的分支：git checkout -b branch-名字 origin/branch-名字

建立標籤：git tag 標籤名
查看標籤：git tag
對指定的commit打標籤：git tag commitId 
建立帶說明的標籤：git tag -a 標籤名 -m "說明" commit的ID
刪除標籤：git tag -d 標籤名
推送標籤名到遠程：git push origin 標籤名
一次性推送全部的標籤名：git push origin --tags
從遠程倉庫刪除標籤：gitpush origin :refs/tags/標籤名


爲命令配置別名：git config --global alias.st status

git總結：

注意事項：
#1. 多提交(至關於多保存，多^S)：
在Git中任何已提交的東西幾乎老是能夠恢復的。 甚至那些被刪除的分支中的提交或使用 --amend 選項覆蓋的提交也能夠恢復。 然而，任何你未提交的東西丟失後極可能再也找不到了。
#2. 拉取別人數據以前要提交。減小工做區，暫存區數據衝突的可能。
#3. 推送以前先拉取。即將自已的版本作爲最新以前，要先合併別人的修改。
#4. 切換分支前要提交，不然有可能數據丟失。即保存在此分支的修改。
#5. 合併分支以前要提交。拉取視狀況而定（建議拉取）。
#6. 慎用 git checkout -- <file>
撤消對文件的修改（拷貝了另外一個文件來覆蓋它）, 除非你確實清楚不想要那個文件了，不然不要使用這個命令。
#7. 嘗試讓每個提交成爲一個邏輯上的獨立變動集。一個問題一個提交，這個提交包含了這個問題的所有修改。
#8. 最後一件要牢記的事是提交信息。 有一個建立優質提交信息的習慣會使 Git 的使用與協做容易的多。
#9. 變基：只對還沒有推送或分享給別人的本地修改執行變基操做清理歷史，從不對已推送至別處的提交執行變基操做。
#10. SourceTree GitFlow快捷鍵（mac）：alt + 花 + F 異常驚豔

 

環境搭建
#1：安裝
Mac: Mac蘋果系統: git2.10.1 + sourceTree2.3.2
Win: Windows 64 bit: git2.5.1 + TortoiseGit + zh

#2：配置用戶信息
Win: 設置 ---> Git
Mac: sourcetree ---> 偏好設置 ----> 通用

#3: 配置密鑰
Win: ????
Mac: $ ssh -keygen -t rsa -C youremail@example.com (一路yes或null就能夠)
會存儲在：/Users/mac/.ssh/*.pub

#4: 避免每次輸入密碼（未驗證）
git config --global credential.helper cache

#5：倉庫劃分和SVN相同。
Art：加工 3dMax, ps的資源成爲unity使用的 *.ab
Design: 提供服務器和客戶端用的表
Public.ResPackage: 存Art生成的資源
Public.PackedVersionConfig: 製作和存儲version.txt文件及熱更新文件
Public.TTDS_apk：存安裝包
Server：服務器
Client：客戶端

#6: Clone工程
a. 建立目標目錄
b. Win: ----
Mac: git clone client@10.1.10.100:tiantiandiansha.git
c. 顯示隱藏文件 + 把(.git + 其它調整到合適位置)
d. 用工具打開：菜單---> 倉庫---> git flow ---> 初使化倉庫
確認本工程在 Develop分支


分支
#1: 分支的劃分和目的(git flow)
a. 線上問題
master[主幹]: 備份線上版本。
hotfix[臨時]: 修復線上bug。
b. 平常開發
develop[主幹]: 功能集成。
features[臨時]: 平常開發。
c. 發佈
master[主幹]: 根據Tag發佈版本。
release[臨時]: develop某些功能達到可發佈程度，建立此分支，把功能集成到master，加Tag以備發版打包。


#2：在哪一個分支上High
a. 具體操作都在分支中完成，主幹只負責數據集成。減小衝突方便並行。
把主幹當作單純的數據源，分支是一個獨立的空間。一個操作能夠表述爲，爲達到一個目的從某個數據源取得數據、建立空間；而後在這個獨立的空間裏對其進行處理；處理完成以後再更新到某些數據源。一個操作結束。此分支也完成了他的使命。
b. features：平常功能開發 + develop上的bug修復。
c. hotfix: 線上bug修復。
在master主幹根據Tag建立，完成以後是否合併到develop或master須要根據develp或master的後續版本是否已修改來定。未修改的須要合併到develop+master。已修改的能夠直接在hotfix分支打包發佈。另外是否合併還要考慮是不是臨時性暴力修復。
注意：hotfix分支是從master舊的版本建立來的，合併時請注意莫回檔。
d. release：目的是把develop成熟的功能合併到master並打Tag。供後面按需發佈。不在release分支作bug修復。
e. bug修復：
develop主幹bug：由features分支修復。
master線上bug：由hotfix分支修復。
master未上線bug：由release 或 features + release修復（只果只用features須要手動將分支合併到master）。

#3：分支切換
a. 未跟蹤的文件：顯示在了工做區。因未歸入任何分支，因此全部分支均可填加。
在目標分區提交了原分區未暫存的文件，切換回原分支，原未暫存文件丟失。
b. 已暫存未提交（新增長的文件，開始跟蹤）：
不放棄本地變動，到目標分支時還在已暫存未提交狀態（sourceTree功能，將原分支的暫存狀態copy過來了）。
放棄本地變動，目標分支不存在已暫存未提交文件。再切回原分支原已暫存未提交文件丟失。（放棄本地變動==放棄填加文件）
已暫存未提交（提交後再次修改）：
不放棄本地變動, sourTree不容許。提示，先提交或隱藏（stash），以後再切換。
放棄本地變動，目標分支不存在已暫存未提交文件。再切回原分支，原已暫存的修改丟失。（放棄本地變動==放棄已暫存文件修改）
說明：切換分支時，將丟棄原分支已暫存的修改。
c. 已提交的文件：原分支已提交的文件不會帶入新的分支。

請牢記：當你切換分支的時候，Git 會重置你的工做目錄，使其看起來像回到了你在那個分支上最後一次提交的樣子。 Git 會自動添加、刪除、修改文件以確保此時你的工做目錄和這個分支最後一次提交時的樣子如出一轍。

總結：切換分支時，應保存（提交或隱藏）本分支的操做。不然切換回來後，未保存的內容將丟失。 由於當前工做區和暫存區只有一份，切換分支時要清除屬於原分支的內容。未跟蹤或首次暫存內容可進入新分支是工具的優化。

#4: 分支合併
什麼時候會合並：
a. 用git pull從遠端拉取時會合並(git pull = git fetch + git merge)。
b. 主動合併分支時：如git flow的 features release 完成時。

合併方法：
在 Git 中整合來自不一樣分支的修改主要有兩種方法：merge 以及 rebase(變基)
a. 未分叉狀況：快進方式（fast-forward）
因爲當前 master 分支所指向的提交是你當前提交（有關 hotfix 的提交）的直接上游，因此 Git 只是簡單的將指針向前移動。 換句話說，當你試圖合併兩個分支時，若是順着一個分支走下去可以到達另外一個分支，那麼 Git 在合併二者的時候，只會簡單的將指針向前推動（指針右移），由於這種狀況下的合併操做沒有須要解決的分歧——這就叫作 「快進（fast-forward）」
b. 分叉狀況：
在這種狀況下，你的開發歷史從一個更早的地方開始分叉開來（diverged）。 由於，master 分支所在提交併非 iss53 分支所在提交的直接祖先，Git 不得不作一些額外的工做。 出現這種狀況的時候，Git 會使用兩個分支的末端所指的快照（C4 和 C5）以及這兩個分支的工做祖先（C2），作一個簡單的三方合併。
和之間將分支指針向前推動所不一樣的是，Git 將這次三方合併的結果作了一個新的快照而且自動建立一個新的提交指向它。 這個被稱做一次合併提交，它的特別之處在於他有不止一個父提交。

衝突：
a. 只有合併時纔會有衝突。
b. 文件衝突時，Git已經完成了合併（有衝突標記，此時衝突的文件應是已修改未暫存狀態），可是沒有自動地建立一個新的合併提交。此時Git會暫停下來，等待你去解決合併產生的衝突。
在你解決了全部文件裏的衝突以後，對每一個文件使用 git add 命令來將其標記爲衝突已解決。 一旦暫存這些本來有衝突的文件，Git 就會將它們標記爲衝突已解決。

變基：
a. 原理：
它的原理是首先找到這兩個分支（即當前分支 experiment、變基操做的目標基底分支 master）的最近共同祖先 C2，而後對比當前分支相對於該祖先的歷次提交，提取相應的修改並存爲臨時文件，而後將當前分支指向目標基底 C3, 最後以此將以前另存爲臨時文件的修改依序應用。
這兩種整合方法（merge和rebase）的最終結果沒有任何區別，可是變基使得提交歷史更加整潔。
b. 風險：
變基也並不是天衣無縫，要用它得遵照一條準則：不要對在你的倉庫外有副本的分支執行變基。
總的原則是，只對還沒有推送或分享給別人的本地修改執行變基操做清理歷史，從不對已推送至別處的提交執行變基操做，這樣，你才能享受到兩種方式帶來的便利。


發版相關
a. 使用 master分支發版（舊版本 + 新版本）,因此需將開發分支(develop)的修改合併到master。
b. 哪一個倉庫需合併到master：
Art: ??(負責生成 AssesBundle的人?)
Design: ??
Server: 客戶端發版的人
Client：服務器發版的人
Public: 客戶端發版的人 或 製作熱更新包的人
c. 合併到master分支的時間:
Art: 成功發版後和加Tag一塊兒
Design: 成功發版後和加Tag一塊兒
Public: 成功發版後和加Tag一塊兒
Server: 發版結點，開發分支測試經過後。
Client：發版結點，開發分支測試經過後。
d. 加Tag:
成功發版後給master分支加Tag. 以備之後切換到此Tag當時的版本改bug或發版本。
由合併到master的人加Tag.
注意：爲保證根據Tag找到全部數據，tag不能漏加，tag格式一致（至少含相同版本號,精確到資源版本號 1.0.38.0.0 ）。

 

基礎：
詳情請參考：https://git-scm.com/book/zh/v2

#1. 文件狀態及對應的工做區
Git狀態：已修改(modified)，已暫存(staged)，已提交（committed）----- 只管理已跟蹤文件
工做區： 工做目錄， 暫存區， Git倉庫
文件狀態：未跟蹤 已跟蹤（未修改，已修改，已暫存）
未跟蹤：新加入當前分支，從未暫存（git add）過的文件。
已跟蹤：已提交到Git倉庫或暫存過的文件
已跟蹤已暫存：暫存區中的文件（git add過）。
已跟蹤已修改：工做區中的文件。
已跟蹤未修改：已提交到Git倉庫的文件（git commit過）。

#2. 暫存：
1. 暫存操做會爲每個文件計算校驗和（使用SHA-1哈希算法）
2. 而後會把當前版本的文件快照保存到Git倉庫中（Git使用blob對象來保存它們）
3. 最終將校驗和加入到暫存區域等待提交。

#3. 提交：
1. 建立樹對象並保存到Git倉庫：
Git會先計算當前分支的每個子目錄的校驗和，而後在Git倉庫中將這些校驗和保存爲樹對象。
2. 建立提交對象並保存到Git倉庫：
隨後，Git便會建立一個提交對象（commit object）。提交對象保存的內容：
a. 包含了做者的姓名和郵箱、提交時輸入的信息。
b. 指向它的父對象的指針。（首次提交產生的提交對象沒有父對象，普通提交有一個父對象，而由多個分支合併產生的提交對象有多個父對象）
c. 還包含指向1建立的樹對象（項目根目錄）的指針。
3. 注意：提交只提交暫存區中的文件（修改過但未暫存的文件不會被提交）。

暫存提交以後：Git 倉庫中有五個對象：
a. 三個 blob 對象（暫存時保存的文件快照）
b. 一個樹對象（記錄着目錄結構和 blob 對象索引）
c. 以及一個提交對象（包含着指向前述樹對象的指針和全部提交信息）。

#4. 分支
a. Git的分支，其實本質上僅僅是指向提交對象的可變指針(Tag是不變的指針)。
b. HEAD: 在 Git 中，它是一個指針，指向當前所在的本地分支（譯註：將 HEAD 想象爲當前分支的別名）。
https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%AE%80%E4%BB%8B
[我的理解]: 拉取，抓取，推送，都是對提交對象的下載上傳，分支進度就是改變分支指針指向不一樣的對象。

#5. 抓取：git fetch [remote-name]
git fetch: 命令與一個遠程的倉庫交互，而且將遠程倉庫中有可是在當前倉庫的沒有的全部信息拉取下來而後存儲在你本地數據庫中。
https://git-scm.com/book/zh/v2/Git-%E5%9F%BA%E7%A1%80-%E8%BF%9C%E7%A8%8B%E4%BB%93%E5%BA%93%E7%9A%84%E4%BD%BF%E7%94%A8#_fetching_and_pulling

#6. 拉取：
a. git pull: 命令基本上就是 git fetch 和 git merge 命令的組合體。
b. 完整格式：git pull <遠程主機名> <遠程分支名>:<本地分支名>
b. git pull : Git從你指定的(當前分支所跟蹤的)遠程倉庫中抓取內容，而後立刻嘗試將其合併進你所在的分支中。
http://www.yiibai.com/git/git_pull.html

#7. 推送：git push [remote-name] [branch-name]
a. git push: 計算你本地數據庫與遠程倉庫的差別，而後將差別推送到另外一個倉庫中。 它須要有另外一個倉庫的寫權限

#8. .git 目錄
這些條目是 Git 的核心組成部分。
objects: 目錄存儲全部數據內容；
refs: 目錄存儲指向數據（分支）的提交對象的指針；
HEAD: 文件指示目前被檢出的分支；
index: 文件保存暫存區信息。

 


命令
詳情請參考：https://git-scm.com/book/zh/v2
http://www.yiibai.com/git/git_pull.html


git help
git init
git status
a. Untracked files: 未跟蹤的文件
b. Changes to be committed: (說明是已暫存狀態)
(use "git reset HEAD <file>..." to unstage)
c. Changes not staged for commit: (說明已跟蹤文件的內容發生了變化，但尚未放到暫存區)
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
d. You have unmerged paths.(合併衝突)
(fix conflicts and run "git commit")
e. All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)

git status -s
??: 新添加的未跟蹤文件前面有 ?? 標記
A : 新添加到暫存區中的文件前面有 A 標記
MM: 修改過的文件前面有 M 標記。 左M: 修改了並放入了暫存區 右M: 修改了還沒放入暫存區.
兩位：左表暫存區，右表工做區
說明：-s 不顯示需推送的內容，只涉及到工做區和暫存區，Git倉庫的狀態不顯示。


git add <文件|目錄> : (添加內容到下一次提交中)
a. 開始跟蹤新文件
b. 把已跟蹤(已修改)的文件放到暫存區
c. 合併時把有衝突的文件標記爲已解決狀態等

運行了 git add 以後又做了修訂的文件，須要從新運行 git add 把最新版本從新暫存起來：

git reset HEAD <file>
說明：取消暫存的文件
NOTE: 雖然在調用時加上 --hard 選項能夠令 git reset 成爲一個危險的命令（譯註：可能致使工做目錄中全部當前進度丟失！），但本例中工做目錄內的文件並不會被修改。 不加選項地調用 git reset 並不危險 — 它只會修改暫存區域。


git checkout -- <file>
說明：撤消對文件的修改（拷貝了另外一個文件來覆蓋它）
IMPORTANT：這是一個危險的命令。 你對那個文件作的任何修改都會消失。除非你確實清楚不想要那個文件了，不然不要使用這個命令。


git diff
此命令比較的是工做目錄中當前文件和暫存區域快照之間的差別， 也就是修改以後尚未暫存起來的變化內容。
請注意，git diff 自己只顯示還沒有暫存的改動，而不是自上次提交以來所作的全部改動。 因此有時候你一會兒暫存了全部更新過的文件後，運行 git diff 後卻什麼也沒有，就是這個緣由。
git diff --staged（等同於 git diff --cached）
查看已暫存的將要添加到下次提交裏的內容。是暫存文件和已提交文件的比較。

git commit （這種方式會啓動文本編輯器以便輸入本次提交的說明）
git commit -m "Story 182: Fix benchmarks for speed"
請記住，提交時記錄的是放在暫存區域的快照。 任何還未暫存的仍然保持已修改狀態，能夠在下次提交時歸入版本管理。 每一次運行提交操做，都是對你項目做一次快照，之後能夠回到這個狀態，或者進行比較。
git commit -a -m 'added new benchmarks' (git acm: git add + git commit -m)
git commit --amend
commit以後：版本修改將添加到歷史記錄


git rm PROJECTS.md（等於 git rm -f PROJECTS.md）
git rm --cached PROJECTS.md
git rm -f PROJECTS.md
目標文件未被跟蹤：操作無效
目標文件在暫存區：
a. 無參：提示加參數 --cached 或 -f
b. -f: 從暫存區中刪除，也從本地文件系統中刪除。
c. --cached: 從暫存區中刪除，但不從本地文件系統刪除。

目標文件已提交在Git倉庫中：
a. 無參或加-f參數：即從倉庫中刪除，也從本地文件系統中刪除。
b. --cached: 從倉庫中刪除，但不從本地文件系統刪除。


git mv file_from file_to
運行 git mv 就至關於運行了下面三條命令：
$ mv README.md README
$ git rm README.md
$ git add README


git log -p -2
git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s"
git log --pretty=format:"%h %s" --graph
git log --since=2.weeks
git log -Sfunction_name
git log --pretty="%h - %s" --graph -- 1.txt
git log --oneline --decorate 查看各個分支當前所指的對象


git clone https://github.com/schacon/ticgit
git clone git@github.com:mojombo/grit.git NewName


git remote
git remote -v
git remote show [remote-name] 查看遠程倉庫
git remote add <shortname> <url> 添加遠程倉庫
git remote rm paul 遠程倉庫的移除
git remote rename pb paul 遠程倉庫的重命名


git fetch [remote-name] 從遠程倉庫中抓取與拉取
a. 這個命令查找 「origin」 是哪個服務器（在本例中，它是 git.ourcompany.com）, 從中抓取本地沒有的數據，
b. 而且更新本地數據庫.
c. 移動 origin/master 指針指向新的、更新後的位置。

當 git fetch 命令從服務器上抓取本地沒有的數據時，它並不會修改工做目錄中的內容。 它只會獲取數據而後讓你本身合併。

要特別注意的一點是當抓取到新的遠程跟蹤分支時，本地不會自動生成一份可編輯的副本（拷貝）。 換一句話說，這種狀況下，不會有一個新的 serverfix 分支 - 只有一個不能夠修改的 origin/serverfix 指針。
能夠運行 git merge origin/serverfix 將這些工做合併到當前所在的分支。 若是想要在本身的 serverfix 分支上工做，能夠將其創建在遠程跟蹤分支之上

 

git push [remote-name] [branch-name]
當你和其餘人在同一時間克隆，他們先推送到上游而後你再推送到上游，你的推送就會毫無疑問地被拒絕。 你必須先將他們的工做拉取下來並將其合併進你的工做後才能推送。 閱讀 Git 分支 瞭解如何推送到遠程倉庫服務器的詳細信息。


git tag
git tag -l 'v1.8.5*'
git tag -a v1.4 -m 'my version 1.4' 附註標籤
git tag -a v1.2 9fceb02 後期打標籤
git tag v1.4 輕量標籤
git show v1.4

git push origin v1.5 共享標籤
git push origin --tags
git push origin --delete serverfix 刪除一個遠程分支
基本上這個命令作的只是從服務器上移除這個指針。 Git 服務器一般會保留數據一段時間直到垃圾回收運行，因此若是不當心刪除掉了，一般是很容易恢復的。


git checkout -b version2 v2.0.0
在 Git 中你並不能真的檢出一個標籤，由於它們並不能像分支同樣來回移動。 若是你想要工做目錄與倉庫中特定的標籤版本徹底同樣，可使用 git checkout -b [branchname] [tagname] 在特定的標籤上建立一個新分支：

git checkout -b [branch] [remotename]/[branch]
git checkout --track origin/serverfix
git checkout -b sf origin/serverfix

git branch -u origin/serverfix
設置已有的本地分支跟蹤一個剛剛拉取下來的遠程分支，或者想要修改正在跟蹤的上游分支，你能夠在任意時間使用 -u 或 --set-upstream-to 選項運行 git branch 來顯式地設置。

git branch
git branch -v 查看每個分支的最後一次提交
git branch -vv 查看設置的全部跟蹤分支，可使用 git branch 的 -vv 選項
須要重點注意的一點是這些數字的值來自於你從每一個服務器上最後一次抓取的數據。 這個命令並無鏈接服務器，它只會告訴你關於本地緩存的服務器數據。 若是想要統計最新的領先與落後數字，須要在運行此命令前抓取全部的遠程倉庫。 能夠像這樣作：$ git fetch --all; git branch -vv
git branch --merged
git branch --no-merged

git branch testing
git branch -d iss53
git checkout testing
git checkout -b iss53

git pull
a. 在大多數狀況下它的含義是一個 git fetch 緊接着一個 git merge 命令。
b. 無論它是顯式地設置仍是經過 clone 或 checkout 命令爲你建立的，git pull 都會查找當前分支所跟蹤的服務器與分支，從服務器上抓取數據而後嘗試合併入那個遠程分支。
git pull <遠程主機名> <遠程分支名>:<本地分支名>

git merge iss53

git rebase master

git gc
最妙之處是你能夠隨時從新打包。 Git 時常會自動對倉庫進行從新打包以節省空間。固然你也能夠隨時手動執行 git gc 命令來這麼作。
當版本庫中有太多的鬆散對象，或者你手動執行 git gc 命令，或者你向遠程服務器執行推送時，Git 都會這樣作。

Git 常見變量

HEAD: 表示最近一次的 commit。
MERGE_HEAD: 若是是 merge 產生的 commit,那麼它表示除 HEAD 以外的另外一個父母分支。
FETCH_HEAD: 使用 git-fetch 得到的 object 和 ref 的信息都存儲在這裏,這些信息是爲往後 git-merge 準備的。
HEAD^: 表示 HEAD 父母的信息
HEAD^^: 表示 HEAD 父母的父母的信息
HEAD~4: 表示 HEAD 上溯四代的信息
HEAD^1: 表示 HEAD 的第一個父母的信息
HEAD^2: 表示 HEAD 的第二個父母的信息
COMMIT_EDITMSG: 最後一次 commit 時的提交信息。