独立游戏版本控制与项目管理实战：Git 工作流、分支策略与工具链完全指南

这是 「独立游戏版本控制与项目管理从 0 到 1 的完整实战手册」。

不讲虚的，只讲能落地的方法论和工具链，适用于：

✔ 刚开始做独立游戏、还在用「复制文件夹」备份的开发者
✔ 想从 SVN/Perforce 迁移到 Git 的小团队
✔ 已经用 Git 但没有规范流程、经常出问题的团队
✔ 需要管理美术/音频/关卡等二进制资产的跨职能团队

一、为什么版本控制是独立游戏开发的生命线

1.1 一组令人警醒的数据

根据 Game Developer Conference (GDC) 2024 年的开发者调查报告：

• 68% 的独立游戏开发者使用 Git 作为主要版本控制工具
• 17% 仍在使用「手动复制文件夹」的方式备份项目
• 在没有版本控制的项目中，42% 经历过「不可恢复的数据丢失」
• 使用版本控制的项目按时发布率比不使用的 高出 3.2 倍

另一项来自 IndieDB 的统计显示，在失败的独立游戏项目中，约 23% 的开发者将「项目管理混乱」和「资产版本丢失」列为项目终止的重要原因之一。

1.2 三个真实案例

案例 1：「那个被覆盖的存档」

某独立开发者花了 6 个月做了一个 Metroidvania 游戏，所有地图数据存在一个 JSON 文件里。某天深夜赶工，不小心用旧版本覆盖了新版本，丢失了整整 3 周的关卡设计。因为没有版本控制，没有任何回滚手段。这个项目后来延期了 4 个月。

案例 2：「合并地狱」

一个 3 人团队使用 Git 但没有分支策略。三个人同时修改同一个场景文件（.unity），导致合并冲突无法解决。Unity 的场景文件是 YAML 格式的，手动合并几乎不可能。最终他们花了 2 天时间手动重建场景，整个 Sprint 的进度归零。

案例 3：「20GB 的仓库」

一个团队把所有构建产物（Builds）也提交到了 Git 仓库，3 个月后仓库膨胀到 20GB。每次 git clone 需要 40 分钟以上，CI/CD 构建超时，团队成员苦不堪言。后来花了整整一周时间用 git filter-repo 清理历史，才把仓库缩减到合理大小。

1.3 版本控制的四大核心价值

二、Git 基础与游戏项目配置

2.1 Git 安装与初始化

macOS:

# 通过 Homebrew 安装最新版 Git
brew install git

# 验证安装
git --version
# git version 2.44.0 (Apple Git-170)

Windows:

从 git-scm.com 下载安装包，安装时勾选：

• Git Bash
• Git LFS
• 使用 LF 作为行尾符（推荐跨平台项目）

初始化游戏项目仓库:

cd MyGameProject
git init

# 配置用户信息
git config user.name "Your Name"
git config user.email "your@email.com"

# 推荐：设置全局默认分支名
git config --global init.defaultBranch main

# 创建第一次提交
git add .
git commit -m "chore: initial project setup"

2.2 .gitignore 配置

.gitignore 是版本控制的第一道防线。下面是三大引擎的完整模板：

Unity 项目 .gitignore:

# Unity generated folders
[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Bb]uild/
[Bb]uilds/
[Ll]ogs/
[Uu]ser[Ss]ettings/

# Memory capture
[Mm]emoryCaptures/

# Recordings
[Rr]ecordings/

# Asset metadata - 只忽略 .meta 以外的缓存
# 注意：.meta 文件必须提交！否则 Unity 的 GUID 会丢失
[Aa]sset[Ss]tore[Tt]ools*/

# Visual Studio cache/options
.vs/
*.csproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd
*.pdb
*.mdb
*.opendb
*.VC.db

# JetBrains Rider
.idea/

# Unity3D generated meta files
*.pidb.meta
*.pdb.meta
*.mdb.meta

# Builds
*.apk
*.aab
*.unitypackage
*.app

# Crashlytics
sysinfo.txt

# OS files
.DS_Store
Thumbs.db

Godot 项目 .gitignore:

# Godot specific
.godot/
*.import

# Exported builds
build/
export/

