版本控制系统是每一个开发流程中不可或缺的一部分。传统上，硬件设计公司为单独一个工程使用一个中央版本控制系统，但这样会强加给硬件团队很大的局限性。一个流行的可缓解此问题的解决方案就是像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的利弊总结如下：

您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证，并注明出处“路科验证”。

Git for Hardware Designers.pdf(618 KB)