GitHub开源项目维护协作指南。

如果你是项目的负责人，在后期项目维护中，同样不建议直接使用本地 push 的方式进行，尽管我们有这个项目的全部权限，也可能会因为某次失手，导致将不符合预期的内容提交。这里建议走 pr 的方式进行维护，便于在 merge 的时候二次核验一下代码差异。 接下来是一个维护的常规流程。 拉取代码到本地： $ git clone git@github.com:eryajf/learn-github.git $ cd learn-github $ cat README.md # learn-github 学习GitHub相关交互以及功能 此时项目所在分支为默认的 main 分支，我们从最新代码切到一个测试分支。 $ git checkout -b test # 模拟如下修改 $ echo '模拟修改提交' >> README.md 然后将 test 分支提交到远程。 $ git add . $ git commit -m 'test' $ git push --set-upstream origin test 然后我们来到 GitHub 项目页，可以看到 test 分支 可以看到页面已经提示 test 分支，并有一个提交 PR 的按钮，我们来创建这个 PR。 通常点击 1 的 tab 进行交互，2 号可以选择当前项目的不同分支，我们这里选择刚刚的 test 分支。 编号 3 表示可以选择其他远程仓库进行合并，通常是与一个 fork 后的仓库进行交互。编号 4 可以清晰看到当前这次合并与源分支的差异。 点击创建 PR。 通常我们应该在这一步写明一个标题，以及当次将要合并的内容纲要。 此时视角切回到项目主维护者，可以通过编号 1 和编号 2 来核对提交的次数以及差异内容，这里因为是从本地推送，所以通常直接二次 check 即可，如果是处理别人的 PR，则应该将代码拉到本地进行一些功能测验。 编号 3 表示将这次 PR 进行合并，所有的提交都会合并到 main 分支中，如果该次 PR 有多次 commit，主分支也会呈现多次 commit 的历史。 编号 4 表示将多次 commit 压缩成 1 次，然后再合并到主分支，一般与协助者协同维护项目的时候，应该选择第二项。 当我们确认之后，就完成了一次自己面对项目的迭代推进流程。