# Imported translations
*.translation

# Mono
.mono/
data_*/
mono_crash.*.json

# OS files
.DS_Store
Thumbs.db

# IDE
.vs/
.vscode/
*.csproj
*.sln
.idea/

Unreal Engine 项目 .gitignore:

# Unreal Engine
Binaries/
DerivedDataCache/
Intermediate/
Saved/
Build/

# Visual Studio
.vs/
*.sln
*.sdf
*.suo
*.opensdf
*.opendb
*.VC.db

# Rider
.idea/

# Compiled assets - 根据需要决定是否提交 cooked 资产
# *.uasset
# *.umap

# Crash reports
crashinfo/

# OS files
.DS_Store
Thumbs.db

⚠️ 重要提醒：Unity 的 .meta 文件必须提交！ 这些文件包含资产的 GUID，丢失后 Unity 会重新生成，导致所有场景和 Prefab 中的引用断裂。这是新手最常犯的致命错误。

2.3 Git LFS（Large File Storage）配置

为什么需要 LFS？

Git 天生是为文本文件设计的。游戏项目中有大量二进制文件：

不使用 LFS 的后果：

• 仓库快速膨胀，git clone 需要几十分钟
• 无法有效 diff 二进制文件
• GitHub 对单文件 > 100MB 直接拒绝推送

LFS 安装与配置

# 安装 Git LFS
# macOS
brew install git-lfs

# 或者从 https://git-lfs.github.com/ 下载

# 初始化 LFS（每个仓库只需一次）
cd MyGameProject
git lfs install

# 验证安装
git lfs --version
# git-lfs/3.5.1 (GitHub; darwin arm64; go 1.22.0)

追踪规则设置

# 追踪纹理文件
git lfs track "*.png"
git lfs track "*.jpg"
git lfs track "*.jpeg"
git lfs track "*.psd"
git lfs track "*.tga"
git lfs track "*.exr"

# 追踪 3D 模型
git lfs track "*.fbx"
git lfs track "*.obj"
git lfs track "*.blend"
git lfs track "*.max"

# 追踪音频
git lfs track "*.wav"
git lfs track "*.mp3"
git lfs track "*.ogg"

# 追踪视频
git lfs track "*.mp4"
git lfs track "*.mov"
git lfs track "*.avi"

# 追踪其他大文件
git lfs track "*.dll"
git lfs track "*.so"
git lfs track "*.dylib"
git lfs track "*.exe"
git lfs track "*.apk"
git lfs track "*.aab"

# 重要：.gitattributes 必须提交到 Git！
git add .gitattributes
git commit -m "chore: configure Git LFS tracking rules"

验证 LFS 状态：

# 查看当前追踪规则
git lfs track

# 查看 LFS 管理的文件
git lfs ls-files

# 查看 LFS 存储占用
git lfs status

存储限制与成本对比

💡 省钱技巧： 如果你的项目有大量美术资产（> 5GB），考虑使用 GitLab（免费额度更高）或自建 LFS 服务器（如 git-lfs-s3）。对于纯代码仓库，GitHub 的 1GB 免费额度通常够用。

2.4 仓库结构组织

推荐的通用游戏项目目录结构：

project-root/
├── Assets/                 # Unity 资产根目录
│   ├── Art/               # 美术资产
│   │   ├── Characters/    # 角色（模型/纹理/动画）
│   │   ├── Environments/  # 环境
│   │   ├── UI/            # UI 资产
│   │   ├── VFX/           # 特效
│   │   └── Concepts/      # 概念设计（可选，也可放外部）
│   ├── Audio/             # 音频
│   │   ├── Music/         # 音乐
│   │   ├── SFX/           # 音效
│   │   └── Voice/         # 语音
│   ├── Prefabs/           # 预制体
│   ├── Scenes/            # 场景
│   ├── Scripts/           # 代码
│   │   ├── Core/          # 核心系统
│   │   ├── Gameplay/      # 游戏玩法
│   │   ├── UI/            # UI 代码
│   │   └── Editor/        # 编辑器扩展
│   ├── Materials/         # 材质
│   ├── Shaders/           # 着色器
│   └── Plugins/           # 第三方插件
├── Docs/                   # 项目文档
│   ├── GDD/               # 游戏设计文档
│   ├── Art/               # 美术规范
│   └── Tech/              # 技术文档
├── Tools/                  # 开发工具/脚本
├── .gitignore
├── .gitattributes
└── README.md

