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 重新考慮了以前每一代版本控制系統延續下來的諸多方面。 Git 更像是一個小型的檔案系統，提供了許多以此為基礎構建的超強工具，而不只是一個簡單的 VCS。稍後我們在Git 分支討論 Git 分支管理時，將探究這種方式對待資料所能獲得的益處。

更多詳情見請繼續閱讀下一頁的精彩內容： http://www.linuxidc.com/Linux/2017-06/144961p2.htm