16 KiB
第一章：Git 是什么？—— 你的时光机和协作利器
想象一下，你正在做一个大型的 Unity 项目，你和你的队友们分别负责不同的模块。
-
没有版本控制的噩梦：
-
你写好了一个功能，用微信发给主程，他手动合并到主项目里。
-
美术同学做好了一个新模型，替换了旧的，结果发现新模型有问题，但旧文件已经被覆盖，找不回来了。
-
你和另一个程序员同时修改了
PlayerController.cs脚本，最后提交的人把另一个人的代码给覆盖了，导致功能丢失。 -
一周后，游戏出了个大 Bug，你发现是你三天前某次修改引入的，但你已经不记得当时改了什么，也找不到三天前的版本了。
-
Git 就是为了解决以上所有问题而生的。
它是一个分布式版本控制系统 (Distributed Version Control System, DVCS)。我们拆解一下：
-
版本控制： 它可以帮你记录项目文件的每一次变化（谁在什么时间，改了哪个文件的哪几行）。你可以随时“回到过去”，查看任何一个历史版本。
-
分布式： 这是 Git 与早期工具 (如 SVN) 最大的不同。在 SVN 中，所有人都连接一个中央服务器。而 Git 中，每个开发者的电脑上都有一个完整的项目仓库（Repository），包含所有的历史记录。这意味着：
-
你可以在没有网络的情况下，在本地提交代码、查看历史、创建分支。
-
即使远程服务器（比如 GitHub）挂了，你的本地仓库也是安全的，不会丢失任何数据。
-
为什么 Unity 项目尤其需要 Git？
Unity 项目不仅有代码 (.cs 文件)，还有大量的二进制文件，比如场景 (.unity)、预制体 (.prefab)、模型 (.fbx)、贴图 (.png) 等。Git 结合一个叫做 Git LFS 的工具，可以完美地管理这些“大块头”，让团队协作变得井然有序。
第二章：核心概念 —— Git 的世界观
在敲任何命令之前，你必须先理解 Git 是如何“思考”的。这几个概念是基石中的基石。
2.1 仓库 (Repository / Repo)
简单说，就是你的项目文件夹。这个文件夹里的一切（代码、资源、修改历史）都被 Git 管理着。
-
本地仓库 (Local Repository): 存放在你自己电脑上的仓库。你日常的修改、提交等绝大部分操作都是在这里完成。
-
远程仓库 (Remote Repository): 存放在一台服务器上（比如 GitHub、Gitee 或公司自己的 GitLab），供团队成员共享和同步代码。它是团队协作的“集线器”。
2.2 Git 的三大区域
这是 Git 的精髓所在，理解了它，你就理解了一半的 Git 命令。
-
工作区 (Working Directory): 就是你在电脑上能直接看到的项目文件夹。你用 Unity Editor、VS Code 等工具做的所有修改，都发生在这里。
-
暂存区 (Staging Area / Index): 一个“待提交”的区域。当你对工作区的文件做了修改后，你可以通过
git add命令，把这些修改“放”到暂存区。这给了你极大的灵活性，比如你改了10个文件，但这次只想提交其中的3个，你就可以只add这3个文件。 -
本地仓库 (Local Repository): 当你觉得暂存区里的内容可以作为一次完整的“版本”时，你使用
git commit命令，Git 会将暂存区的所有内容生成一个“快照”（我们称之为一次 提交 (Commit)），并永久保存在你的本地仓库中。
它们之间的关系如下图：
2.3 提交 (Commit)
一次 Commit 就是你对项目做的一次有意义的修改的“存档点”。它包含：
-
一个独一无二的 ID（一个长长的字符串，叫做 SHA-1 哈希值）。
-
提交者的信息（你的名字和邮箱）。
-
提交的时间。
-
提交信息 (Commit Message): 这是最重要的部分！用来清晰地描述“你这次提交干了什么”。写好 Commit Message 是团队协作的灵魂！
2.4 分支 (Branch)
如果说 Commit 是存档点，那 分支 就是平行的“故事线”。
-
主分支 (
master或main): 默认存在的分支。在团队中，它通常代表着最稳定、可随时发布的版本。 -
开发分支 (
develop): 通常我们的主要开发工作都在这个分支上进行。 -
功能分支 (
feature): 这是团队协作的核心。当你要开发一个新功能时（比如“新的背包系统”），你会从develop分支上创建一个新的分支，比如feature/inventory-system。然后你在这个新分支上尽情地编写代码、测试，完全不会影响到develop分支的稳定性。当功能开发完毕后，再把它 合并 (Merge) 回develop分支。
这种“先开分支 -> 再开发 -> 最后合并”的模式，是保证团队项目稳定、高效协作的基石。
第三章：准备工作 —— 为 Unity 项目量身定制 Git
在开始使用 Git 之前，我们需要做一些针对 Unity 项目的特殊配置。
3.1 安装与配置
-
安装 Git: 直接从 Git 官网 下载并安装。Windows 用户建议一路默认安装，这样会附带一个非常好用的命令行工具 Git Bash。
-
初次配置: 安装后，打开 Git Bash（或终端），设置你的身份。这个身份会记录在你的每一次提交里。
Bash
git config --global user.name "Your Name" # 替换成你的名字或常用昵称 git config --global user.email "you@example.com" # 替换成你的邮箱
3.2 .gitignore：告诉 Git 该忽略什么
Unity 在运行时会生成大量临时文件和本地缓存（比如 Library 文件夹），这些文件体积巨大且对其他团队成员毫无用处。我们必须告诉 Git 忽略它们，否则你的仓库会变得臃肿不堪，并且充满冲突。
在你的 Unity 项目根目录（与 Assets 和 ProjectSettings 文件夹同级）创建一个名为 .gitignore 的文本文件，然后把 GitHub 官方推荐的 Unity .gitignore 内容 复制进去。
核心要点是，它会忽略掉 Library, Temp, Logs, Build 等文件夹。
3.3 Git LFS：管理大文件的神器
Git 本身不擅长处理大的二进制文件（模型、贴图、音频等）。Git LFS (Large File Storage) 是一个专门解决此问题的扩展。它的原理是，在 Git 仓库里只保存大文件的“指针”（一个很小的文本文件），而真实的文件内容则存储在一个专门的 LFS 服务器上。
-
安装 LFS: 从 Git LFS 官网 下载并安装。
-
在项目中启用: 在项目根目录打开 Git Bash，运行：
Bash
git lfs install -
追踪文件类型: 告诉 LFS 哪些类型的文件需要由它来管理。
Bash
git lfs track "*.psd" "*.png" "*.jpg" "*.fbx" "*.asset" "*.unity" "*.prefab"这个命令会创建一个
.gitattributes文件。.gitignore和.gitattributes这两个文件都必须提交到 Git 仓库中！
第四章：单人模式 —— 熟悉核心命令
我们先在自己的电脑上，走一遍个人开发的全流程，熟悉最核心的命令。
4.1 获取项目
-
情况一：初始化一个全新的项目
Bash
# 进入你的 Unity 项目文件夹 cd path/to/your/unity/project # 初始化 Git 仓库 git init -
情况二：从远程仓库下载一个已有项目（团队中最常见的）
Bash
# 克隆远程项目到本地 git clone <远程仓库的URL> # 例如: https://github.com/your-team/your-project.git
4.2 日常开发循环
这是你每天都要重复无数次的“三板斧”。
-
git status- 查看状态 这是最最常用的命令！它会告诉你：-
哪些文件被修改了？(modified)
-
哪些是新创建的文件？(untracked)
-
哪些文件已经被放入暂存区了？(staged) 养成随时随地敲
git status的好习惯！
-
-
git add <文件名>- 添加到暂存区-
添加某个文件:
git add Assets/Scripts/Player.cs -
添加整个文件夹:
git add Assets/Scripts/ -
添加所有修改和新文件（最常用）:
Bash
git add .
-
-
git commit -m "提交信息"- 提交到本地仓库Bash
git commit -m "feat: 实现玩家跳跃功能"-m后面跟着的是本次提交的说明。一定要写清楚！ 一个好的规范是：-
feat: 新功能
-
fix: 修复 Bug
-
docs: 修改文档
-
refactor: 代码重构
-
style: 代码格式调整
-
art: 美术资源更新
示例:
-
git commit -m "fix: 修复了打开商店UI时出现的空引用异常" -
git commit -m "art: 更新了主角色的行走动画"
-
4.3 git log - 查看历史
想看看你和队友们都干了什么？
-
git log: 显示详细的提交历史。 -
git log --oneline: 每个提交只显示一行，非常清晰。 -
git log --graph --oneline --decorate: 以图形化的方式显示分支合并历史，强烈推荐！
第五章：团队协作模式 —— 分支与远程操作
这才是 Git 真正强大的地方！
5.1 远程仓库交互
-
git push- 推送 将你本地的提交推送到远程仓库，这样队友才能看到你的代码。Bash
# 将本地的 develop 分支推送到名为 origin 的远程仓库 git push origin develop -
git pull- 拉取 从远程仓库获取最新的代码，并与你的本地分支合并。这是你每天早上开始工作前，必须执行的第一个命令！Bash
# 拉取远程的 develop 分支并与本地合并 git pull origin develop
5.2 黄金流程：功能分支工作流 (Feature Branch Workflow)
这是目前最流行、最安全的团队协作流程。
场景：你要开发一个“玩家登录”功能。
-
第一步：更新主开发分支 确保你的
develop分支是最新版本。Bash
git checkout develop # 1. 切换到 develop 分支 git pull origin develop # 2. 从远程拉取最新代码 -
第二步：创建你的功能分支 分支命名要清晰，比如
feature/user-login或fix/bug-123。Bash
# 创建并切换到新分支 git checkout -b feature/user-login -
第三步：在新分支上尽情开发 现在，你可以安心地在新分支上进行开发了。不断地
add和commit。Bash
# ... 编写代码，修改资源 ... git add . git commit -m "feat: 完成登录UI界面搭建" # ... 继续工作 ... git add . git commit -m "feat: 对接登录服务器API"你在
feature/user-login分支上的所有操作，都与develop分支无关，可以大胆尝试。 -
第四步：将你的分支推送到远程 这既是备份，也是为了让其他同事可以看到你的进度。
Bash
git push origin feature/user-login -
第五步：发起合并请求 (Pull Request / PR) 当你的功能开发完成并通过自测后，最关键的一步来了。你需要通过远程仓库的网页界面（GitHub/Gitee 等）发起一个 Pull Request。 它的意思是：“我 (
feature/user-login) 的功能做完了，请求项目负责人审查我的代码，并把它合并到develop分支。” 这是进行 代码审查 (Code Review) 的最佳时机。你的同事或主管会检查你的代码，提出修改意见。 -
第六步：合并与清理 一旦 PR 被批准，负责人会在网页上点击“Merge”按钮，你的所有代码就正式汇入
develop分支了！ 之后，这个功能分支就完成了它的历史使命，可以被删除了。Bash
# 切换回 develop 分支 git checkout develop # 删除本地分支 git branch -d feature/user-login # 删除远程分支 git push origin --delete feature/user-login
5.3 解决冲突 (Merge Conflict) —— 团队协作的必修课
当 A 和 B 同时修改了同一个文件的同一块区域时，git pull 或 git merge 时就会产生冲突。Git 不知道该听谁的，于是把决定权交给你。
-
识别冲突：
git pull后，Git 会在终端提示哪些文件冲突了。 -
解决冲突： 打开冲突的文件，你会看到类似这样的标记：
C#
<<<<<<< HEAD // 这是你本地的代码 public float speed = 10.0f; ======= // 这是远程仓库上你队友的代码 public float speed = 15.0f; >>>>>>> abcdef123... -
做出决定： 你需要和队友沟通，或者根据需求，手动修改这部分代码，决定最终的版本。比如，你们决定速度应该是
12.0f。C#
// 删除所有特殊标记，留下最终的代码 public float speed = 12.0f; -
完成合并：
Bash
git add <刚刚解决冲突的文件名> git commit # 此时不需要 -m，Git 会自动生成一个合并的提交信息
Unity 场景和预制体冲突是天坑！ .unity 和 .prefab 是二进制文件，它们的冲突极难用文本方式解决。 避免策略：
-
责任到人： 尽可能保证同一时间只有一个人在修改同一个场景或 Prefab。
-
化整为零： 尽量将大场景拆分成多个小 Prefab，分给不同的人负责。
-
加强沟通： 在修改一个公共 Prefab 或核心场景前，在团队群里吼一声：“我要改主场景的摄像机了，其他人先别动！”
第六章：高级技巧与最佳实践
-
git stash- 临时储藏： 当你正在开发一个功能，突然来了个紧急 Bug 要修，但你手头的代码还没写完，不想提交。怎么办？Bash
git stash # 将当前所有未提交的修改临时存起来 # ... 切换到别的分支修复 Bug，提交 ... git checkout feature/your-original-branch # 切回你原来的分支 git stash pop # 把之前存起来的修改恢复回来 -
图形化工具 (GUI)： 虽然命令行是基础，但在查看复杂的提交历史、处理分支和解决冲突时，使用图形化工具会更直观。推荐：SourceTree, Fork, 或者 VS Code 自带的 Git Lens 插件。它们可以帮你清晰地看到分支图和文件差异。
-
提交前编译： 在
git commit之前，一定要确保你的项目在 Unity Editor 里能正常编译通过。提交一个带编译错误的版本给团队，是非常不负责任的行为。 -
保持仓库整洁： 定期清理已经合并的、无用的本地和远程分支。
总结
掌握 Git 不是一朝一夕的事，但它绝对是你职业生涯中最值得投资的技能之一。
给你的学习路径建议：
-
理解核心概念： 仓库、三个区域、提交、分支。这是地基。
-
熟练个人流程：
status,add,commit,log。这是日常。 -
上手团队流程：
pull,push,branch,merge。这是协作。 -
在实践中学习： 不要怕犯错，主动去创建分支，甚至故意制造一些冲突来练习解决。Git 强大的地方在于，它几乎总能让你安全地回到任何一个历史版本。
从今天起，忘掉拖动文件夹和 U 盘吧。拥抱 Git，它会让你的开发工作变得前所未有的清晰、高效和安全。祝你在 Unity 的世界里，借助 Git 的翅膀，飞得更高！