如果你是项目的负责人，在后期项目维护中，同样不建议直接使用本地 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 次，然后再合并到主分支，一般与协助者协同维护项目的时候，应该选择第二项。

当我们确认之后，就完成了一次自己面对项目的迭代推进流程。