GitHub 开发流程学习笔记

1. 使用场景

这套流程适合我现在这种工作方式：

本地 Windows 电脑负责写代码、改脚本、整理说明文档
远程 Linux / HPC 服务器负责跑分析任务和存放大结果文件
GitHub 负责保存代码历史、同步修改、做协作提交

换句话说，我要解决的不是"怎么装 Git"，而是下面这个实际问题：

我需要在本地稳定地管理代码，并把修改提交到 GitHub；远程服务器继续负责计算，不负责主要的版本管理。

2. 为什么要做这套流程

做这套流程，主要是因为当前的工作方式如果没有 GitHub 闭环，会有几个明显问题：

修改历史不清楚，不容易知道哪次改动引入了什么变化
文件容易靠手工复制来回传，容易乱，也不方便回滚
远程服务器如果同时承担"算任务"和"管代码"两种角色，会越来越混乱
后续如果要协作、提交 PR、回看旧版本，会很吃力

另外，当前这个目录本身还是一个仓库快照，不是真正的 Git 工作树，因为没有 .git 目录。这意味着它能改文件，但不能正常完成 commit 和 push。

所以，这套流程的根本目的就是：

把代码管理、本地开发、远程同步、远程计算这几件事分工清楚，并形成固定闭环。

3. 这套流程是什么

这套流程本质上是一条标准的 GitHub 开发闭环：

clone 真仓库 -> 新建分支 -> 修改文件 -> commit -> push -> PR

它背后的分工是：

Git 管本地版本历史
GitHub 管远程仓库和协作流程
远程服务器 管计算任务和大文件结果

所以，这套流程不是"装几个工具"，而是建立一个清晰的工作模型：

本地是开发入口
GitHub 是同步与协作入口
远程服务器是计算入口

4. 要做成这套流程，需要配置什么

要让这条流程真正跑起来，需要配置 5 类东西。

4.1 `git`

作用：

在本地记录代码版本
支持 clone、status、add、commit、push

没有 git，就没有本地版本管理。

4.2 `user.name` 和 `user.email`

作用：

标记每次提交是谁做的

没有这两个配置，git commit 会报 Author identity unknown。

4.3 `GitHub CLI (gh)`

作用：

登录 GitHub
辅助克隆 GitHub 仓库
创建 Pull Request

它不是 Git 的替代品，而是 GitHub 相关操作的辅助工具。

4.4 `Git Credential Manager`

作用：

让 git push、git pull 这类 HTTPS 操作更稳定
避免每次都反复输入 GitHub 凭据

它主要服务的是 git 的网络认证，不是拿来替代 gh 的。

4.5 一个真正的 Git 仓库

作用：

这一点非常关键。

没有 .git 的目录，只是普通文件夹，不是 Git 工作树。

5. 这些配置之间是什么关系

这几个配置不是并列堆在一起的，它们是串起来工作的。

关系可以理解成下面这条链：

真实仓库(.git) -> git 管本地版本 -> user.name/email 标记提交身份 -> Git Credential Manager 负责 git 的 HTTPS 认证 -> gh 负责 GitHub 级别的登录/PR 操作

具体来说：

clone 下来一个真实仓库后，目录里才会有 .git
有了 .git，git status / commit / push 才有意义
git commit 需要 user.name 和 user.email
git push 到 GitHub 时，通常要靠 Git Credential Manager 处理认证
gh 则负责 GitHub 平台层面的动作，比如 gh auth login 和 gh pr create

还有一个容易混淆的点：

SSH 连接远程服务器，解决的是"怎么上远程机跑任务"
GitHub 同步仓库，解决的是"怎么管理代码版本并提交到远程仓库"

这两件事相关，但不是同一件事。

6. 这套流程应该怎么做

操作顺序应该固定下来，不要每次都临时想。

第一步：先完成本地初始化

运行：

powershell 复制代码

powershell -ExecutionPolicy Bypass -File .\Scripts\setup_github_workflow.ps1 `
    -GitUserName "你的名字" `
    -GitUserEmail "你的GitHub邮箱" `
    -LoginWithGh

这一步的目标是：

确认 git 和 gh 可用
配置 Git 身份
配置 Git 默认项
登录 GitHub

第二步：克隆真实仓库

不要继续在当前快照目录里开发，要重新 clone。

powershell 复制代码

powershell -ExecutionPolicy Bypass -File .\Scripts\setup_github_workflow.ps1 `
    -RepoUrl "https://github.com/<owner>/<repo>.git" `
    -CloneParent "D:\github_proj" `
    -CloneRepo

第三步：进入真实仓库后开始开发

标准动作顺序：

powershell 复制代码

git switch -c feat/<short-topic>
git status
git add -A
git commit -m "Add <short summary>"
git push

如果第一次没有自动绑定上游分支，再执行：

powershell 复制代码

git push -u origin feat/<short-topic>

创建 PR：

powershell 复制代码

gh pr create --fill

第四步：远程服务器继续只做计算

推荐的分工是：

本地维护脚本和文档
GitHub 保存版本历史
远程服务器跑 R、shell、生信流程和大数据任务

这能避免"代码散在远程机里、改完又忘了同步"的问题。

7. 这次实际是怎么做的

这次已经完成了这些事情：

确认本机已有 git、OpenSSH、codex
安装了 GitHub CLI
配置了 Git Credential Manager
写入了几个 Git 默认项
新增了初始化脚本 setup_github_workflow.ps1
新增了流程说明 GITHUB_DEV_WORKFLOW.md

已经写入的 Git 默认项包括：

init.defaultBranch = main
fetch.prune = true
push.autoSetupRemote = true

这几项分别用于：

统一默认主分支名
清理失效远程分支引用
减少第一次推送新分支时的手工操作

8. 现在还差什么

还差你自己的账号信息这一步：

设置 GitUserName
设置 GitUserEmail
完成 gh auth login
从 GitHub clone 一份真实仓库

也就是说，这套流程的基础设施已经搭好了，但真正进入"能提交、能推送"的状态，还差你自己的账号认证和真实仓库克隆这一步。

9. 最后用一句话总结

这套 GitHub 流程的核心，不是学会几个命令，而是建立一条分工清楚的工作闭环：

本地开发 -> Git 管版本 -> GitHub 做同步和协作 -> 远程服务器做计算

GitHub 开发流程学习笔记

1. 使用场景

2. 为什么要做这套流程

3. 这套流程是什么

4. 要做成这套流程，需要配置什么

4.1 git

4.2 user.name 和 user.email

4.3 GitHub CLI (gh)

4.4 Git Credential Manager

4.5 一个真正的 Git 仓库

5. 这些配置之间是什么关系

6. 这套流程应该怎么做

第一步：先完成本地初始化

第二步：克隆真实仓库

第三步：进入真实仓库后开始开发

第四步：远程服务器继续只做计算

7. 这次实际是怎么做的

8. 现在还差什么

9. 最后用一句话总结

4.1 `git`

4.2 `user.name` 和 `user.email`

4.3 `GitHub CLI (gh)`

4.4 `Git Credential Manager`