Obsidian_Unity/就业/Git实战开发.md at main

Kingishu/Obsidian_Unity

Fork 0

Files

T

Kingishu 0d9e5282f3 初始化obs/Unity仓库

2026-05-03 14:06:26 +08:00

16 KiB

Raw Permalink Blame History

第一章：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 会在终端提示哪些文件冲突了。

解决冲突： 打开冲突的文件，你会看到类似这样的标记：

<<<<<<< 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 的翅膀，飞得更高！

16 KiB Raw Permalink Blame History Unescape Escape

第一章：Git 是什么？—— 你的时光机和协作利器

为什么 Unity 项目尤其需要 Git？

第二章：核心概念 —— Git 的世界观

2.1 仓库 (Repository / Repo)

2.2 Git 的三大区域

2.3 提交 (Commit)

2.4 分支 (Branch)

第三章：准备工作 —— 为 Unity 项目量身定制 Git

3.1 安装与配置

3.2 .gitignore：告诉 Git 该忽略什么

3.3 Git LFS：管理大文件的神器

第四章：单人模式 —— 熟悉核心命令

4.1 获取项目

4.2 日常开发循环

4.3 git log - 查看历史

第五章：团队协作模式 —— 分支与远程操作

5.1 远程仓库交互

5.2 黄金流程：功能分支工作流 (Feature Branch Workflow)

5.3 解决冲突 (Merge Conflict) —— 团队协作的必修课

第六章：高级技巧与最佳实践

总结

16 KiB

Raw Permalink Blame History

3.2 `.gitignore`：告诉 Git 该忽略什么

3.3 `Git LFS`：管理大文件的神器

4.3 `git log` - 查看历史