Godot 项目结构：

project-root/
├── project.godot           # 项目配置（必须提交）
├── scenes/                # 场景文件 (.tscn)
├── scripts/               # GDScript / C# 代码
├── assets/
│   ├── art/               # 美术资源
│   ├── audio/             # 音频资源
│   └── fonts/             # 字体
├── addons/                # 插件（按需提交）
├── docs/                  # 文档
├── .gitignore
├── .gitattributes
└── README.md

⚠️ 永远不要提交的内容：

• Builds/ 目录（构建产物）
• Library/（Unity）或 .godot/（Godot）缓存目录
• 操作系统临时文件（.DS_Store, Thumbs.db）
• IDE 配置文件（.vs/, .idea/）
• 密钥和凭证文件

三、分支策略选择

3.1 Git Flow（适合大团队）

Git Flow 由 Vincent Driessen 在 2010 年提出，是最经典的分支模型。

分支结构：

main ─────●────────────────────●──────────────── (生产版本)
           \                  /
release ────●──────────●───── (发布准备)
             \        /
develop ──────●──●──●──●──●── (开发主线)
               \    /    \
feature/a ──────●──       (功能 A)
feature/b ──────────●──●─ (功能 B)

五种分支：

工作流：

# 1. 从 develop 创建功能分支
git checkout develop
git checkout -b feature/player-combat

# 2. 开发完成后合并回 develop
git checkout develop
git merge --no-ff feature/player-combat
git branch -d feature/player-combat

# 3. 准备发布时创建 release 分支
git checkout -b release/v1.0

# 4. 在 release 分支上修 bug、改版本号
# 5. 合并到 main 并打 tag
git checkout main
git merge --no-ff release/v1.0
git tag -a v1.0 -m "Release v1.0"

# 6. release 分支的修改也要合回 develop
git checkout develop
git merge --no-ff release/v1.0
git branch -d release/v1.0

优点：

• 清晰的角色分工，适合 5+ 人团队
• 发布流程严格可控
• 支持 hotfix 紧急修复

缺点：

• 流程复杂，学习成本高
• 对 1-3 人团队过于重型
• 分支多，合并冲突概率增加

3.2 GitHub Flow（适合小团队/独立开发者）

GitHub Flow 是 GitHub 推荐的轻量级分支模型。

分支结构：

main ────●────●────●────●────●──── (始终可部署)
          \  /  \  /  \  /
feat-a ────●     │     │         (短命分支)
feat-b ──────────●     │         (短命分支)
fix-c ─────────────────●         (短命分支)

工作流：

# 1. 从 main 创建功能分支
git checkout main
git checkout -b feature/inventory-system

# 2. 开发、提交
git add .
git commit -m "feat: implement inventory UI"

# 3. 推送到远程
git push -u origin feature/inventory-system

# 4. 创建 Pull Request
# （在 GitHub/GitLab 网页上操作）

# 5. 代码审查通过后合并到 main
# 6. 删除功能分支
git branch -d feature/inventory-system

优点：

• 简单直观，5 分钟就能学会
• 适合持续部署
• PR 机制天然支持代码审查

缺点：

• main 分支必须始终稳定，需要 CI 保障
• 不支持并行发布

3.3 Trunk-Based Development（适合持续交付）

所有人在同一条主干上开发，分支生命周期极短（通常 < 1 天）。

适用场景：

• 有完善的 CI/CD 流水线
• 有 Feature Flag 系统
• 团队有良好的测试习惯

3.4 独立开发者推荐策略：简化版 GitHub Flow

对于 1-3 人的独立游戏团队，推荐以下简化策略：

main ──────●────●────●──── (稳定版本，对应发布)
            \  /  \  /
feature ─────●     │      (功能开发)
bugfix ────────────●      (Bug 修复)

实际操作规范：

# 分支命名规范
feature/player-movement     # 新功能
feature/inventory-system    # 新功能
bugfix/collision-detection  # Bug 修复
release/v0.3-alpha          # 发布准备
hotfix/crash-on-startup     # 紧急修复
art/character-redesign      # 美术变更（可选）

