GitHub Desktop备份 – Skyshin34的博客

本文最后更新于13 天前，其中的信息可能已经过时，如有错误请留言

原教程链接：https://www.youtube.com/watch?v=k-67Hr_433E

为什么选择Git作为版本控制方案

Why Git (GitHub)?
✓ Biggest ecosystem
✓ Large file support good enough (Git LFS)
✓ Popular
✓ No vendor lock-in

创建仓库绑定工程

1.创建一个新的仓库

2.配置设置

Name：项目文件夹名
Local Path：存放所有项目文件夹的路径
Git ignore：Unity(用以忽略Library里的缓存，即使删除也能在打开项目时在生成，能占项目存储的很大一部分，故忽略)

备份

Discard all changes…丢弃所有更改：
把工作区里未提交的修改直接还原到上一次提交（HEAD）的状态。可以无偿试错，发现无法进行时删除自上一个版本以来的所有修改

Stash all changes（暂存所有更改）把当前未提交的改动打包存到一个“临时堆栈”（stash），工作区恢复干净，方便切分支/拉代码。

🟨 黄色方块：Modified（已跟踪文件被修改）。
例：SampleScene.unity 被改动，提交后会记录新版本。

🟩 绿色加号：Added（新文件，已加入到待提交列表）。
例：BetterTest.cs 与其 .meta 是新建的；相当于 git add 之后尚未提交。

🟥 红色减号：Deleted（文件被删除，等待在下一次提交里移除）。
例：Test.cs 和 Test.cs.meta 将在提交中被删除；“Discard/Revert”可把它们从上一次提交恢复回来。

发布仓库(可选)

Private 默认启用，禁止其他人修改和下载。
发布之后可以在GitHub的仓库下载后，再Unity中复现工程

Push的注意事项

开始改之前先 Pull，先把别人最新的内容拉下来，不要基于旧版本改
不要直接改主场景，不要直接改主场景，不要直接改主场景
尤其是 .unity 场景文件很容易冲突，如果要测试可以新建自己的测试场景
不要上传 Library、Temp、Obj、Logs 这些文件夹（会被ignore）
Commit 信息写清楚改了什么
模型、贴图、音频这种大文件尽量确认 Git LFS 已经启用，不然文件太大可能上传失败

Push = 将本地commit的内容上传到 GitHub
Pull = 从 GitHub 下载别人最新修改

箭头含义是：

↑ 1 = 你本地有 1 个 commit 还没上传到 GitHub
↓ 2 = GitHub 上有 2 个 commit 你本地还没有

创建自己的分支（一次性操作）

顶部菜单：Branch > New Branch
- 命名可以以contributer的名字 + 添加的功能的模板 skyshin-ui
修改后点击Publish Branch把这个分支发布到 GitHub

Commit本地修改

这个提交是存档到本地，还没有上传到Github的仓库中

Push origin

origin = 远程仓库
将本地commit 的内容上传到 GitHub中
Push 到哪里，由什么决定：由你当前所在的分支决定
- 比如Current Branch显示为skyshin/ProgramEdit则上传到github的origin/skyshin/ProgramEdit

创建 Pull Request

Push 完之后，GitHub Desktop 通常会出现一个按钮：Create Pull Request
点它，会自动打开 GitHub 网页
如果没有这个按钮，也可以手动去网页：打开你的 GitHub 仓库页面
点上方的：Pull requests – New pull request
选择合并方向，例如base: main compare: skyshin/ProgramEdit，则是将把 skyshin/ProgramEdit 合并到 main

Fetch Origin

如果显示 Fetch origin，通常说明“当前分支”和 GitHub 上对应的远程分支暂时没有需要 Pull / Push 的内容
如果有远程新内容：会变成 Pull origin，说明 GitHub 上有别人提交的新版本，你需要拉下来
本地有新Commit会变成 Push origin，说明你本地有 commit 还没上传到 GitHub
既有本地提交，也有远程提交：会显示 ↑ ↓，说明你和 GitHub 两边都有新内容，通常需要先 Pull，再 Push

Merge Pull Request（最好检查的负责人做这件事情）

打开 GitHub 仓库网页
负责人检查修改内容没问题后点击Merge Pull Request = 把某个成员的分支合并进 main，再点击 Confirm merge

解决 Pull Request 冲突

创建分支并解决合并冲突——Unity 学习

当 GitHub 页面显示：Merge conflicts This branch has conflicts that must be resolved
说明你的分支和 main 修改了同一个文件，Git 不知道该保留谁

在 Pull Request 页面点击：Resolve conflicts

Gamejam实战（3天）

如果是小型合作，比如这次和GameJam的队友全程同步研发，可以都向主分支提交，这样就不用Request了
每次修改前要记得拉取一下最新的版本
其实只要不同时修改一个预制体，是可以同时在一个场景中修改的（不对！）
- 我们这次都在同一个场景里改但没冲突，是因为目前修改内容没有撞到一起，或者 Git 自动合并成功了。但同一个 scene 文件本身还是有冲突风险。最安全的规则还是：不要同时改同一个 Prefab、同一个 Scene 里的同一批物体、同一个配置 Asset。谁要大改场景，先在群里说一声，改完 push，其他人 pull 后再继续
看冲突文件类型
- 脚本就手动合并，观看代码判断保留哪边，或者手动合并两边逻辑
  - 删除 <<<<<<<、=======、>>>>>>> 这些标记
    3. 保存文件
    4. 回 GitHub Desktop
    5. 勾选文件
    6. Commit merge
    7. Push origin
- .unity 场景文件