軟體版本控制介紹

　　本文集中討論版本控制如何工作。我將從巨集觀的角度開始，結尾將關注於一個具體的Git例子，Git是一個最近比較流行的版本控制系統。你或許已經知道這個版本控制主要用來追蹤和記載一個或者多個檔案的歷史記錄。然而，也許你還沒用過版本控制，也就不熟悉它的它提供的諸多好處，還有不確定每個系統的細微差別。

 

　巨集觀角度看軟體版本控制

　　版本控制的核心是這樣一個簡單的概念，即對一個或者多個檔案的追蹤過程，隨著這些檔案演變成一個或多個產品的過程。特別是版本控制追蹤什麼變化，是什麼改變了它，為什麼會這樣。版本控制系統提供了一個有益的說明，這寫說明在傳統的檔案管理中是找不到的。

　　需要注意的是版本控制使用不僅是侷限於程式設計師。版本控制可以被任何人用來維護檔案目錄，因此即便你不是程式也可以繼續閱讀此文。版本控制系統有很多選項，對於本文，我將討論Git。需要牢記的是，不管你最終選擇什麼樣的版本，都只有一個相同的目的，就是幫助你組織和保護你的原始碼和檔案。

　版本控制的概念

　　重要的是掌握基礎概念，特別是在你和你的團隊集中某一具體版本控制系統之前。這裡有三個具體的概念，我將在本文中專注於此。

• 原始碼支援
• 歷史視角（版本）和評價（說明）
• 回滾

　　在一些版本控制系統中，恢復某個檔案是可能的；在多數版本控制系統中，整個目錄的恢復也是可能的。得到一杯牛奶和你最好的餅乾，因為我在這裡要告訴你，猶豫是否改動原始碼的日子已一去不復返。舉個例子，在Drupal社群存在模組的沙盒版本，模組不過是產品程式碼的一個分支版本。

　　倘若你在一個開發團隊工作中弱化版本控制的使用，在你重寫工作中的產品程式碼，不可避免地造成一些收益和寶貴時間的損失。 許多程式設計師會得到豐厚的報酬，那在商業環境中損失是不可以接受的。

　　Git利用一個資料庫去追蹤和報導變化。舉個例子，假設此刻，我是一個是一個出色的Druper程式開發人員，為起居寫了軟體模組。我認為我需要重寫我的spectacular模組中的一個功能。我致力於將原始碼返回至儲存中，這個新的致力版本存在於Git的一個簡單類似資料庫的系統中。我不再去擔心追蹤它們的變化，相反Git會為我做這些工作。因為標註在致力過程中是必須的，我能追溯我的標註，如果我的模組是spectacular，為什麼我需要重寫它。我確信你熟悉軟體版本。比如Drupal釋出都會有其版本號。在我寫這篇文章時，Drupal7.24核心版本已經發布了。如果你正在使用版本控制你或許會指Drupal7.24作為一個標籤或者一個標記分支。標籤或者標記具有里程碑式的意義。

　　在我們深入之前，你必須熟悉幾個重要的術語。這些術語用一套規範的方式去定義，你能將這些知識用於如果不是全部至少是多數的版本控制系統。

• 儲存-儲存是個普遍術語。版本控制系統管理一個儲存，在Git中儲存實際上就是一個資料庫，在那裡文字和歷史都得到維護和儲存。
• 工作集-工作集包括檔案和資料夾。通常你會看到一個儲存包含多個工作集，這些工作集組織在通常稱作專案中。當你編輯一個工作集時，你順帶地就會升級儲存。版本控制最重要的事情就是，當你升級你的儲存時，你自動地建立了一個原始碼支援，不僅是儲存。關於工作集有一點需要記住的是，檔案包含潛在的變化已不在儲存中了。
• 新增和檢入-正如你猜測的那樣，新增是一個概念，即你新增新的檔案或者提交和查詢存在的檔案。
• 返回/回滾-如果你需要返回到早前的檔案版本，你將會返回或者回滾在儲存中任何版本的工作集。
• 檢出-如果你正在檢出儲存中的一個檔案，通常你會將主幹帶入你當地的工作集中。在一些案例中，檢出一個檔案的活動或鎖住這個檔案，以防其他的開發者使用。
• 分佈儲存系統-通常假設你在一個分佈儲存系統中工作，那真個儲存都在你本地的開發框內。Git就是一種分佈版本控制系統。如果你需要從儲存中查詢資料，你可以拉出資料。如果你需要新增或者檢查文字到儲存中，你可以推進資料。強烈建議，即使不需要用到SSH去和儲存互動如果它在一個遠端服務其中。
• 標籤和標記-此概念用來說明一個具體儲存的狀態。你或許標籤或者標記了一個你的Drupal模組版本，你認為可以穩定釋出的。
• 分支和分叉-這是一個常見的概念，即建立一個完整的儲存拷貝。通常，你會聽到一個沙盒程式碼的術語，它的意思是一個開發者已經分支或者分叉了一個專案儲存。
• 合併-如果你分支或者分叉了一個儲存，那麼你將不可避免地想要把你的原始碼推送到儲存的主幹或者主要分支中。推送分支或者分叉程式碼返回主幹的過程，就是指呼叫合併。

