前段时间复习了 一些 Git 常用命令，目的是希望自己即使是一个人维护项目也可以更科学、更标准化一点，经过一段时间的实践，我个人开发的 GitHub 简易工作流基本成形。

这套工作流不适合所有人，PR 流程的引入增加了流程的复杂度。

初始化项目

先本地新建项目，需要同步 GitHub 时再创建远程仓库然后关联：

git remote add origin [email protected]:username/repository_name.git

首次 push main 分支时需要使用 -u 参数指定远程分支：

git push -u origin main

之后 main 分支的 push 一律使用：

git push origin main
# 或者
git push

在配合 AI 编程的时候，有意识的多次 add，当项目内容有一个逻辑上最小完整功能时再 commit 一次，并且使用简短明了有意义的 commit 描述。

分支管理

一般只用到 main 分支和 dev 分支，在本地新建 dev 分支：

git switch -c dev

然后进行新的开发，当需要将 dev 上的开发成果合并到 main 分支时，再 push dev 分支到 GitHub：

git push -u origin dev

在 GitHub 上通过 PR（Pull Request）进行分支合并，以便进行代码审查，使用「Squash and merge」方式完成合并。这种方式会将 dev 分支上本次 PR 的所有 commit 记录压缩为一条新的 commit 合并到 main 分支上。

最终效果是 main 分支上会新增一条对应这次合并的 commit 记录，dev 分支上的 commit 记录则保持原样（同本地一致）。

此时本地 main 分支落后于远程 main 分支一个 commit，需要在本地 main 分支上拉取最新的远程 main 分支：

git switch main
git pull origin main

再继续进行其他新的开发时，切换到 dev 分支并将 dev 分支变基到最新的 main 分支上。

git switch dev
git rebase main

当新的开发成果需要被合并到 main 分支时，再次 push 本地 dev 分支到远程 dev 分支，此时由于本地 dev 分支是基于上一次合并后产生的新的 commit 开始的，与上一次合并后的远程 dev 分支不一致，所以本次 push 可能需要强制覆盖远程 dev 分支：

git push --force-with-lease origin dev

在 GitHub 上通过 PR 进行分支合并。完整流程就是这样，后续以此循环即可。

如果不想使用 PR 则完全可以在本地完成分支合并，只 push main 分支到远程仓库。