初始化obs/Unity仓库

2026-05-03 14:06:26 +08:00
commit 0d9e5282f3
95 changed files with 14419 additions and 0 deletions
@@ -0,0 +1,414 @@
+### **第一章：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 的翅膀，飞得更高！
@@ -0,0 +1,31 @@
+#### 1.委托和事件的区别
+#### 2.使用数组实现栈,队列,List
+#### 3.手撕排序算法
+#### 4.\==运算符和equals方法的区别
+#### 5.接口和抽象类的区别(从继承规则、成员类型、使用场景角度分析)
+区别：①继承：抽象类单继承，接口多实现；②成员：抽象类可包含非抽象成员，接口（C#8.0 前）全抽象；③场景：抽象类体现 “is-a” 关系（如 “狗是动物”），接口体现 “can-do” 能力（如 “会飞”）。
+#### 6.值类型和引用类型的区别
+#### 7.如何在不使用第三个变量的情况下交换变量
+
+##### 8.C#中的String和string的区别是什么
+
+##### 9.readonly和const的区别是什么
+
+10.讲一下c#的拆箱和装箱
+
+11.静态变量和非静态变量有什么区别
+
+12.方法重载和方法override的区别是什么
+
+13.c#的泛型是怎么一回事,它的作用是什么
+
+14.c#的string类为什么是不可变的
+
+15.String类和string类的区别是什么
+
+16.string和StringBuilder的区别是什么
+
+17.c#的lambda表达式是什么,带来了什么便利
+
+18.
+