一个pull-request其实是一个分支，而不是一个提交，所以一个pull-request里可以容纳多个提交，pull-request的提交过程原理很像（应该就是）rebase一个分支，然后将这个分支合入目标分支。

下面是我修改代码并且向openGauss/openGauss-server代码仓库提交pull-request的工作模型，参考了fork+pull request模式：Fork + PullRequest 模式 - Gitee.com

1、fork自己的仓库

例如，希望向master分支提交pull-request，即我的修改是基于master分支。

先从openGauss/openGauss-server仓库fork出一个我自己仓库，qinh/ openGauss-server包含了源仓库的所有分支，也可以同步源仓库的修改。

2、创建工作分支

然后基于qinh/openGauss-server的master分支创建一个工作分支，例如，名为my-feature：

我的修改、实验就在这个工作分支上进行，之所以不在master分支上进行，是想保留一个干净的master作为对比和更新用。按照我的想法，工作分支的修改如果成功合入，就应该删除工作分支，再要合入其它修改，则再创建新的工作分支，而master分支是一直保留的。

创建分支时，分支起点可以是qinh/openGauss-server，也可以是openGauss/opengGauss-server，我觉得两者都是一样的。

然后，下载仓库：

git clone git@gitee.com:hwrd/openGauss-server.git

本地创建跟踪分支：

git branch my-feature --track origin/my-feature

在本地电脑上基于这个分支修改、编译、测试，提交，代码稳定后push到qinh/openGauss-server的my-feature分支：

git push origin my-feature

3、创建pull-request

在qinh/openGauss-server仓库页面中，点 “+Pull Request” 创建pull-request，注意不是在openGauss/openGauss-server公共仓库的页面点“+Pull Request”。

然后就打开下面的页面，源分支选我的仓库的my-feature，目标分支选opengauss的master分支，表示请求将我的仓库的my-feature分支的修改合入opengauss公共仓库的master分支，这个过程有点像rebase。

这样就创建了一个pull-request，之后经过评审，如果需要修改，都要上传到我的仓库的my-feature分支，之后会显示在这个pull-request的“提交”中。

也就是说，只要向这个分支push的提交，都是属于这个pull-request的，即pull-request是和一个分支绑定的。

后面如果这个这个分支需要更新，或者与目标分支有冲突，操作方式和原理，跟rebase是一样的。