Github

Coding

基本操作 Clone & Fork

这两者都涉及“获取代码”，但目的完全不同

操作 物理本质 逻辑归属 适用场景
Fork 在 GitHub 云端 复制一份他人的仓库到你自己的名下。 代码现在属于你的账号，你可以随意修改且不影响原作。 给开源项目提修改建议，或基于他人模型二次开发。
Clone 将远程仓库（Remote）下载到本地电脑。 代码依然属于原作者 自己的项目，或者已被加入协作者名单的项目。
  1. 你在 GitHub 网页点 Fork
  2. 你 git clone 你自己 Fork 出来的仓库到本地
  3. 修改后 git push 回你自己的仓库
  4. 发起 Pull Request (PR) 请求原作者合并

任务管理：Issue

Issue 可以是反馈 Bug 的地方，也可以是一个项目看板

  • 用法：记录待办事项 (TODO)、功能需求 (Feature Request) 或学术讨论
  • 关联性：每个 Issue 都有一个编号（如 #12）。在 Commit message 里写 fix: resolve issue #12，GitHub 会自动建立链接
  • Label：利用标签（如 bug、enhancement、help wanted）来分类任务。对于科研项目，可以设置 experiment 或 data-collection 标签

Basics

  • 标题 (Title)：简洁明了的任务说明
  • 正文 (Description)：支持 Markdown 语法
  • 指派人 (Assignees)：这任务归谁干，在实验室项目里，学可能会把一个任务“指派”给你
  • 标签 (Labels)：给任务分类。常见的有 bug（程序错误）、enhancement（功能增强）、help wanted（求助）
  • 里程碑 (Milestones)：关联到一个具体的时间点。可以把所有相关 Issue 都挂在这个里程碑下

联动 (Linking)

#

GitHub 为每个 Issue 分配了一个唯一的编号（如 #1）

  • 在讨论中提到 #1，它会自动变成一个超链接
  • 在 Commit 信息里写 refactor: improve smpl rendering, fixes #1
  • 当你把代码合并到主分支时，GitHub 会检测到 fixes #1 关键字，并自动帮你关掉（Close）那个 Issue

提及与引用 (@mentions)

就像微信里的 @ 一样，你在 Issue 里 @某个账号，他就会收到通知。所有的讨论都留在了代码仓库里，方便日后回溯

使用场景

一：科研笔记与任务追踪

例如在你的 Research 仓库开一个 Issue：

  • 标题：[Feature] 实现 SMPL-X 模型的批量渲染脚本
  • 正文：列出任务清单（Task List）：
    • [x] 配置环境
    • [ ] 编写核心循环
    • [ ] 导出为 .mp4
  • 作用：学长看到后，不需要问你进度，看一眼 Issue 里的勾选情况就知道了

场景二：博客灵感库

在你的 Blog_Source 仓库里开 Issue：

  • 标题：[Idea] 写一篇关于 UIUC 交换申请的心得
  • 正文：随便写点大纲或想到的关键词
  • 作用：这相当于一个云端待办清单，而且支持版本回溯

Issue 模板 (Issue Templates)

如果点击 “New Issue” 后会弹出几个选项。这就是模板。它强迫你按照固定的格式填信息（比如：你用的 Python 版本、报错截图、复现步骤）。这能极大提高沟通效率

Workflow

  1. Open：发现问题或产生新想法，创建一个 Issue
  2. Discuss：在下方留言、上传截图、@相关人员讨论方案
  3. Link：创建一个分支去解决它，并在提交代码时引用该 Issue 编号
  4. Close：问题解决了，手动或通过代码合并自动关闭

协作：Pull Request (PR)

PR 是“请求对方拉取你的代码”

  • Code Review (代码评审)：在 PR 界面，队友可以在你改动的那一行代码下直接留言讨论
  • Draft PR：如果你还没写完，但想让导师看看思路，可以创建一个 Draft PR，它不会被意外合并
  • Merge 策略：
    • Create a merge commit：保留所有琐碎的提交历史
    • Squash and merge：把你的 10 个琐碎提交压缩成 1 个，保持主线整洁

自动化：GitHub Actions

这是 GitHub 自带的虚拟机（Runner），可以根据触发条件（如 push）自动跑代码

  • Workflow (.yml)：存放在 .github/workflows/ 目录下
  • 应用例子：博客自动化，配置了 Actions，你可以直接在 Obsidian 里写完并推送到 GitHub，GitHub 的服务器会自动帮你运行 hexo g -d，不需要占用你本地电脑的资源
  • 科研应用：每次推送代码时自动运行 pytest 测试你的 SMPL 渲染逻辑是否被改坏了

GitHub 协作全流程

假设你要为一个开源的机器人控制库贡献代码：

  1. Fork 对方的仓库到你的账号
  2. Clone 你的仓库到本地
  3. Checkout 建立一个新的分支（如 feat-fix-ik）
  4. Commit 你的修改
  5. Push 到你自己的远程分支
  6. 在 GitHub 网页点击 Compare & pull request
  7. 原作者 Review 你的代码并提出修改意见
  8. 原作者点击 Merge，你的代码正式进入了原作的 main 分支