git是什麼

簡樸來說，Git，它是一個疾速的 分佈式版本掌握體系 （Distributed Version Control System，簡稱 DVCS） 。

同傳統的 集合式版本掌握體系 （Centralized Version Control Systems，簡稱CVCS） 差異，Git的分佈式特徵使得開闢者間的合作變得越發靈活多樣。

這時刻我們會想到：

1. 什麼又是版本掌握呢？
2. 什麼是分佈式什麼是集合式？

我們帶着題目往下走。

版本掌握

版本掌握是一種紀錄一個或多少文件內容變化，以便未來查閱特定版本訂正狀況的體系。

比方：有一名順序員他能夠須要保存一個代碼文件的一切的訂正版本，如許就能夠

• 將某個文件回溯到之前的狀況
• 以至將悉數項目都回退到過去某個時刻點的狀況
• 比較文件的變化細節，查出末了是誰修改了哪一個處所，從而找出致使奇異題目湧現的緣由

這時刻採用版本掌握就是一個異常明智的挑選，運用版本掌握體系平常還意味着，就算你瞎攪一氣把悉數項目中的文件改的改刪的刪，你也照樣能夠輕鬆恢復到本來的模樣。 但分外增添的事情量卻微不足道。

版本掌握的生長

兒童：人們經由過程複製悉數項目標體式格局來保存差異的版本，或許還會改名加上備份時刻以示區分。長處就是簡樸，然則迥殊輕易出錯，一不小心會寫錯文件或許掩蓋意想外的文件。

少年：人們為了上面的題目，很久之前就開闢了許多種當地版本掌握體系，大多是採用某種簡樸的數據庫來紀錄文件的歷次更新差異，比方个中比較盛行的 RCS 。

青年：人們又碰到一個題目，怎樣讓在差異體繫上的開闢者協同事情？ 因而，集合化的版本掌握體系（ CVCS）應運而生。 這類體系，諸如 CVS 、 Subversion ，都有一個單一的集合治理的服務器，保存一切文件的訂正版本，而協同事情的人們都經由過程客戶端連到這台服務器，掏出最新的文件或許提交更新。如今，每一個人都能夠在肯定程度上看到項目中的其他人正在做些什麼。 而治理員也能夠輕鬆掌控每一個開闢者的權限，而且治理一個 CVCS。

事分兩面，有好有壞。 這麼做最不言而喻的瑕玷是中間服務器的片面毛病。 假如關機一小時，那末在這一小時內，誰都沒法提交更新，也就沒法協同事情。 假如中間數據庫地點的磁盤發作破壞，又沒有做適當備份，毫無疑問你將喪失一切數據——包括項目標悉數變動汗青，只剩下人們在各自机械上保存的零丁快照。

丁壯：因而分佈式版本掌握體系面世了。 在這類體系中，像 Git 、 Mercurial 等，客戶端並不只提取最新版本的文件快照，而是把代碼堆棧完整地鏡像下來。 這麼一來，任何一處協同事情用的服務器發作毛病，預先都能夠用任何一個鏡像出來的當地堆棧恢復。 因為每一次的克隆操縱，現實上都是一次對代碼堆棧的完整備份。

許多這類體系都能夠指定和多少差異的遠端代碼堆棧舉行交互。籍此，你就能夠在統一個項目中，離別和差異事情小組的人相互合作。 你能夠依據須要設定差異的合作流程，比方條理模子式的事情流，而這在之前的集合式體系中是沒法完成的。

git降生史記

許多人都曉得， Linus 在1991年建立了開源的 Linux ，今後，Linux 體系不斷生長，已成為最大的服務器體系軟件了。

Linus 雖然建立了 Linux，但 Linux 的壯大是靠全球熱情的志願者介入的，這麼多人在世界各地為 Linux 編寫代碼，那 Linux 的代碼是怎樣治理的呢？

事實是，在2002年之前，世界各地的志願者把源代碼文件經由過程 diff 的體式格局發給 Linus，然後由 Linus 本人經由過程手工體式格局兼并代碼！

你或許會想，為何 Linus 不把 Linux 代碼放到版本掌握體系裡呢？不是有 CVS、SVN這些免費的版本掌握體系嗎？因為 Linus 堅定地阻擋 CVS 和 SVN，這些集合式的版本掌握體系不只速率慢，而且必需聯網才運用。有一些商用的版本掌握體系，雖然比 CVS 、 SVN 好用，但那是付費的，和 Linux 的開源精力不符。