# 保护 main 分支（即使是一个人）
# 在 GitHub Settings > Branches 中设置：
# - Require pull request reviews
# - Require status checks to pass

里程碑分支策略：

# 每个里程碑打 tag
git tag -a v0.1-prototype -m "M0: 原型验证完成"
git tag -a v0.3-vertical-slice -m "M1: 垂直切片完成"
git tag -a v0.7-alpha -m "M2: Alpha 版本"
git tag -a v0.9-beta -m "M3: Beta 版本"
git tag -a v1.0-release -m "M5: 正式发布"

四、提交（Commit）最佳实践

4.1 Conventional Commits 规范

推荐使用 Conventional Commits 格式：

<type>(<scope>): <subject>

<body>

<footer>

type 类型列表（游戏开发适配版）：

scope 建议（游戏项目常用）：

player, enemy, ui, combat, inventory, level, audio,
networking, save, input, camera, physics, vfx

完整示例：

feat(combat): implement parry system with timing window

- Add parry input detection with 0.3s timing window
- Successful parry reduces enemy stamina by 30%
- Add screen shake and particle effect on parry
- Play parry sound effect (parry_success.wav)

Closes #42

4.2 提交频率建议

推荐频率：

每天提交目标：1-3 个有意义的提交

❌ 反面案例：

# 太笼统
git commit -m "update"
git commit -m "fix stuff"
git commit -m "work"
git commit -m "..."

# 太大
git commit -m "everything since last month"

4.3 提交前检查清单

每次提交前过一遍这个清单：

□ 代码编译通过（无错误、无警告）
□ 游戏可以正常启动（不崩溃）
□ 修改的功能可以正常运行
□ 没有引入新的明显 Bug
□ 没有提交调试代码（Debug.Log、print 等）
□ 没有提交临时文件（.bak、.tmp 等）
□ 没有提交密钥/凭证
□ .meta 文件（Unity）已正确包含
□ 提交信息符合 Conventional Commits 规范
□ 大文件已通过 LFS 追踪

自动化提交检查（Git Hooks）：

# .git/hooks/pre-commit（需要 chmod +x）
#!/bin/bash

# 检查是否有超过 100MB 的文件未被 LFS 追踪
FILES=$(git diff --cached --name-only --diff-filter=ACM)
for FILE in $FILES; do
  SIZE=$(wc -c < "$FILE" 2>/dev/null || echo 0)
  if [ "$SIZE" -gt 104857600 ]; then
    echo "❌ 文件 $FILE 超过 100MB 但未使用 LFS"
    echo "   请运行: git lfs track \"$FILE\""
    exit 1
  fi
done

# 检查提交信息格式
COMMIT_MSG=$(cat "$1")
if ! echo "$COMMIT_MSG" | grep -qE "^(feat|fix|art|audio|level|perf|refactor|test|docs|chore|ci)(\(.+\))?: .+"; then
  echo "❌ 提交信息不符合 Conventional Commits 规范"
  echo "   格式: <type>(<scope>): <subject>"
  exit 1
fi

echo "✅ 提交前检查通过"

五、协作与代码审查

5.1 Pull Request（PR）工作流

即使是独立开发者，也推荐使用 PR 工作流，原因：

1. 强制自我审查：在创建 PR 的过程中，你会重新审视自己的代码
2. 历史记录：PR 自动记录为什么做了这个改动
3. CI 集成：PR 可以自动运行测试、构建验证
4. 未来协作：当你找到合作者时，流程已经就绪

PR 模板（.github/pull_request_template.md）：

## 改动说明
<!-- 简述这个 PR 做了什么 -->

## 改动类型
- [ ] 新功能 (feat)
- [ ] Bug 修复 (fix)
- [ ] 美术更新 (art)
- [ ] 音频更新 (audio)
- [ ] 性能优化 (perf)
- [ ] 重构 (refactor)
- [ ] 其他

## 测试情况
- [ ] 本地编译通过
- [ ] 相关功能手动测试通过
- [ ] 没有引入新的崩溃/错误

