本文轉自：http://www.eetop.cn/blog/html/28/1561828-437263.html

版本控制系統是每一個開發流程中不可或缺的一部分。傳統上，硬體設計公司為單獨一個工程使用一箇中央版本控制系統，但這樣會強加給硬體團隊很大的侷限性。一個流行的可緩解此問題的解決方案就是像Git這樣開源的分散式版本控制系統。

我們可以想象一個場景：一個團隊，一起研發一個複雜的可以被分割成上百個小塊的ASIC硬體專案，由前端設計，驗證，模擬和後端團隊一起完成，我們分析一下這個場景。

A.要求

RTL設計人員需要有一個自己完全獨立開發環境：需要自己的資料庫，有自己的歷史和分支結構。私人資料庫發生變化不能擾亂公共資料庫。

B.示例場景

設計師們需要不斷地平衡各種引數，如面積，時序，功耗，新功能等，為此，他們需要嘗試不同的方法，顯然，在此期間，設計人員不能影響其他團隊成員。即擁有一個私人資料庫，將此視為私人獨立開發環境，在這裡他們不必擔心影響他人，可以有自己的分支版本，等嘗試完成後，失敗的分支版本可以拋棄，成功的合併到主分支與他人共享。

C. Git 解決方案

Git是被設計用於管理多種版本庫工作的，當設計師克隆一個資料庫時，他們不只是複製這些檔案的最新快照過來，其實，他們映射了整個資料庫。因此，他們對他們的本地工作區專案有完整的版本歷史。

這與傳統的集中式版本控制系統（VCCS）有著根本的不同。傳統的：所有中心版本系統在一箇中央資料庫（在伺服器上），每個人都提交他們自己的更改，所有的提交都會出現在中央資料庫上。

D. 建議

從技術上講，Git不會附加任何語義值到任何儲存庫。然而，它有助於創造共享庫，設計人員可以繼續在其本地資源庫開發，但將這個中心資料庫視為與團隊的其他成員共享程式碼，以及維護程式碼的基礎版本（如果私人嘗試失敗，可以找回之前公共的版本）。

簡單介紹後，通過下面通用工作流程，進一步介紹一下Git的部分機制

A. 需求

RTL設計人員需要與硬體團隊的不同成員進行合作。對於一個子團隊的變化不能影響其他團隊。設計者需要將這些作為獨立的開發線，然後將它們手動合併到主幹。

B.示例場景

在我們的場景中，塊設計者可與以下團隊一起工作：

• 設計驗證小組（DV）

                     a.模組設計驗證 (BlockDV) 

                     b.晶片級整體驗證（ChipDV）

                     c.模擬團隊（EmulationDV）

• 形式驗證小組（FV）

• 後端物理設計團隊（PD）

                     綜合/時序/佈線

每個團隊都有不同的要求，儘管序列工作流程將是最簡單的設計，但它並不總是最快速，最有效利用資源的。

C.Git 解決方案

Git的解決方案是使用“分支”作為所有資源（檔案）發展的獨立的線路。Git允許整個分支跨資料庫共享資源。一般情況下，Git提供2種類型的分支：“本地”分支用於開發工作（獨立），而“遠端”分支允許協作（共享）。

分支是Git日常工作流程中不可或缺的一部分，因此應能快速建立，重新命名，合併和刪除。Git從概念上將分支視為指向特定提交連結串列的指標，由於每個提交（commit）都知道它的父，因此Git可以追蹤提交的歷史，重建提交的分支。使用Git可以自動採用合併多個不同版本的策略。

• 快進合併

          如果Git檢測到你要合併回原始分支，並且原始分支沒有新的提交，那麼它僅僅是“快進”的分支指標。如下圖所示，資料庫沒有變化。圖中，圓圈代表每次提交(commit)，箭頭反映父子關係。合併使得“master”指向“Branch_x”。

• 遞迴合併

          這適用於僅有兩個分支擁有共同的提交(commit)。Git會建立一個合併提交，它有兩個在各自分支裡最新的父。這就是所謂的3路合併，因為Git使用3個提交建立了合併的提交。合併前後概念圖如下所示：

• Rebase

          Rebase最大的好處是你的專案歷史會非常整潔。首先，它不像git merge 那樣引入不必要的合併提交。其次，rebase導致最後的專案歷史呈現出完美的線性。但是，如果你違反了Rebase黃金法則，重寫專案歷史可能會給你的協作工作流帶來災難性的影響。

D.建議

技術上，Git把所有分支等同。但我們建議在中央伺服器上建立一個名為“origin/develop”的分支，位於所有分支的頂部，所有的迴歸都在這個分支的頂端執行，一旦通過，將成為候選釋出物件。對於不同的子團隊之間共享程式碼，我們建議建立特性分支，這些分支最終會被刪除，可能是因為其合併回主分支，或者被丟棄。例如，一個設計人員可能有許多特性分支，每個分支都要獨立工作。

• origin/timing_fix_x 

         適用於配合物理設計團隊，對RTL嘗試各種更改，以修復時序問題

•  origin/bug_fix_PR100 

          適用於配合模組設計團隊，以修復在模組迴歸測試中出現的漏洞。

資料庫的一個可能的時間表如下圖所示。設計師建立了上面提到的兩個特性分支，一旦他們成功完成兩個功能，就將兩個特性分支合併回到“origin/develop”分支，當其它提交需要獨立工作時，develop分支繼續伴隨與之向前發展。

作為一個好的實際應用，特性分支應該不會生存很長時間。

設計師應該經常同步develop分支和特性分支，以保證它們不會相互偏離太遠。通過使用“rebase”策略，設計師可以在develop分支的頂層進行更改操作，以確保提交鏈線性歷史。對於重要的特性，一個好的做法就是在合併更改時不使用“fast forward”策略，因為“fast forward”策略不會建立提交歷史，這使得在特性分支合併到develop分支時，很難追蹤提交歷史。

總結：

使用Git進行硬體研發有很大好處。相比與傳統CVCS，Git的利弊總結如下：