2、版本控制（Git）：Git核心概念、工作流（Git Flow）、常用命令、.gitignore配置、分支管理策略

2.1 为什么版本控制是游戏开发的命脉

说实话，我见过太多游戏项目死在版本管理上。

有一次，团队里一个新人直接往 master 分支 push 了未压缩的 2GB 贴图资源。整个仓库瞬间膨胀到 5GB，同事拉代码要等半小时。嗯，那天下午我们啥也没干，就折腾 Git 了。

游戏开发和普通软件开发不一样。你想想看，一个项目里既有代码，又有几百 MB 的模型、贴图、音频。如果没有一套靠谱的版本控制策略，那简直就是灾难。

我个人习惯，在项目启动第一天就把 Git 工作流定死。谁也别想改。

2.2 Git 核心概念：别被术语吓到

Git 其实没那么玄乎。说白了，它就是一个快照系统。

2.2.1 工作区、暂存区、仓库

这三个概念我每次培训都要讲一遍。很多人搞混，其实很简单：

• 工作区：你正在编辑的文件夹。就是你的 Unity 或 Unreal 项目目录。
• 暂存区：一个临时存放区。你告诉 Git「这些文件我准备提交了」。
• 仓库：真正存历史版本的地方。本地叫本地仓库，远程叫远程仓库。

我在项目中遇到过最典型的错误：有人直接 git add . 把 10GB 的临时缓存文件全加进去了。结果 push 到远程仓库，整个团队都炸了。

2.2.2 提交（Commit）与 SHA-1

每次 git commit 都会生成一个 40 位的哈希值。这就是你的「存档编号」。

为什么用哈希？因为它是唯一的。你不用担心两个提交撞车。

我曾经犯过一个错：提交信息写的是「fix bug」。三天后回来看，完全想不起来修了啥。从那以后，我要求团队提交信息必须写清楚「改了哪个模块、为什么改」。

2.2.3 HEAD 与分支

HEAD 就是「你当前在哪儿」。它指向你当前所在的分支的最新提交。

分支呢？就是一条独立的开发线。你可以把它想象成平行宇宙。

2.3 分支管理策略：游戏项目的生存法则

游戏开发的分支策略和普通软件不太一样。因为游戏有资源、有策划配置、有美术资产，分支合并时冲突特别多。

2.3.1 我推荐的主干开发模型

我个人习惯用 Trunk-Based Development 的变体。不是纯主干，而是结合了 Git Flow 的优点。

分支类型	命名规则	用途
主分支	main	只放可发布的版本。谁也别直接推。
开发分支	develop	日常开发的主战场。所有功能分支从这里拉。
功能分支	feature/xxx	每个新功能或资源单独一个分支。
修复分支	hotfix/xxx	线上紧急 bug 修复。直接从 main 拉。
发布分支	release/x.x.x	版本发布前的最后测试和微调。

2.3.2 Git Flow 在游戏项目中的实战调整

标准的 Git Flow 太复杂了。我一般只保留核心部分：

1. 从 develop 拉 feature/xxx 分支
2. 开发完成后合并回 develop
3. 每周五从 develop 切一个 release 分支做周版本
4. 测试通过后合并到 main 并打 tag

你看，是不是简单多了？

2.4 常用命令：够用就行

我不建议背几百个 Git 命令。实际开发中常用的就十几个。

2.4.1 日常三板斧

# 查看状态
git status

# 添加文件到暂存区
git add filename.ext

# 提交
git commit -m "feat: 添加角色移动逻辑"

# 推送到远程
git push origin feature/player-move

2.4.2 分支操作

# 创建并切换到新分支
git checkout -b feature/ui-rework

# 切换分支
git checkout develop

# 合并分支（先切到目标分支）
git merge feature/ui-rework

# 删除本地分支
git branch -d feature/ui-rework

2.4.3 后悔药系列

# 撤销工作区的修改（还没 add）
git checkout -- filename.ext

# 撤销暂存区的文件（还没 commit）
git reset HEAD filename.ext

# 撤销最近一次提交（保留修改）
git reset --soft HEAD~1

# 彻底回滚到某个版本（慎用）
git reset --hard commit_hash

我曾经在项目上线前夜手滑执行了 git reset --hard，把一周的工作全丢了。还好有 git reflog 这个救命稻草。记住了，reflog 能找回你所有的操作记录。

2.5 .gitignore 配置：别让垃圾进仓库

游戏项目的 .gitignore 比普通项目复杂得多。因为引擎会生成大量临时文件。

2.5.1 Unity 项目必备

# 临时文件
[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Bb]uild/
[Bb]uilds/

# IDE 文件
*.csproj
*.sln
*.suo
*.user
*.userprefs

# 大资源缓存
*.asset
*.meta
!Assets/**/*.meta

# 日志
*.log

2.5.2 Unreal Engine 项目必备

# 中间文件
Intermediate/
DerivedDataCache/
Saved/

# 二进制资源
*.pdb
*.ilk
*.exp
*.lib

# 编辑器配置
*.sln
*.suo
*.user
*.vs/

2.6 工作流实战：一个典型的功能开发流程

假设你要开发一个「角色跳跃」功能：

1. 拉取最新代码：git checkout develop && git pull
2. 创建功能分支：git checkout -b feature/jump
3. 开发：写代码、调动画、测试
4. 提交：分多次提交，每次只改一个逻辑点
5. 合并回 develop：git checkout develop && git merge feature/jump
6. 解决冲突：如果有冲突，手动处理后再提交
7. 删除功能分支：git branch -d feature/jump

嗯，就这么简单。但很多人会在第 5 步翻车。合并冲突时不要慌，用 git mergetool 或者手动编辑文件都行。关键是别把别人的代码覆盖了。

2.7 避坑指南：我踩过的那些坑

• 大文件管理：游戏资源动辄几百 MB。别直接放 Git 仓库。用 Git LFS 或者专门的资源管理工具。
• 二进制文件冲突：场景文件、预制体、贴图，这些二进制文件冲突了没法自动合并。我的建议是：同一时间只让一个人改同一个场景。
• 提交频率：别一天只提交一次。我习惯每完成一个小功能点就提交一次。这样回滚时损失最小。
• 分支命名规范：统一用 feature/xxx、bugfix/xxx、hotfix/xxx。别起什么 my-branch、test123 这种名字，三个月后你自己都看不懂。