## 截图/录屏
<!-- 如果是视觉相关的改动，请附上截图 -->

## 相关 Issue
Closes #

5.2 代码审查清单（10 项检查点）

无论审查别人的代码还是自己的代码，逐项检查：

5.3 审查反馈模板

## 审查结论：🟢 通过 / 🟡 有小问题 / 🔴 需要修改

### 总体评价
<!-- 一两句话概括 -->

### 具体问题
- **文件:** `Scripts/PlayerController.cs:42`
  **问题:** 每帧都在 `GetComponent<>()` 会造成性能问题
  **建议:** 在 `Start()` 中缓存引用

- **文件:** `Scripts/CombatSystem.cs:108`
  **问题:** 硬编码了伤害值 `50`
  **建议:** 改为 `ScriptableObject` 配置

### 优点
<!-- 列出做得好的地方，鼓励好实践 -->

六、项目管理工具选择

6.1 工具横向对比

6.2 Trello 看板式

推荐看板结构：

📋 Backlog | 🔨 To Do | 🏗 In Progress | 👀 Review | ✅ Done

标签系统：

卡片模板：

## 描述
<!-- 这个任务要做什么 -->

## 验收标准
- [ ] 标准 1
- [ ] 标准 2

## 技术备注
<!-- 实现思路、注意事项 -->

## 预估工时
X 小时

## 相关资产
<!-- 需要的美术/音频/文档链接 -->

6.3 Notion（文档 + 任务）

推荐数据库结构：

Notion 的核心优势在于把设计文档、任务追踪、会议记录整合在一起。

📁 Game Design
  ├── GDD (Game Design Document)
  ├── Art Bible
  ├── Technical Design
  └── Audio Design

📁 Tasks
  ├── Sprint Board (看板视图)
  ├── Bug Tracker (表格视图)
  └── Milestones (日历视图)

📁 Meetings
  ├── Weekly Standup Notes
  └── Post-mortem

📁 Resources
  ├── Asset List
  ├── Reference Games
  └── Tools & Links

任务数据库属性：

6.4 GitHub Projects（集成式）

推荐配置：

# 看板列
- 📥 Backlog
- 📋 Ready (当前 Sprint 的任务)
- 🏗 In Progress
- 👀 In Review (等待 PR 审查)
- ✅ Done

# 自动化规则
- PR 被合并 → 自动移动到 Done
- Issue 被关闭 → 自动移动到 Done
- PR 被创建 → 自动移动到 In Review

Issue 模板（.github/ISSUE_TEMPLATE/feature_request.md）：

---
name: Feature Request
about: 新功能需求
title: '[FEAT] '
labels: feature
---

## 功能描述
<!-- 清晰描述想要的功能 -->

## 用户故事
作为 [角色]，我希望 [功能]，以便 [价值]。

## 验收标准
- [ ] 标准 1
- [ ] 标准 2
- [ ] 标准 3

## 技术方案（可选）
<!-- 如果有初步的技术思路 -->

## 参考（可选）
<!-- 参考游戏、截图、链接 -->

6.5 独立开发者推荐组合

最佳组合：Notion + GitHub Projects

• Notion：存放设计文档、美术参考、会议纪要、开发日志
• GitHub Projects：追踪任务、关联代码提交、管理 Sprint

工作流：

1. 在 Notion 中写设计文档 → 拆分任务
2. 在 GitHub Projects 中创建 Issue
3. 开发时在 Issue 上更新进度
4. 提交代码时关联 Issue（Closes #42）
5. 每周回顾 Notion 中的开发日志

七、里程碑与迭代计划

7.1 敏捷开发在游戏中的应用

游戏开发不完全等同于软件开发，需要适配：

7.2 Sprint 规划

推荐周期：2 周一个 Sprint

Sprint 流程：

Day 1: Sprint Planning（规划会）
  - 从 Backlog 中选取本 Sprint 目标
  - 估算工时，分配任务
  - 确定 Sprint Goal（一句话目标）

Day 2-9: 开发
  - 每日更新任务状态
  - 遇到阻塞及时沟通
  - 中期检查进度

Day 10: Sprint Review + Retrospective
  - 演示本 Sprint 成果
  - 回顾做得好/需要改进的地方
  - 更新 Backlog 优先级