　集中 VS. 分佈版本控制系統

　　在本文中我將深入的討論Git，作為一種分佈版本控制系統。注意我不會深入探討集中版本控制系統的細節，集中版本控制系統不在本文討論範圍之內。在外殼，集中版本控制系統常用於大型軟體開發，你通常會碰到的兩個版本是Microsoft Team Foundation Server (TFS)和 Subversion.。我建議你花時間去學習集中版本控制系統，儘管，需要確定它們是否是你的開發壞境所需要的。

　　分佈版本控制工作與集中版本控制比較而言是不同的。特別是，當你在本地開發機器上初始化儲存。在你本地的開發儲存機器上，你有一個工作集，你在儲存中新增和升級了檔案。因為我會講到Git，你應該知道，可以用遠端儲存原始碼。通常遠端儲存會用到GitHub。不去涉及太多細節，GitHub是一個雲服務，藉助於此你可以將本地儲存放在雲端。

　Git的儲存行為

　　Git是一個分佈版本控制系統，它是一個開放程式碼專案，這個專案會用到GNU通用公共許可證版本2，因此它是免費的。你可以下載Git http://git-scm.com。

　　下載Git並且在安裝過程中，在多數情況下，安裝時的諸多預設選項很多。然而，出於本文的目的，我將選擇Git Bash作為僅有的殼型別，因為我感覺Linux命令列shell很舒服。同樣，我也選擇“Checkout Windows-style and commit Unix-style line endings”。在這個環境下，我可以使用儲存在蘋果或者Linux作業系統開發環境中。

　　安裝之後，你可以驗證Git安裝是否成功，即釋出來自Git Bash shell 的命令git–version。Git Bash shell 在安裝過程有提供 git –version。

　　如果你想看版本號以便git正確安裝，在開始版本控制時，你需要建立整個儲存或者一部分儲存，為你正在工作的專案。借用Git版本控制系統，你建立自己的儲存在你的本地開發機器上。記住，重要的是Git儲存需儲存在你檔案的相同目錄中。

　　為此，本文我將在dev目錄下進行工作。

　　來自dev目錄，我將執行git init命令去初始化一個空的儲存：

git init

　　接下來，我會驗證這個空的儲存，借用git status 命令：

git status

　　通常你會看到一條語句，nothing to commit 特別在目錄為空時。

　　你應該意識到一個隱藏的目錄稱之為.git,在那裡儲存了所有儲存後設資料。如果你想回到Git儲存和所有完好的編輯歷史，確保包括這個.git資料夾。

　　在此，你或許想提交檔案給你的儲存，但在你做任何事情之前，你必須設定兩個Git配置項。記住版本控制系統傾向於顯示說明。有鑑於此，我必須確保所有的原始碼編輯標記有我的名字和郵件。我設定兩個配置項：

git config user.name “web3”
git config user.email <a href="mailto:example@warrenbullock.me">example@warrenbullock.me</a>

　提交檔案

　　現在我可以提交一些檔案到我的儲存中。有鑑於此，我將通過Drupal7 網路端儲存來說明版本控制。首先，我得告訴Git去跟蹤一個稱為style.css的型別表單。

git add style.css

　　如果詢問我的Git工作集的狀態，它會告訴我檔案在提交時變化，緊隨新檔名之後。因為我知道存在一個叫style.css檔案，它需要提交，我釋出git commit命令：

git commit