不過，到了2002年，Linux 體系已生長了十年了，代碼庫之大讓 Linus 很難繼承經由過程手工體式格局治理了，社區的弟兄們也對這類體式格局表達了強烈不滿，因而 Linus 挑選了一個貿易的版本掌握體系 BitKeeper，BitKeeper 的店主 BitMover 公司出於人性主義精力，受權 Linux 社區免費運用這個版本掌握體系。

安定團結的大好局面在2005年就被打破了，緣由是 Linux 社區牛人群集，難免感染了一些梁山英雄的江湖習慣。開闢 Samba 的 Andrew 試圖破解 BitKeeper 的協定（這麼乾的實在也不只他一個），被 BitMover 公司發現了（監控事情做得不錯！），因而 BitMover 公司怒了，要收回 Linux 社區的免費運用權。

Linus 能夠向 BitMover 公司道個歉，保證今後嚴厲管束弟兄們，嗯，這是不能夠的。現實狀況是如許的：

Linus 花了兩周時刻自身用 C 寫了一個分佈式版本掌握體系，這就是 Git！一個月以內，Linux 體系的源碼已由 Git 治理了！牛是怎樣定義的呢？人人能夠體味一下。

Git 敏捷成為最盛行的分佈式版本掌握體系，尤其是2008年，GitHub 網站上線了，它為開源項目免費供應 Git 存儲，無數開源項目最先遷移至 GitHub，包括 jQuery，PHP，Ruby等等。

汗青就是這麼有時，假如不是昔時 BitMover 公司要挾 Linux 社區，能夠如今我們就沒有免費而超等好用的 Git 了。

git的長處

在集合式體系中，每一個開闢者就像是連接在集線器上的節點，相互的事情體式格局大致相像。 而在 Git 中，每一個開闢者同時扮演着節點和集線器的角色——也就是說，每一個開闢者既能夠將自身的代碼孝敬到其他的堆棧中，同時也能保護自身的公然堆棧，讓其他人能夠在其基本上事情並孝敬代碼。 由此，Git 的分佈式合作能夠為你的項目和團隊衍生出各種差異的事情流程。

• 速率快
• 簡樸的設想，易用
• 對非線性開闢形式的強力支撐（許可不計其數個并行開闢的分支）
• 完整分佈式
• 有才能高效治理相似 Linux 內核一樣的超大規模項目（速率和數據量）

git完成道理

從根本上來說 Git 是一個內容尋址 （content-addressable） 文件體系，並在此之上供應了一個版本掌握體系的用戶界面，Git 的中心部份是一個簡樸的鍵值對數據庫 （key-value data store） 。 你能夠向該數據庫插進去恣意範例的內容，它會返回一個鍵值，經由過程該鍵值能夠在恣意時刻再次檢索 （retrieve） 該內容。

初始化的git目次

當在一個新目次或已有目次實行 git init 時，Git 會建立一個 .git 目次。 這個目次包括了險些一切 Git 存儲和操縱的對象。 如若想備份或複製一個版本庫，只需把這個目次拷貝至另一處即可。

$ ls -F1
HEAD
config*
description
hooks/
info/
objects/
refs/

這是一個全新的 git init 版本庫，這將是你看到的默許構造。

• description 文件僅供 GitWeb 順序運用，我們無需體貼。
• config 文件包括項目特有的設置選項。
• info 目次包括一個全局性消除（global exclude）文件，用以安排那些不願望被紀錄在 .gitignore 文件中的疏忽形式（ignored patterns）。
• hooks 目次包括客戶端或服務端的鈎子劇本 （hook scripts）。
• objects 目次存儲一切數據內容。
• refs 目次存儲指向數據（分支）的提交對象的指針
• HEAD 文件指導現在被檢出的分支
• index 文件保存暫存區信息。

git對象模子

一切用來示意項目汗青信息的文件,是經由過程一個40個字符的 （40-digit） “對象名”來索引的，對象名看起來像如許:

6ff87c4664981e4397625791c8ea3bbb5f2279a3

你會在Git里隨處看到這類“40個字符”字符串。每一個“對象名”都是對“對象”內容做 SHA1 哈希盤算得來的，（ SHA1 是一種密碼學的哈希算法）。如許就意味着兩個差異內容的對象不能夠有雷同的“對象名”。

如許做會有幾個長處：

• Git 只需比較對象名，就能夠很快的推斷兩個對象是不是雷同。
• 因為在每一個堆棧 （repository） 的“對象名”的盤算要領都完整一樣，假如一樣的內容存在兩個差異的堆棧中，就會存在雷同的“對象名”下。
• Git 還能夠經由過程搜檢對象內容的 SHA1 的哈希值和“對象名”是不是雷同，來推斷對象內容是不是正確。