Sprint 规划模板：

# Sprint X 规划

## Sprint Goal
<!-- 一句话描述本 Sprint 要达成的目标 -->
例：完成第一个完整地牢关卡，包含 3 种敌人和 1 个 Boss

## 选定任务
| 任务 | 类型 | 预估工时 | 负责人 | 优先级 |
|------|------|---------|--------|--------|
| 实现敌人 AI 巡逻行为 | Feature | 8h | Dev | P1 |
| 设计地牢第一层布局 | Level | 6h | Design | P1 |
| 制作 Boss 战斗阶段转换 | Feature | 12h | Dev | P1 |
| Boss 角色模型和动画 | Art | 16h | Art | P2 |
| 地牢环境音效 | Audio | 4h | Audio | P2 |

## 总预估工时：46h
## 可用工时：40h（2 周 × 5 天 × 4h 有效开发时间）
## 注意：工时超出，需要裁剪低优先级任务

7.3 里程碑定义

独立游戏开发的典型里程碑：

💡 关键建议： 每个里程碑都应该产出一个可玩的 Build。不要等到 Alpha 才让人玩到你的游戏。M0 的原型就应该能让朋友试玩。

7.4 燃尽图（Burn-down Chart）追踪

燃尽图是追踪 Sprint 进度的利器：

理想线 vs 实际进度

剩余工时(h)
40 |●
   |  \
30 |    ●───── 理想线
   |     \    \
20 |      ●────●── 实际进度
   |           \
10 |            ●
   |              \
 0 |________________●___
   Day1  Day3  Day5  Day7  Day10

健康燃尽图特征：

• 实际线在理想线附近波动
• 没有突然的上升（说明范围蔓延）
• 没有长时间的水平线（说明任务阻塞）

异常信号：

• 实际线持续高于理想线 → 任务估算过低或范围过大
• 实际线突然上升 → 有人新增了任务
• 实际线长时间水平 → 遇到了阻塞性问题

八、备份与灾难恢复

8.1 3-2-1 备份策略

这是业界公认的黄金备份法则：

8.2 自动备份脚本

macOS/Linux 备份脚本：

#!/bin/bash
# backup-game-project.sh
# 每日自动备份游戏项目

PROJECT_DIR="$HOME/projects/MyGame"
BACKUP_DIR="$HOME/backups/MyGame"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_NAME="backup_${DATE}.tar.gz"

# 创建备份目录
mkdir -p "$BACKUP_DIR"

# 压缩备份（排除不需要的目录）
tar -czf "${BACKUP_DIR}/${BACKUP_NAME}" \
  --exclude='Library' \
  --exclude='Temp' \
  --exclude='Obj' \
  --exclude='Build' \
  --exclude='Builds' \
  --exclude='.git' \
  -C "$(dirname "$PROJECT_DIR")" \
  "$(basename "$PROJECT_DIR")"

# 上传到云存储（使用 rclone）
rclone copy "${BACKUP_DIR}/${BACKUP_NAME}" backblaze:game-backups/

# 清理 30 天前的本地备份
find "$BACKUP_DIR" -name "backup_*.tar.gz" -mtime +30 -delete

echo "✅ 备份完成: ${BACKUP_NAME}"
echo "📦 大小: $(du -h "${BACKUP_DIR}/${BACKUP_NAME}" | cut -f1)"

设置定时任务（cron）：

# 编辑 crontab
crontab -e

# 每天凌晨 2 点自动备份
0 2 * * * /path/to/backup-game-project.sh >> /var/log/game-backup.log 2>&1

8.3 云备份服务对比

8.4 灾难恢复演练

每季度做一次恢复演练：

灾难恢复演练 Checklist：

□ 模拟场景：硬盘完全损坏
□ 从 Git 远程仓库克隆项目
  - 耗时：____ 分钟
  - 结果：成功 / 失败
□ 从云备份恢复最近一次备份
  - 耗时：____ 分钟
  - 结果：成功 / 失败
□ 验证恢复的项目可以正常编译和运行
  - Unity 打开：成功 / 失败
  - 编译通过：成功 / 失败
  - 游戏启动：成功 / 失败
