第四章 版本控制入门：Git的安装与配置、常用命令与工作流

做芯片验证，说白了就是跟代码打交道。你写testbench，写checker，写scoreboard，一天下来改几十个文件是常事。刚开始我带项目的时候，团队里有人用U盘拷代码，有人用邮件发压缩包，结果版本乱得一塌糊涂。后来我强制所有人用Git，这才算把命根子保住了。

这一章，我就带你从零开始，把Git这套东西捋清楚。别怕，咱们不搞花架子，只讲验证工程师最常用的那几招。

4.1 Git的安装与配置

先装工具。Linux环境下，我习惯用命令行装：

sudo apt-get install git   # Ubuntu/Debian
sudo yum install git       # CentOS/RHEL

Windows的话，去官网下载Git Bash就行。装完第一件事，配身份信息：

git config --global user.name "Zhang San"
git config --global user.email "zhangsan@chip.com"

嗯，这里要注意。邮箱最好用公司邮箱，别用私人邮箱。我曾经有个同事用QQ邮箱提交代码，结果CI系统死活不认，排查了半天才发现是邮箱格式问题。

再配个别名，能省不少事：

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

4.2 常用命令：从clone到merge

命令不在多，够用就行。我总结了一套验证工程师的「黄金命令集」，你照着练就行。

4.2.1 clone —— 把仓库拉下来

拿到一个项目，第一件事就是clone：

git clone git@github.com:company/ip_verify.git
cd ip_verify

这里有个坑。如果仓库里有大文件（比如仿真波形），clone会特别慢。我建议用 --depth 1 只拉最新版本：

git clone --depth 1 git@github.com:company/ip_verify.git

4.2.2 commit —— 保存你的工作

改完代码，记得commit。我的原则是：一个commit只做一件事。

git add tb_uart.sv
git commit -m "fix: uart rx timeout issue"

为什么强调这个？我在项目中遇到过有人一个commit改了20个文件，既有bug fix又有新feature，结果review的时候根本没法看。后来回滚也麻烦，只能硬着头皮全盘接受。

4.2.3 push —— 把代码推上去

本地commit完了，得推到远程仓库：

git push origin master

如果你在分支上工作，记得指定分支名：

git push origin feature/uart_enhance

4.2.4 pull —— 同步最新代码

团队协作时，每天上班第一件事就是pull：

git pull origin master

pull其实是fetch + merge的组合。我个人更推荐先fetch看看别人改了啥，再决定怎么合并：

git fetch origin
git log --oneline origin/master..master
git merge origin/master

4.2.5 branch —— 分支管理

分支是Git的精髓。我常用的分支操作：

# 创建分支
git branch feature/uart_enhance

# 切换分支
git checkout feature/uart_enhance

# 创建并切换（一步到位）
git checkout -b feature/uart_enhance

# 查看所有分支
git branch -a

你想想看，如果没有分支，所有人都在master上改，那不乱套了？

4.2.6 merge —— 合并分支

功能开发完，要合并回主分支：

git checkout master
git merge feature/uart_enhance

合并时可能会冲突。别慌，Git会告诉你哪些文件冲突了，手动解决后重新add和commit就行。

4.3 GitFlow工作流

GitFlow是一种成熟的分支管理策略，特别适合芯片验证这种需要严格版本管理的场景。

说白了，GitFlow把分支分成几类：

分支类型	命名规则	用途
master	master	正式发布版本，只接受merge
develop	develop	日常开发主分支
feature	feature/xxx	新功能开发
release	release/x.x	发布前准备
hotfix	hotfix/xxx	紧急bug修复

我举个例子。假设我们要开发UART IP的验证环境：

1. 从develop分支创建feature分支：git checkout -b feature/uart_tb develop
2. 在feature分支上开发testbench、checker、scoreboard
3. 开发完成后，merge回develop：git checkout develop && git merge feature/uart_tb
4. 准备发布时，创建release分支：git checkout -b release/1.0 develop
5. 在release分支上做最终测试和文档整理
6. 测试通过后，merge到master和develop

嗯，这里要注意。如果线上发现紧急bug，直接从master创建hotfix分支：

git checkout -b hotfix/crc_error master
# 修复bug
git checkout master && git merge hotfix/crc_error
git checkout develop && git merge hotfix/crc_error

4.4 验证环境中的Git实践

最后，分享几个我在实际项目中用Git的经验：

• .gitignore要配好：仿真生成的波形文件、日志文件、编译中间文件都不要提交。我见过有人把几百MB的vcd文件push到仓库，结果所有人都要下载半天。
• 提交前做diff：git diff 看一下改了啥，避免把调试代码也提交上去。
• 用tag标记版本：每次仿真环境稳定后，打个tag：git tag v1.0.0。这样回滚时直接 git checkout v1.0.0 就行。
• 分支命名要规范：我习惯用 feature/模块名_功能描述，比如 feature/uart_baud_gen。一目了然。

Git这东西，刚开始用会觉得麻烦。但用顺手了，你会发现它就像你的第二大脑。每次改代码都心里有数，出了问题也能快速回退。说白了，版本控制不是束缚，而是给你自由。

下一章，我们聊聊自动化脚本。有了Git打底，脚本写起来就更有底气了。