對象

每一個對象 (object) 包括三個部份：範例，大小和內容。大小就是指內容的大小，內容取決於對象的範例，有四種範例的對象："blob" 、 "tree" 、 "commit" 和 "tag" 。

• “blob” 用來存儲文件數據，平常是一個文件。
• “tree” 有點像一個目次，它治理一些“tree”或是 “blob”（就像文件和子目次）。
• 一個“commit”只指向一個"tree"，它用來標記項目某一個特定時刻點的狀況。它包括一些關於時刻點的元數據，如時刻戳、近來一次提交的作者、指向上次提交 （commits） 的指針等等。
• 一個 “tag” 是來標記某一個提交 (commit) 的要領。

險些一切的 Git 功用都是運用這四個簡樸的對象範例來完成的。它就像是在你本機的文件體系之上構建一個小的文件體系。

Blob對象

一個 blob 平常用來存儲文件的內容。

Tree 對象

一個 tree 對象能夠指向一個包括文件內容的 blob 對象, 也能夠是別的包括某個子目次內容的別的 tree 對象，它平常用來示意內容之間的目次條理關聯。 Tree 對象、blob 對象和別的一切的對象一樣，都用其內容的 SHA1 哈希值來定名的；只要當兩個 tree 對象的內容完整雷同（包括其所指向一切子對象）時，它的名字才會一樣，反之亦然。如許就能讓Git 僅僅經由過程比較兩個相干的 tree 對象的名字是不是雷同，來疾速的推斷其內容是不是差異。

Commit對象

commit 對象指向一個 tree 對象，而且帶有相干的形貌信息。

一個提交 commit 由以下的部份構成：

