开发过程中版本控制
宏觀角度看軟件版本控制
版本控制的核心是這樣一個簡單的概念，即對一個或者多個文件的追蹤過程，隨著這些文件演變成一個或多個產品的過程。特別是版本控制追蹤什么變化，是什么改變了它，為什么會這樣。版本控制系統提供了一個有益的說明，這寫說明在傳統的文件管理中是找不到的。
需要注意的是版本控制使用不僅是局限于程序員。版本控制可以被任何人用來維護文件目錄，因此即便你不是程序也可以繼續閱讀此文。版本控制系統有很多選項，對于本文，我將討論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命令去初始化一個空的存儲：
| 1 | git init |
接下來，我會驗證這個空的存儲，借用git status 命令：
| 1 | git status |
通常你會看到一條語句，nothing to commit 特別在目錄為空時。
你應該意識到一個隱藏的目錄稱之為.git,在那里保存了所有存儲元數據。如果你想回到Git存儲和所有完好的編輯歷史，確保包括這個.git文件夾。
在此，你或許想提交文件給你的存儲，但在你做任何事情之前，你必須設置兩個Git配置項。記住版本控制系統傾向于顯示說明。有鑒于此，我必須確保所有的源代碼編輯標記有我的名字和郵件。我設置兩個配置項：
| 12 | git config user.name “web3”git config user.email <a href="mailto:example@warrenbullock.me">example@warrenbullock.me</a> |
提交文件
現在我可以提交一些文件到我的存儲中。有鑒于此，我將通過Drupal7 網絡端存儲來說明版本控制。首先，我得告訴Git去跟蹤一個稱為style.css的類型表單。
| 1 | git add style.css |
如果詢問我的Git工作集的狀態，它會告訴我文件在提交時變化，緊隨新文件名之后。因為我知道存在一個叫style.css文件，它需要提交，我發布git commit命令：
| 1 | git commit |
在上面的例子中我沒有添加任何參數給commit命令。當你在用命令行工具，特別是—m選項，你只能添加一個簡短的信息版本，這條信息是條很重注釋。如果你不選—m 選項，命令行工具會給你打開一個默認的文本編輯器，這樣你就可以加入一個隨之而來長的注釋。我的默認文本編輯器是VIM。在我打入信息后，我按下逃逸鍵，然后我打入：wq to save and quit。借助于保存這個注釋并且推出VIM，我邊得知信息的狀態，1文件改變，1插入（+）。還有許多方法添加信息給一個文件提交。我能提供–a –m作為提交命令的一部分。–a簡單地意味提交所有文件在一個工作的目錄中。–m是提供一條信息，文件在提交之前發生了什么變化。
盡管我已經提交了sytle.css文件到存儲中，如果我發布git log命令，我會看到我原始的檢查：（譯者注添加）
| 1 | git log |
默認的git log輸出肯定讓人困惑，更優的選擇是git log –online – all。這個log，命令的變體將會僅僅展示當前存儲中的changeset IDs 和文件注釋。
有機會你可以比較文件的兩個不同版本。這個時常發生，因為常常存在沖突，Git不能確定那個文件版本需要保留。如果你想比較不同的style.css版本，我會用到git diff命令：
| 1 | git diffstyle.css |
返回到先前的某一個版本
不可避免地你打算返回或者回滾到某處正在工作的源代碼。這個過程很簡單當你用版本控制系統，特別是Git。關于這個，我已經檢查過我的style.css文件。我知道我我在存儲有一個可以依靠的版本。當我意識到需要返回我的style.css文件是，我簡單地在主干存儲中檢出它。我做了明確地編輯并且提交了變化。
很少的一部分選項，將代碼檢出加入一個工作集中，我能回滾多數當前的提交或者我能回歸到一個特定的修訂版本。如果我想回滾到許多當前的提交，我可以發布git checkout HEAD style.css命名：
| 1 | git checkout HEAD style.css |
或者我可以回滾到任何特定的修訂版本，借助于checkout命令 ，伴隨存儲中問文件guid（譯者注：數字標識符）。當我發布git log –oneline—all命令 所有的與文件名相關的guid都會展示出來，因此我可以回滾到一個特定修訂版本，比如此例中的98c12
| 1 | git checkout 98c12 sytle.css |
創建一個標簽和標記
在此，我僅有一個標識文件，借助uchangeset標識符和guid比如98c12.然而通常的例子，你需要鑒別真個存儲狀態，在開發周期中一個特殊的位置。一個軟件開發周期的例子或許是一個產品的發布。版本控制系統允許你提供人類可讀的名字給整個存儲，在Drupal7的例子中，它或許是-7.24。
Tagging and labeling often times是可互換術語取決于你所用的版本控制系統。因為我們正在用Git，我將要所指的過程作為標簽（tagging）。在Git創建一個tag，我能發布命令git tag：
| 1 | git tag drupal-7.24 |
如果我想確切地了解tag中存在什么，我可以發布命令：
| 1 | git show drupal-7.24 |
正如你可以檢出一個特定的文件到你的工作集，你也可以檢出一個特定的tag。我發布git checkout drupal-7.24:
| 1 | git Checkout drupal-7.24 |
標簽是一個超級強有力的概念特別是和分支和合并聯合在一起時。讓我們假設你需要些一個特定代碼為你的產品版本2.0.一種常見的策略是檢出標簽版本（1.0）。因為你已分支版本2.0，你可以編輯寫代碼。稍后，當你自信版本2.0已經可以發布了，你或許會將版本1.0和2.0返回到你的干或者主要分支中。記住，這是僅有的單一策略。你或許決定從不分支或者分叉代碼。這全取決于你。
分支和合并
或許多數用過的和有用的在版本控制系統的所有特征是分支。在Git中，分支和合并是非常容易和相當輕量級的。我可以創建一個新的分支，即發布git branch命令 緊隨其后的是新分支的名稱：
| 1 | git branch drupal-8.0.0 |
如果我發布命令git branch 沒有任何選項，我能看到一個列表的當前分支，附在我當前篩選的分支后。在Git中，你當前篩選的分支標注在星號和綠色的文本之間。
因為我確認過我在當前的主干分支中，我會發布checkout命令在新的分支有效標記為活躍狀態：
| 1 | git checkout drupal-8.0.0 |
正如你所想象的那樣，這是一個為實驗性代碼的完美沙盒。你可以自由地做任何你想做的，不需要考慮產品存儲。分支相連是一個逆過程，稱之為合并。合并允許你在分支中所做的改變，添加它們到重要的主干或者其它分支中。
合并分支借用Git是很簡單的。記住，檢查文件到你私人的分支常嬋是指向前整合。它的逆過程稱之為逆向整合，包括你檢查文件回到主要分支或者主干。唯一你可以決定是合適逆向或者向前整合代碼。盡管我猜它取決于多少開發人員參與你的產品開發，同時，取決于你私有和主要分支的有多活躍。
如果我想合并我的私有分支到主要分支或者主干，我會發布git merge命令，緊隨其后的是我想合并的分支名：
| 1 | 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。衷心希望你能采用一種你想要的版本控制系統。
【轉載自：iHk-system.com|尋訪諸神的網站】
轉載于:https://blog.51cto.com/ayuepm/1382248
總結
- 上一篇： .NET二级域名共享Session
- 下一篇： hive cli启动判断hadoop v