414 lines
16 KiB
Markdown
414 lines
16 KiB
Markdown
### **第一章：Git 是什么？—— 你的时光机和协作利器**
|
||
|
||
想象一下，你正在做一个大型的 Unity 项目，你和你的队友们分别负责不同的模块。
|
||
|
||
- **没有版本控制的噩梦：**
|
||
|
||
- 你写好了一个功能，用微信发给主程，他手动合并到主项目里。
|
||
|
||
- 美术同学做好了一个新模型，替换了旧的，结果发现新模型有问题，但旧文件已经被覆盖，找不回来了。
|
||
|
||
- 你和另一个程序员同时修改了 `PlayerController.cs` 脚本，最后提交的人把另一个人的代码给覆盖了，导致功能丢失。
|
||
|
||
- 一周后，游戏出了个大 Bug，你发现是你三天前某次修改引入的，但你已经不记得当时改了什么，也找不到三天前的版本了。
|
||
|
||
|
||
**Git 就是为了解决以上所有问题而生的。**
|
||
|
||
它是一个**分布式版本控制系统 (Distributed Version Control System, DVCS)**。我们拆解一下：
|
||
|
||
1. **版本控制：** 它可以帮你记录项目文件的每一次变化（谁在什么时间，改了哪个文件的哪几行）。你可以随时“回到过去”，查看任何一个历史版本。
|
||
|
||
2. **分布式：** 这是 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 命令。
|
||
|
||
1. **工作区 (Working Directory):** 就是你在电脑上能直接看到的项目文件夹。你用 Unity Editor、VS Code 等工具做的所有修改，都发生在这里。
|
||
|
||
2. **暂存区 (Staging Area / Index):** 一个“待提交”的区域。当你对工作区的文件做了修改后，你可以通过 `git add` 命令，把这些修改“放”到暂存区。这给了你极大的灵活性，比如你改了10个文件，但这次只想提交其中的3个，你就可以只 `add` 这3个文件。
|
||
|
||
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 安装与配置**
|
||
|
||
1. **安装 Git:** 直接从 [Git 官网](https://git-scm.com/downloads) 下载并安装。Windows 用户建议一路默认安装，这样会附带一个非常好用的命令行工具 **Git Bash**。
|
||
|
||
2. **初次配置:** 安装后，打开 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 内容](https://github.com/github/gitignore/blob/main/Unity.gitignore) 复制进去。
|
||
|
||
**核心要点是，它会忽略掉 `Library`, `Temp`, `Logs`, `Build` 等文件夹。**
|
||
|
||
#### **3.3 `Git LFS`：管理大文件的神器**
|
||
|
||
Git 本身不擅长处理大的二进制文件（模型、贴图、音频等）。Git LFS (Large File Storage) 是一个专门解决此问题的扩展。它的原理是，在 Git 仓库里只保存大文件的“指针”（一个很小的文本文件），而真实的文件内容则存储在一个专门的 LFS 服务器上。
|
||
|
||
1. **安装 LFS:** 从 [Git LFS 官网](https://git-lfs.github.com/) 下载并安装。
|
||
|
||
2. **在项目中启用:** 在项目根目录打开 Git Bash，运行：
|
||
|
||
Bash
|
||
|
||
```
|
||
git lfs install
|
||
```
|
||
|
||
3. **追踪文件类型:** 告诉 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 日常开发循环**
|
||
|
||
这是你每天都要重复无数次的“三板斧”。
|
||
|
||
1. **`git status` - 查看状态** 这是**最最常用**的命令！它会告诉你：
|
||
|
||
- 哪些文件被修改了？(modified)
|
||
|
||
- 哪些是新创建的文件？(untracked)
|
||
|
||
- 哪些文件已经被放入暂存区了？(staged) **养成随时随地敲 `git status` 的好习惯！**
|
||
|
||
2. **`git add <文件名>` - 添加到暂存区**
|
||
|
||
- 添加某个文件: `git add Assets/Scripts/Player.cs`
|
||
|
||
- 添加整个文件夹: `git add Assets/Scripts/`
|
||
|
||
- **添加所有修改和新文件（最常用）:**
|
||
|
||
Bash
|
||
|
||
```
|
||
git add .
|
||
```
|
||
|
||
3. **`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)**
|
||
|
||
这是目前最流行、最安全的团队协作流程。
|
||
|
||
**场景：你要开发一个“玩家登录”功能。**
|
||
|
||
1. **第一步：更新主开发分支** 确保你的 `develop` 分支是最新版本。
|
||
|
||
Bash
|
||
|
||
```
|
||
git checkout develop # 1. 切换到 develop 分支
|
||
git pull origin develop # 2. 从远程拉取最新代码
|
||
```
|
||
|
||
2. **第二步：创建你的功能分支** 分支命名要清晰，比如 `feature/user-login` 或 `fix/bug-123`。
|
||
|
||
Bash
|
||
|
||
```
|
||
# 创建并切换到新分支
|
||
git checkout -b feature/user-login
|
||
```
|
||
|
||
3. **第三步：在新分支上尽情开发** 现在，你可以安心地在新分支上进行开发了。不断地 `add` 和 `commit`。
|
||
|
||
Bash
|
||
|
||
```
|
||
# ... 编写代码，修改资源 ...
|
||
git add .
|
||
git commit -m "feat: 完成登录UI界面搭建"
|
||
# ... 继续工作 ...
|
||
git add .
|
||
git commit -m "feat: 对接登录服务器API"
|
||
```
|
||
|
||
你在 `feature/user-login` 分支上的所有操作，都与 `develop` 分支无关，可以大胆尝试。
|
||
|
||
4. **第四步：将你的分支推送到远程** 这既是备份，也是为了让其他同事可以看到你的进度。
|
||
|
||
Bash
|
||
|
||
```
|
||
git push origin feature/user-login
|
||
```
|
||
|
||
5. **第五步：发起合并请求 (Pull Request / PR)** 当你的功能开发完成并通过自测后，最关键的一步来了。你需要通过远程仓库的网页界面（GitHub/Gitee 等）发起一个 **Pull Request**。 它的意思是：“我 (`feature/user-login`) 的功能做完了，请求项目负责人审查我的代码，并把它合并到 `develop` 分支。” 这是进行 **代码审查 (Code Review)** 的最佳时机。你的同事或主管会检查你的代码，提出修改意见。
|
||
|
||
6. **第六步：合并与清理** 一旦 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 不知道该听谁的，于是把决定权交给你。
|
||
|
||
1. **识别冲突：** `git pull` 后，Git 会在终端提示哪些文件冲突了。
|
||
|
||
2. **解决冲突：** 打开冲突的文件，你会看到类似这样的标记：
|
||
|
||
C#
|
||
|
||
```
|
||
<<<<<<< HEAD
|
||
// 这是你本地的代码
|
||
public float speed = 10.0f;
|
||
=======
|
||
// 这是远程仓库上你队友的代码
|
||
public float speed = 15.0f;
|
||
>>>>>>> abcdef123...
|
||
```
|
||
|
||
3. **做出决定：** 你需要和队友沟通，或者根据需求，手动修改这部分代码，决定最终的版本。比如，你们决定速度应该是 `12.0f`。
|
||
|
||
C#
|
||
|
||
```
|
||
// 删除所有特殊标记，留下最终的代码
|
||
public float speed = 12.0f;
|
||
```
|
||
|
||
4. **完成合并：**
|
||
|
||
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 不是一朝一夕的事，但它绝对是你职业生涯中最值得投资的技能之一。
|
||
|
||
**给你的学习路径建议：**
|
||
|
||
1. **理解核心概念：** 仓库、三个区域、提交、分支。这是地基。
|
||
|
||
2. **熟练个人流程：** `status`, `add`, `commit`, `log`。这是日常。
|
||
|
||
3. **上手团队流程：** `pull`, `push`, `branch`, `merge`。这是协作。
|
||
|
||
4. **在实践中学习：** 不要怕犯错，主动去创建分支，甚至故意制造一些冲突来练习解决。Git 强大的地方在于，它几乎总能让你安全地回到任何一个历史版本。
|
||
|
||
|
||
从今天起，忘掉拖动文件夹和 U 盘吧。拥抱 Git，它会让你的开发工作变得前所未有的清晰、高效和安全。祝你在 Unity 的世界里，借助 Git 的翅膀，飞得更高！ |