□ LFS 资产完整性检查
  - git lfs fsck: 通过 / 有错误
□ 记录恢复耗时和遇到的问题
□ 根据演练结果更新备份策略

⚠️ 没有经过恢复演练的备份 = 没有备份。 很多开发者设了自动备份但从没测试过能否恢复，等到真正需要时才发现备份是坏的。

九、附录

附录 A：Git 常用命令速查表

# === 基础操作 ===
git init                           # 初始化仓库
git clone <url>                    # 克隆远程仓库
git status                         # 查看工作区状态
git add <file>                     # 添加文件到暂存区
git add .                          # 添加所有修改
git commit -m "message"            # 提交
git log --oneline --graph          # 查看提交历史（简洁图）
git diff                           # 查看未暂存的修改
git diff --cached                  # 查看已暂存的修改

# === 分支操作 ===
git branch                         # 列出本地分支
git branch <name>                  # 创建分支
git checkout <branch>              # 切换分支
git checkout -b <branch>           # 创建并切换分支
git merge <branch>                 # 合并分支
git branch -d <branch>             # 删除分支
git rebase -i HEAD~3               # 交互式变基（整理最近 3 次提交）

# === 远程操作 ===
git remote add origin <url>        # 添加远程仓库
git push -u origin main            # 推送并设置上游
git pull                           # 拉取并合并
git fetch                          # 只拉取不合并

# === LFS 操作 ===
git lfs install                    # 初始化 LFS
git lfs track "*.png"              # 追踪文件类型
git lfs ls-files                   # 查看 LFS 管理的文件
git lfs fetch --all                # 拉取所有 LFS 文件
git lfs prune                      # 清理本地 LFS 缓存

# === 撤销操作 ===
git checkout -- <file>             # 撤销工作区修改
git reset HEAD <file>              # 取消暂存
git reset --soft HEAD~1            # 撤销提交，保留修改
git revert <commit>                # 创建新提交来撤销某次提交

# === 标签操作 ===
git tag                            # 列出标签
git tag -a v1.0 -m "Release v1.0" # 创建带注释的标签
git push origin --tags             # 推送标签

# === 历史清理（危险操作）===
git stash                          # 暂存当前修改
git stash pop                      # 恢复暂存的修改
git filter-repo --path Builds/ --invert-paths  # 从历史中删除目录

附录 B：提交信息规范速查表

feat(combat): add parry system          # 新功能
fix(player): resolve double jump bug    # Bug 修复
art(character): update idle animation   # 美术更新
audio(boss): add phase 2 music          # 音频更新
level(dungeon): redesign floor 3        # 关卡变更
perf(rendering): batch draw calls       # 性能优化
refactor(ai): extract state machine     # 代码重构
test(inventory): add unit tests         # 测试
docs(gdd): update combat section        # 文档
chore(deps): update Unity to 2022.3     # 构建/依赖
ci(build): add automated builds         # CI/CD

附录 C：项目管理工具对比表

附录 D：独立游戏项目管理 Checklist

项目启动阶段：
□ 初始化 Git 仓库
□ 配置 .gitignore（引擎专用模板）
□ 配置 .gitattributes（LFS 追踪规则）
□ 设置分支策略和保护规则
□ 选择项目管理工具并创建看板
□ 创建设计文档模板
□ 建立目录结构规范
□ 设置 CI/CD 流水线（可选）

日常开发：
□ 每天至少 1 个有意义的提交
□ 提交信息符合 Conventional Commits
□ 功能开发在 feature 分支上进行
□ 合并前进行代码审查（即使是自己）
□ 每周更新项目管理工具中的任务状态
□ 每 2 周进行一次 Sprint 规划

里程碑节点：
□ 产出可玩的 Build
□ 打 Git Tag 标记里程碑版本
□ 进行一次完整的灾难恢复演练
□ 回顾并优化工作流程
□ 更新项目文档

总结： 版本控制和项目管理是独立游戏开发中最容易被忽视、却最难补救的基础设施。花 1 天时间配置好 Git + LFS + 分支策略 + 项目管理工具，能帮你避免未来几十天甚至几个月的灾难。不要等到项目崩溃的那一天，才后悔没有早点建立规范。