GitHu的誕生記 轉 https://blog.csdn.net/fanpeihua123/article/details/58151161
前言：這篇文章應讀者要求所寫，主要聊聊版本管理系統（Version Control System,簡稱 VCS）， 這篇文章不能讓你學會一門技術， 但是希望能幫你理解版本管理的原理。
“人肉” 版本管理
小李在大學裡很上進，把專業課學好之餘還經常跟著老師做點專案， 這些專案都不大， 小李經常一個人就能完成。
在電腦上寫程式碼的時候，小李也有煩惱： 修改了一個Java 類， 寫了一堆程式碼之後，突然想嘗試另外一個方案， 但是又不想放棄辛辛苦苦寫的這些程式碼 – 萬一新方案行不通呢?
怎麼辦？ 那就另存為一個新檔案吧，這是每個軟體都提供的標準功能。
於是小李的電腦上就出現了這樣的情況：
Person.java
Person_2015_10_12_還有希望.java
Person_2015_10_15_這個演算法也不錯.java
Person_2015_10_18_老師喜歡這個方案.java
(碼農翻身：這其實就是一種版本管理系統， 只不過是“人肉”版的， 我在大學時也這麼幹過，小微專案沒必要搞那麼複雜。)
鎖定檔案：避免互相覆蓋
後來老師給小李介紹了一個大一點的專案：線上商城， 類似京東的縮水版，即便如此， 一個人搞不定了。
小李叫來好基友小樑， 兩個人意氣風發，堅決要把這個專案如期拿下。
兩人把工作分了一下，小李負責訂單模組， 小樑負責產品模組，還有個公用的部分，誰都可以改。
專案也相應的分了這麼幾個大目錄：Order，Product， Common
兩人約定各自悶頭開發，每週把程式碼合併一次測試， 合併的方法就是小樑把所有程式碼都複製給小李。
第一週相安無事。
第二週相安無事。
第三週兩個人就打起來了。
因為小李把小樑的程式碼複製到自己電腦以後， 發現出了大問題：自己對Common目錄下的public.js做了大改， 程式碼改動了好幾百行，可是這些改動竟然被小樑的public.js覆蓋掉了, 這一週的改動都丟失了 ！
兩人吵了半天，最後還得尋求解決辦法, 有室友推薦了個軟體BeyondCompare ， 可以清晰的比較兩個人的程式碼目錄和檔案，改動一目瞭然。
小李和小樑試用了一下，BeyondCompare 很好很強大， 只是改動多了，手工工作量還是挺大的。
乾脆一不做，二不休， 開發一個版本控制系統（Version Control System）得了， 徹底解決檔案被覆蓋的問題。
這個VCS有這樣的功能：
(1) 支援把程式碼放到一個伺服器上， 這樣就是本地電腦出了問題也不怕
(2) 任何人如果想對一個檔案進行修改， 需要先對該檔案做一個操作： checkout, 這會把檔案鎖住，其他人無法修改
(3) 修改完以後， 需要做一個checkin 操作， 修改會被髮到伺服器端儲存， 形成新的版本， 並且釋放檔案鎖
(4) 可以支援回退的功能，也就是說，可以回退到之前的版本去。
碼農翻身注： 微軟的Visual SourceSafe就是這種風格的：檔案被一個人獨佔式的鎖住進行修改，如下圖，標記為紅色的檔案就是被特定使用者鎖住了。
這個VCS包括伺服器端，主要用來存放程式碼，進行版本管理。
還有一個客戶端，主要用來和伺服器端打交道，checkout/check in 程式碼。
允許衝突：退一步海闊天空
有了這個VCS , 小李和小樑如虎添翼， 再也不怕合作期間檔案互相覆蓋的問題了。
只是原定半年要完成的專案，毫無懸念的要延遲了。
老師又給小李和小樑介紹了三個師弟，進來幫助加快進度。
小師弟們對VCS不太熟， 經常性的把自己根本不用修改的檔案也都checkout 出來， 並且遲遲不checkin , 搞的其想修改程式碼的人根本沒法修改。
不止是小師弟們， 連小李和小樑也經常犯類似的錯誤， 讓大家工作起來非常的不爽。
怎麼辦呢？ 小李去找小樑商量： “要不咱把鎖檔案的功能去掉？ “
小樑說： “可是兩個人，甚至多個人改了同一個檔案怎麼辦？怎麼提交？ 以誰的為準？”
舉個例子，小李修改了Person.java , 並且成功的提交到了伺服器的VCS中。 與此同時，小樑也修改了Person.java , 提交的時候，系統就會提示：
“對不起， 小李已經修改了， 請下載最新版本。”
這時候小樑有兩個選擇：
(1) 把自己的修改先擇出來， 放到其他檔案中暫存， 然後把伺服器端的最新版本（包含小李的修改）下載到本機， 然後在把自己的修改加上去，最後提交到伺服器。
(2) 把VCS 客戶端 擴充套件一下，自動的去取伺服器端的最新版本，然後自己本地的Person.java做一個 Merge 。
這時候又會出現兩種情況：
A 小樑和小李的修改位於不同的地方， 沒有衝突，這時候就可以自動的Merge了，Merge後向伺服器端提交即可
B 小樑和小李對同一行進行的修改，出現了衝突， 這時候只好人工來確定到底用誰的程式碼了， 人工Merge後再想伺服器端提交。
鑑於同時改動一個地方的可能性雖然是有的，但是不常見，所以小李和小樑決定：
放棄檔案鎖， 提供一個Merge的功能就可以了。
(碼農翻身注：開源的版本管理系統CVS, SVN都是採用的這種方式)
分支：多版本並行
電子商城專案在師弟的幫助下，花了10個月才推向市場， 沒想到大受歡迎， 高興之餘，也帶來了新問題：
(1) 已經上市的老版本有不少Bug需要修改
(2) 使用者提了一大批新功能，有些新功能還需要修改老程式碼， 有的不需要。
很明顯，這就不能在一個程式碼庫中進行修改了， 如果這麼做， 那修正了老版本的Bug以後就沒法釋出了，因為也包含新功能的程式碼，可能還沒測試完成。
小李決定， 再次擴充套件現有的VCS， 支援分支的功能！
以剛剛釋出的產品為基準， 建立一個新的分支V2.0 , 原來的分支叫V1.0
由兩撥人分別在兩個分支上做開發， 這樣兩者互不衝突， V1.0的Bug 修改以後就可以釋出， 不用考慮V2.0
到了某一個時間點，例如V2.0開發完成，即將進入測試的時候， 需要把V1.0分支的程式碼修改Merge到V2.0中來， 為什麼要這麼做呢？
如果不Merge 過來， 那V2.0豈不還是有老版本遺留的Bug ？
當然Merge的時候有很大的可能會出現“衝突”，需要自動或者人工小心的處理掉。
如果在V2.0開發過程中，又有了新的需求， 還可以建立新的分支， 只要選擇好基於哪個出發點來建立就行了。
分散式管理：給程式設計師放權
隨著電子商務越來越火，越來越多的人也想用小李和小樑的這套軟體搭建獨立的一個電子商城系統。
小李決定把原始碼開放出去，讓網路上的程式設計師都參與進來開發， 讓電子商城系統發展壯大！
網際網路的力量遠遠超出小李的想象， 參與到這個電子商城系統開發的竟然高達幾百人。人多了，原來的版本管理系統有點力不從心了， 出現了各種新情況。
首先有些喜歡“小步提交”人感到特別不爽， 因為版本管理系統的伺服器是集中式的， 不太穩定，時不時停機， 導致他們無法提交程式碼。
其次出現了“多人一起競爭”的情況， 多個人都對同一個檔案進行了修改，為了獲得最新版本，非常麻煩，有時候以為自己拿到了最新版本，可是提交的時候發現還是被別人捷足先登，先提交了，只好再取一次最新版本來合併。
還有些人，喜歡兩個人之間先交流一下程式碼， 然後再提交到伺服器上， 由於現在沒有合適的技術，只好通過Email把檔案發來發去的方式來做。
但這些都不是最重要的，最重要的是有些程式設計師的程式碼沒有經過好好測試就提交進入了主要的程式碼庫， 惹了不少亂子。
如果在程式碼提交之前有人做一下程式碼審查就好了， 這樣能夠保證程式碼質量。
之前的程式碼倉庫是集中共享的， 這樣是無法解決現在遇到的問題的：
小李突發奇想： 要不給每個人設定一個原生代碼倉庫？
工作之前先把伺服器端的程式碼全部取到本地， 喜歡小步提交的人在本機想怎麼折騰就怎麼折騰， 沒有網路也能玩起來， 只有在必要的時候再提交到集中式的伺服器中去。
這麼做依然解決不了提交程式碼時進行評審的需求。
如果心胸再開闊一點，乾脆讓每個程式設計師的程式碼倉庫都獨立得了， 搞成這樣：
點選看大圖
工作流程也得改一改（仔細看，很重要）：
(1) 官方先設定一個程式碼倉庫
(2) 每個程式設計師都可以克隆官方的程式碼倉庫， 做出修改。
(3) 修改完以後，不直接推送到官方程式碼倉庫， 相反，推送到自己的程式碼倉庫去
(4) 通知專案維護者，請求他去拉取自己的修改
(5) 維護者在自己的私有程式碼倉庫，獲得貢獻者的修改， 然後決定是否接受這個修改
(6) 維護者將最新的改動推送到官方倉庫
這樣一來大家都輕鬆了， 每個人都有自己的一畝三分地， 想怎麼折騰就怎麼折騰， 兩個程式設計師之間也可以通過開放的程式碼倉庫交換程式碼了。
專案維護者終於對程式碼提交有了“審批”的功能， 只把那些好的程式碼納入到官方的倉庫中。
小李為新的版本控制系統起了個牛氣哄哄的名字，叫做 Hit ，他內心隱隱約約的覺得Hit才是版本管理系統的未來， 於是決定不再管那個什麼電子商城的鳥系統， 全力的投入到Hit的開發中來。
碼農翻身注：分散式版本管理系統除了Git之外，還有Mercury， IBM的RTC等。
程式設計師也愛社交
等到Hit系統釋出以後，小李驚奇發現，整個開源世界似乎發生了鉅變。
之前小李想參與一個開源專案，或者說拿到committer(提交者)許可權是非常非常難的，你得有很多的積累才行。
有一次小李發現了Struts的一個安全隱患,並且做了漂亮的修改， 但是苦於自己沒有提交許可權， 無法提交到Struts的程式碼倉庫中， 通過Email 把Bug fix 發給了Struts的維護者，幾乎是石沉大海。
現在好了，Hit是分散式的， 可以建立一個完全屬於自己的Struts程式碼倉庫了， 想怎麼改就怎麼改， 完全沒有限制。
如果覺得程式碼不錯， 就向Struts的官方維護者發一個請求， 讓他們去合併就可以了。
Hit受到了開源世界的極大好評。
小李決定趁熱打鐵，進一步降低使用Hit的門檻， 把Hit用一個Web系統包裝起來， 不但能完成上述基本功能， 還要做一點社交化的創新。
以後每個人都有自己的專屬頁面， 上面能展示自己的參與的開源專案，關注的專案，最近一段時間的活動（程式碼提交等等）
還要像微博那樣讓大家互相關注，那些推出了好專案，提交了好程式碼的大V就能變成程式設計師中的明星， 就像下面這位：
Linux 創始人 Linus Torvalds
小李決定把這個Web版本的原始碼管理系統叫做HitHub 。
程式設計師們在HitHub上玩的不亦樂乎，關注他人， 參加開源專案，合作，分享。慢慢的開源世界的主要專案都搬家到HitHub上來了。
連一些著名企業在招聘的時候，都要問應聘者的HitHub賬號，看看他在上面的活動情況。
HitHub火了。
1、開發工具的使用，積累工具的使用經驗，在工作中簡化工作量，讓工具代替人力去做事情；
2、當上面出來新的任務時，先思考問題解決的思路，尋找切實可行的、工作量較少的方案，記錄解決時所用的技術，以及解決問題的過程，把任務需求步驟寫出來，畫出流程圖，把具體應該實現的東西寫出來。
3、在工作中把自己修改的東西記錄下來，提交工作時同步修改，需要的東西進行備份（防止工作環境崩潰，損失檔案），把自己的工作內容記錄下來（每一個改動的作用）。因為工作中不是隻有自己一個人，是一個團隊的協作。如果不記錄，可能自己都忘了在專案中作了哪些修改。
4、看一些方法論的書籍，看一些論壇上別人解決問題的記錄。增加自己解決問題的思路，拓寬解決問題的思維。