　　在上面的例子中我沒有新增任何引數給commit命令。當你在用命令列工具，特別是—m選項，你只能新增一個簡短的資訊版本，這條資訊是條很重註釋。如果你不選—m 選項，命令列工具會給你開啟一個預設的文字編輯器，這樣你就可以加入一個隨之而來長的註釋。我的預設文字編輯器是VIM。在我打入資訊後，我按下逃逸鍵，然後我打入：wq to save and quit。藉助於儲存這個註釋並且推出VIM，我邊得知資訊的狀態，1檔案改變，1插入（+）。還有許多方法新增資訊給一個檔案提交。我能提供–a –m作為提交命令的一部分。–a簡單地意味提交所有檔案在一個工作的目錄中。–m是提供一條資訊，檔案在提交之前發生了什麼變化。

　　儘管我已經提交了sytle.css檔案到儲存中，如果我釋出git log命令，我會看到我原始的檢查：（譯者注新增）

git log

　　預設的git log輸出肯定讓人困惑，更優的選擇是git log –online – all。這個log，命令的變體將會僅僅展示當前儲存中的changeset IDs 和檔案註釋。

　　有機會你可以比較檔案的兩個不同版本。這個時常發生，因為常常存在衝突，Git不能確定那個檔案版本需要保留。如果你想比較不同的style.css版本，我會用到git diff命令：

git diff style.css

　返回到先前的某一個版本

　　不可避免地你打算返回或者回滾到某處正在工作的原始碼。這個過程很簡單當你用版本控制系統，特別是Git。關於這個，我已經檢查過我的style.css檔案。我知道我我在儲存有一個可以依靠的版本。當我意識到需要返回我的style.css檔案是，我簡單地在主幹儲存中檢出它。我做了明確地編輯並且提交了變化。

　　很少的一部分選項，將程式碼檢出加入一個工作集中，我能回滾多數當前的提交或者我能迴歸到一個特定的修訂版本。如果我想回滾到許多當前的提交，我可以釋出git checkout HEAD style.css命名：

git checkout HEAD style.css

　　或者我可以回滾到任何特定的修訂版本，藉助於checkout命令 ，伴隨儲存中問檔案guid（譯者注：數字識別符號）。當我釋出git log –oneline—all命令 所有的與檔名相關的guid都會展示出來，因此我可以回滾到一個特定修訂版本，比如此例中的98c12

git checkout 98c12 sytle.css

　建立一個標籤和標記

　　在此，我僅有一個標識檔案，藉助uchangeset識別符號和guid比如98c12.然而通常的例子，你需要鑑別真個儲存狀態，在開發週期中一個特殊的位置。一個軟體開發週期的例子或許是一個產品的釋出。版本控制系統允許你提供人類可讀的名字給整個儲存，在Drupal7的例子中，它或許是-7.24。

　　Tagging and labeling often times是可互換術語取決於你所用的版本控制系統。因為我們正在用Git，我將要所指的過程作為標籤（tagging）。在Git建立一個tag，我能釋出命令git tag：

git tag drupal-7.24

　　如果我想確切地瞭解tag中存在什麼，我可以釋出命令：

git show drupal-7.24

　　正如你可以檢出一個特定的檔案到你的工作集，你也可以檢出一個特定的tag。我釋出git checkout drupal-7.24:

git Checkout drupal-7.24

　　標籤是一個超級強有力的概念特別是和分支和合並聯合在一起時。讓我們假設你需要些一個特定程式碼為你的產品版本2.0.一種常見的策略是檢出標籤版本（1.0）。因為你已分支版本2.0，你可以編輯寫程式碼。稍後，當你自信版本2.0已經可以釋出了，你或許會將版本1.0和2.0返回到你的幹或者主要分支中。記住，這是僅有的單一策略。你或許決定從不分支或者分叉程式碼。這全取決於你。

　分支和合並

　　或許多數用過的和有用的在版本控制系統的所有特徵是分支。在Git中，分支和合並是非常容易和相當輕量級的。我可以建立一個新的分支，即釋出git branch命令 緊隨其後的是新分支的名稱：

git branch drupal-8.0.0

　　如果我釋出命令git branch 沒有任何選項，我能看到一個列表的當前分支，附在我當前篩選的分支後。在Git中，你當前篩選的分支標註在星號和綠色的文字之間。

　　因為我確認過我在當前的主幹分支中，我會發布checkout命令在新的分支有效標記為活躍狀態：

git checkout drupal-8.0.0

　　正如你所想象的那樣，這是一個為實驗性程式碼的完美沙盒。你可以自由地做任何你想做的，不需要考慮產品儲存。分支相連是一個逆過程，稱之為合併。合併允許你在分支中所做的改變，新增它們到重要的主幹或者其它分支中。