• 一個 tree 對象：tree 對象的 `SHA1署名， 代表着目次在某一時刻點的內容。
• 父對象 (parent(s))： 提交 (commit) 的SHA1署名代表着當前提交前一步的項目汗青。兼并的提交 (merge commits) 能夠會有不只一個父對象。假如一個提交沒有父對象，那末我們就叫它“根提交” (root commit) ，它就代表着項目最初的一個版本 (revision)。 每一個項目必需有至少有一個“根提交”(root commit)。
• 作者 (author) ：做了此次修改的人的名字，另有修改日期。
• 提交者（committer)：現實建立提交(commit)的人的名字， 同時也帶有提交日期。
• 解釋：用來形貌此次提交。

注重：一個提交(commit)自身並沒有包括任何信息來申明其做了哪些修改； 一切的修改(changes)都是經由過程與父提交(parents)的內容比較而得出的。 值得一提的是, 只管git能夠檢測到文件內容穩定而途徑轉變的狀況， 然則它不會去顯式(explicitly)的紀錄文件的改名操縱(能夠看一下 git diff )。

平常用 git commit 來建立一個提交 (commit)， 這個提交 (commit) 的父對象平常是當前分支 (current HEAD) ，同時把存儲在當前索引 (index) 的內容悉數提交。

對象模子：

假如我們把它提交 (commit) 到一個 Git 堆棧中, 在 Git 中它們或許看起來就如下圖:

你能夠看到：每一個目次都建立了 tree對象 (包括根目次)， 每一個文件都建立了一個對應的 blob對象。末了有一個 commit 對象 來指向根 tree 對象 (root of trees) , 如許我們就能夠追蹤項目每一項提交內容.

標籤對象：

一個標籤對象包括一個對象名(SHA1署名), 對象範例, 標署名, 標籤建立人的名字(tagger), 另有一條能夠包括有署名(signature)的音訊.

回到我們的題目

壯大的git分支

有人把 Git 的分支模子稱為它的必殺技特徵，也正因為這一特徵，使得它 從浩瀚版本掌握體系中脫穎而出。

Git 保存的不是文件的變化或許差異，而是一系列差異時刻的文件快照。

在舉行提交操縱時，Git 會保存一個提交對象（commit object）。曉得了 Git 保存數據的體式格局，該提交對象會包括一個指向暫存內容快照的指針。 但不僅僅是如許，該提交對象還包括了作者的姓名和郵箱、提交時輸入的信息以及指向它的父對象的指針。初次提交發生的提交對象沒有父對象，一般提交操縱發生的提交對象有一個父對象，而由多個分支兼并發生的提交對象有多個父對象，

當運用 git commit 新建一個提交對象前，Git 會先盤算每一個子目次的校驗和（40 個字符長度 SHA-1 字串），然後在 Git 堆棧中將這些目次保存為樹（tree）對象。以後 Git 建立的提交對象，除了包括相干提交信息之外，還包括着指向這個樹對象（項目根目次）的指針，云云它就能夠在未來須要的時刻，重現此次快照的內容了。

Git 中的分支，實在本質上僅僅是個指向 commit 對象的可變指針。Git 會運用 master 作為分支的默許名字。在多少次提交后，你實在已有了一個指向末了一次提交對象的 master 分支，它在每次提交的時刻都邑自動向前挪動。

Git 是怎樣曉得你當前在哪一個分支上事情的呢？實在答案也很簡樸，它保存着一個名為 HEAD 的迥殊指針。在 Git 中，它是一個指向你正在事情中的當地分支的指針，我們能夠將 HEAD 設想為當前分支的別號。

因為 Git 中的分支現實上僅是一個包括所指對象校驗和的文件，所以建立和燒毀一個分支就變得異常低價。說白了，新建一個分支就是向一個文件寫入 41 個字節（外加一個換行符）那末簡樸，固然也就很快了。

大多數版本掌握體系它們治理分支大多採用備份一切項目文件到特定目次的體式格局，所以依據項目文件數目和大小差異，能夠消費的時刻也會有相當大的差異，快則幾秒，慢則數分鐘。

而 Git 的完成與項目複雜度無關，它永久能夠在幾毫秒的時刻內完成分支的建立和切換。同時，因為每次提交時都紀錄了先人信息（parent 對象），未來要兼并分支時，尋覓適當的兼并基本（譯註：即配合先人）的事情實在已自然而然地擺在那邊了，所以完成起來異常輕易。Git 勉勵開闢者頻仍運用分支，恰是因為有着這些特徵作保證。

分支的新建與兼并

1. 新建分支並進入

$ git checkout -b iss53

1. 依據需求寫代碼並提交

$ git commit -a -m 'new text'

1. 接到線上題目須要而且修改bug

$ git checkout master
$ git checkout -b hotfix
$ git commit -a -m 'fixed bug'

1. 兼并修改完bug的代碼進master（暫無爭執）

$ git checkout master
$ git merge hotfix

1. 處理題目后刪除hotfix分支並返回本來的iss53分支繼承事情

$ git branch -d hotfix
$ git checkout iss53
$ git commit -a -m 'finished'

1. 兼并iss53分支進主分支

$ git checkout master
$ git merge iss53

請注重，此次兼并操縱的底層完成，並差異於之前 hotfix 的併入體式格局。因為此次你的開闢汗青是從更早的處所最先分叉的。因為當前 master 分支所指向的提交對象（C4）並非 iss53 分支的直接先人，Git 不能不舉行一些分外處置懲罰。就此例而言，Git 會用兩個分支的末尾（C4 和 C5）以及它們的配合先人（C2）舉行一次簡樸的三方兼并盤算。

此次，Git 沒有簡樸地把分支指針右移，而是對三方兼并后的效果從新做一個新的快照，並自動建立一個指向它的提交對象（C6）。這個提交對象比較特別，它有兩個先人（C4 和 C5）。

有時刻兼并操縱並不會云云順遂。假如在差異的分支中都修改了統一個文件的統一部份，Git 就沒法清潔地把兩者合到一同。假如你在處理題目 #53 的過程當中修改了 hotfix 中修改的部份，將會湧現題目。

Git 作了兼并，但沒有提交，它會停下來等你處理爭執。

任何包括未處理爭執的文件都邑以未兼并 unmerged 的狀況列出。Git 會在有爭執的文件里到場規範的爭執處理標記，能夠經由過程它們來手工定位並處理這些爭執。

rebase 變基

最輕易的整合分支的要領是 merge 敕令，它會把兩個分支最新的快照（C3 和 C4）以及兩者最新的配合先人（C2）舉行三方兼并，兼并的效果是發生一個新的提交對象（C5）。:

然則，假如你想讓 experiment分支汗青看起來像沒有經由任何兼并一樣，另有別的一個挑選：你能夠把在 C3 里發生的變化補丁在 C4 的基本上從新打一遍。在 Git 里，這類操縱叫做變基 （rebase）。有了 rebase 敕令，就能夠把在一個分支里提交的轉變移到另一個分支里重放一遍。

$ git checkout experiment
$ git rebase master

它的道理是回到兩個分支近來的配合先人，依據當前分支（也就是要舉行變基的分支 experiment ）後續的歷次提交對象（這裏只要一個 C3），天生一系列文件補丁，然後以基底分支（也就是骨幹分支 master）末了一個提交對象（C4）為新的起點，逐一運用之前預備好的補丁文件，末了會天生一個新的兼并提交對象（C3’），從而改寫 experiment 的提交汗青，使它成為 master 分支的直接下流

簡樸講他就是把你的 experiment 分支里的每一個提交 commit 取消掉，而且把它們暫時 保存為補丁 patch (這些補丁放到”.git/rebase”目次中),然後把 experiment 分支更新 到最新的 origin 分支，末了把保存的這些補丁運用到 experiment 分支上。

如今的 C3′ 對應的快照，實在和一般的三方兼并，即上個例子中的 C5 對應的快照內容如出一轍了。雖然末了整合獲得的效果沒有任何區分，但變基能發生一個更加整齊的提交汗青。假如觀察一個變基過的分支的汗青紀錄，看起來會更清楚：似乎一切修改都是在一根線上前後舉行的，只管現實上它們原本是同時并行發作的。

在 rebase 的過程當中，或許會湧現爭執 conflict。在這類狀況，Git 會住手 rebase 並會讓你去處理 爭執；在處理完爭執后，用 git-add 敕令去更新這些內容的索引 index， 然後，你無需實行 git-commit ，只需實行：

$ git rebase --continue
如許git會繼承運用 apply 餘下的補丁。在任何時刻，你能夠用 --abort 參數來停止 rebase 的行為，而且 experiment 分支會回到 rebase 最先前的狀況。

$ git rebase --abort

git merge 應當只用於為了保存一個有效的，語義化的正確的汗青信息，而願望將一個分支的悉數變動集成到別的一個 branch 時運用 rebase。如許構成的清楚版本變動圖有着主要的代價。

一切其他的狀況都是以差異的體式格局運用 rebase 的合適場景：經典範體式格局，三點式，interactive 和 cherry-picking。

我們運用變基的目標：是想要獲得一個能在長途分支上清潔運用的補丁 — 比方某些項目你不是保護者，但想幫點忙的話，最好用變基：先在自身的一個分支里舉行開闢，當預備向主項目提交補丁的時刻，依據最新的 origin/master 舉行一次變基操縱然後再提交，如許保護者就不須要做任何整合事情（現實上是把處理分支補丁同最新骨幹代碼之間爭執的義務，化轉為由提交補丁的人來處理。），只需依據你供應的堆棧地點作一次快進兼并，或許直接採用你提交的補丁。

須要注重，兼并效果中末了一次提交所指向的快照，無論是經由過程變基，照樣三方兼并，都邑獲得雷同的快照內容，只不過提交汗青差異罷了。變基是根據每行的修改序次重演一遍修改，而兼并是把終究效果合在一同。

風趣的變基

• 我在差異的topic之間往返切換，如許會致使我的汗青中差異topic相互交織，邏輯上構造雜沓；
• 我們能夠須要多個一連的commit來處理一個bug；
• 我能夠會在commit中寫了錯別字，厥後又做修改；
• 以至我們在一次提交時地道就是因為懶散的緣由，我能夠吧許多的變動都放在一個commit中做了提交。
• rebase能夠兼并commit
• rebase能夠用來修改commit信息
• rebase能夠用來拆分commit

git rebase -i HEAD~3

變基也能夠放到其他分支舉行，並不肯定非得依據分化之前的分支。

變基的風險

要用它得恪守一條原則：

不要在大眾分支上運用rebase。

“No one shall rebase a shared branch” — Everyone about rebase

假如你遵照這條金科玉律，就不會出差錯。

在舉行變基的時刻，現實上揚棄了一些現存的提交對象而製造了一些相似但差異的新的提交對象。假如你把本來分支中的提交對象宣布出去，而且其他人更新下載后在其基本上開展事情，而稍後你又用 git rebase 揚棄這些提交對象，把新的重演后的提交對象宣布出去的話，你的合作者就不能不從新兼并他們的事情，如許當你再次從他們那邊獵取內容時，提交汗青就會變得一團糟。

注重rebase往往會重寫汗青，一切已存在的commits雖然內容沒有轉變，然則commit自身的hash都邑轉變。

結論：只需你的分支上須要rebase的一切commits汗青還沒有被push過(比方上例中rebase時從分叉處最先有兩個commit汗青會被重寫)，就能夠安全地運用git rebase來操縱。

上述結論能夠還須要修改：關於不再有子分支的branch，而且因為rebase而會被重寫的commits都還沒有push分享過，能夠比較安全地做rebase

思索下它的功用吧 git pull –rebase