第3章 Git核心操作

3、Git核心操作：从零开始管理你的验证代码

做芯片验证这几年，我见过太多因为版本管理混乱导致的惨案了。有一次，一个同事改了三天testbench，结果发现改的是旧版本——那种感觉，就像你辛辛苦苦搭好了验证环境，结果发现DUT版本不对。所以今天咱们聊聊Git最核心的几个操作，这些都是我每天都要用到的。

说白了，git init就是给一个普通文件夹「开光」，让它变成Git能管理的仓库。你想想看，没有这一步，Git根本不知道这个目录的存在。

核心用法：

# 在当前目录初始化Git仓库
git init

# 在指定目录初始化
git init my_verification_project

我个人习惯，每开始一个新验证项目，第一件事就是跑git init。跑完之后，目录里会多一个.git隐藏文件夹——别手贱去删它，删了你的版本历史就全没了。

小技巧：初始化后立刻创建.gitignore文件，把仿真生成的波形文件（.vcd、.fsdb）、日志文件、编译中间产物都写进去。我在项目中遇到过有人把几十GB的波形文件提交到仓库，那酸爽...

团队协作时，你很少自己从头init。更多时候是git clone——把服务器上的仓库完整复制到本地。

# 克隆一个远程仓库
git clone git@server:verification/uvm_project.git

# 克隆并指定本地目录名
git clone git@server:verification/uvm_project.git my_uvm

嗯，这里要注意：clone会把整个仓库的历史都拉下来，包括所有分支、所有标签。如果你的网络不太好，可以加个--depth 1只拉最新版本，但这样你就看不到历史了。

这个命令我一天能敲几十次。它告诉你三件事：哪些文件改了、哪些文件还没被跟踪、当前在哪个分支上。

# 查看完整状态
git status

# 简洁模式（我更喜欢这个）
git status -s

简洁模式下，M表示已修改，??表示未跟踪，A表示新添加。一眼扫过去就知道当前环境干不干净。

避坑指南：我曾经在提交前忘了跑git status，结果把一个调试用的临时文件也提交上去了。那个文件里写死了某个寄存器的地址，差点导致同事用错配置。所以提交前，一定先看一眼git status。

为什么要有暂存区？说白了，就是让你能「挑着提交」。你改了10个文件，但只想先提交其中3个跟bug修复相关的，剩下的等明天再提交——git add就是干这个的。

# 添加单个文件
git add tb_top.sv

# 添加所有改动（慎用！）
git add .

# 交互式添加（推荐）
git add -p

我个人强烈推荐git add -p。它会逐块显示你的改动，问你要不要添加。这样你能二次确认每个改动是不是你想要的。我在项目中遇到过有人git add .把不该提交的配置文件也加进去了，结果CI直接崩了。

提交是Git的核心操作。每次提交就像给代码拍了一张快照，以后随时可以回来。

# 提交并写提交信息
git commit -m "修复了AXI总线地址对齐的bug"

# 提交前自动格式化（配合编辑器）
git commit -v

提交信息怎么写？我有个简单的原则：

我的习惯：每次提交只做一件事。修复bug就只提交bug修复，加新功能就只提交新功能。这样以后用git bisect定位问题时，能精确找到是哪个提交引入了问题。

这个命令就像仓库的「日记本」，记录了谁在什么时候做了什么改动。

# 查看完整历史
git log

# 一行显示（简洁）
git log --oneline

# 图形化显示分支
git log --graph --oneline --all

# 查看某个文件的修改历史
git log --follow -p tb_top.sv

我最常用的是git log --oneline -10，只看最近10条提交。配合--graph能看清分支合并的脉络。

避坑指南：我曾经在调试一个UVM验证环境时，发现某个sequence的行为不对。用git log -p查看那个文件的修改历史，才发现是两周前一次「小优化」把配置参数写错了。如果没有Git历史，我可能得花一整天重新排查。

说了这么多，咱们串起来看看一个典型的验证工作流：

核心要点：

这些操作看起来简单，但真正用好需要时间。我刚开始用Git时也经常搞混add和commit的顺序，或者忘了push导致同事看不到我的改动。别急，多用几次就熟了。记住一点：在验证项目中，版本管理不是额外负担，而是保护你劳动成果的保险。