　　合併分支借用Git是很簡單的。記住，檢查檔案到你私人的分支常嬋是指向前整合。它的逆過程稱之為逆向整合，包括你檢查檔案回到主要分支或者主幹。唯一你可以決定是合適逆向或者向前整合程式碼。儘管我猜它取決於多少開發人員參與你的產品開發，同時，取決於你私有和主要分支的有多活躍。

　　如果我想合併我的私有分支到主要分支或者主幹，我會發布git merge命令，緊隨其後的是我想合併的分支名：

git merge drupal-8.0.0

　　正如我早前陳述的那樣分支和合並是粉盒版本控制系統兩個重要的特徵。用分支任何時候都可以確保主要分支和主幹或者其他分支保持完整。

　檢驗殼整合（再次關注Git）

　　在許多例子中，命令列介面針對的每個版本控制系統是你將會用到的，然而，許多版本控制系統同樣也支援掛在作業系統shell，通過shell整合概念。簡單地說，借用shell整合，你可以通過你的作業系統的視窗層和檔案取得互動。在微軟windows系統中，它會是windows Explorer，在Mac OS X中它是Macintosh Finder，在Linux分佈中，它是X windows system。借用shell整合，你可以新增檔案，檢入檔案，檢出檔案，返回，當前你所用的全部來自於shell的內部，通常shell整合選項出現在一個目錄選單中。

　　多數時候，版本控制系統也會提供可視的狀態顯示器，顯示檔案標識在查詢狀態。通常shell整合是一個可選的組建，在安裝版本控制系統中。

　圖形使用者介面工具(GUI)

　　除了命令列和shell整合，這裡還有另外一種流行的方法去訪問，一個版本控制系統的儲存。這個方法通常指的是GUI tool。

　　多數但非所有的GUI tool包括功能， 允許你做一些與命令列確實相同的操作。比如新增，檢入和檢出，回滾、分支和合並。或許GUI tool工具最大的優勢就是它能夠視覺化的檢查儲存並且在一個原始檔案瀏覽器重開啟檔案。

　　Git支援許多GUI tool。我推薦你看GUI 客戶頁，在Git專案網址http://git-scm.com/downloads/guis。有許多可選項可供選擇。我個人喜歡Windows的GitHub http://windows.github.com/，因為它而已很好的早windows平臺上執行，並且可以直接整合GitHub雲服務。

　　GUI 工具主要在於個人愛好，它們可以幫助你和你的團隊工作神速。如果你不喜歡用命令列，GUI 工具提供了一個很棒的選擇。

　選擇版本控制

　　此文中我已討論了一種特定的版本控制系統。儘管Git是一種很棒的選擇，但它可能不適合你的開發環境。有很多版本控制系統可以選擇。它們中比較流行的一些包括：Subversion，Microsoft’s Team Foundation Server,還有Mercurial。你或許會問，你怎麼知道那個版本控制系統適合你的開發環境呢？牢記這些考慮。

• 如果你在一個大型的團隊環境中工作，所有的開發人員一起工作在一個相同的辦公室，那麼你或許想試一試集中版本控制系統。Subversion、TFS或許很適合。
• 如果你開始組建你自己的團隊，那我強烈推薦你使用Git或者Mercurial。
• Git會掛入很多整合開發環境，並且提供GitHub雲服務。正如你或許知道的那樣，GitHub是一個免費的開放專案。如果你需要儲存商業程式碼，它依舊是可以承受的。Git能搞定它，對你而言很容易用Git儲存在你本地裝置上，接著推進你的變化週期性地Git 樞紐伺服器的雲端伺服器中。
• 如果你的軟體開發團隊分在世界的各個角落裡，Git和Mercurial將是一個很棒的選擇，因為你可以輸出和輸入以及傳送變化，借用email而無需建立一個伺服器基礎設施去儲存一個儲存。

　　如果你需要證明Git在現實世界中多麼有效，或許你感興趣的例子是知道，在你最喜愛的Linux分佈中的kernel儲存在Git儲存中，它的運作無需比如說，這個開發團隊很大分散在世界的各個角落裡。

　　選擇一個你覺得執行不錯的版本控制系統。如果你僅僅是開始，你在選擇是有很多回旋餘地，那我建議你使用Git。衷心希望你能採用一種你想要的版本控制系統。

　　原文連結： warrenbullock   翻譯： 伯樂線上 - tuzi37