提Pr教程

原创已于 2025-07-07 18:00:30 修改 · 836 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#git #gitlab #github

于 2024-05-13 10:02:01 首次发布

Git 专栏收录该内容

5 篇文章

订阅专栏

提Pr教程

如果是提一个新PR

以提交到GitLab的kwin为例

打开kwin的仓库地址：invent.kde.org/plasma/kwin，注册自己的账号。
fork一份仓库到自己名下
将fork的仓库克隆到本地，在其上从主分支签出一个自己的开发分支（如feat-logging-add-pid-clientname），并在该分支上做出修改并commit
- 需要本地先新建一个开发分支，并将这个开发分支关联上 master
- 提交时注意提交规范：https://invent.kde.org/plasma/kwin/-/blob/master/CONTRIBUTING.md
  - commit信息的第一行和PR的标题都是 模块名: 一行内的修改摘要
- commit时先修改user.name为“名姓”
- 每个commit信息的结尾都要带上 Signed-off-by: gitlab账号 <gitlab账号绑定的邮箱> ，这个可以自己手写，也可以用命令 git commit -s/git commit --amend --signoff （这步主要是为了通过CLA和DCO检查）

要包含first name和last name，参考：https://www.reddit.com/r/kde/comments/o8y66l/remote_rejected_error_when_pushing_a_commit_to/

push到自己fork的repo的远程分支（最好先pull一下）
```
git push origin <本地分支名>:<远程分支名>
```
此时终端会提示发pr的链接，gitlab自己repo的网页也会有发pr的按钮。
去GitLab发merge request
去GitLab发issue，issue中要提及merge request。提及的方式是用 [!PR编号](PR链接) 的语法

如果是修改一个PR

如果是上游的人让你修改一下代码，那还好办，直接本地repo对应分支修改后push上去就行了。

但如果是上游打算合你的PR，结果时间隔太久了中间有很多提交了，而你的PR又和当前的HEAD有冲突，此时就比较难办。

核心：fork的仓库要保证main/master不修改，始终保持和上游一致。

一个理想的做法是：一开始就是在fork的repo的自建分支a做的修改，那么同步上游就非常简单，直接gitlab点击sync按钮即可，而自己新建的分支由于上游没有，所以不会受影响。此后只需要再签出一个分支b，将a分支做的修改cherry-pick到b上即可。

补充：有的开源社区会要求你将你这给PR相关的所有提交都git rebase -i合并成一个大提交。此前在公司由于gerrit的问题好像也这么干过，但我不喜欢这样，这样是把可以独立运行的版本拆分了，只是方便了review，不能体现出修改的过程，以后出bug了也不好二分。

如果一开始没有自建分支，而是直接在自己repo的main/master分支修改的，此时可以先基于main/master签出一个a分支，然后丢弃main/master的自己的修改，此时就可以sync上游的了，然后再基于同步后的main/master签出分支b，再cherry-pick刚才a分支的提交到b上，再把a分支删掉，这样就和理想做法一样了。但是这样会导致此前的PR不可用（因为分支已经对应不上了）

其他

如果是提交到freedesktop的项目，还需要激活一下账号的fork权限，否则无法fork仓库。参照wiki：https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home

关于自己fork的repo跑CI必然失败的问题，参考：https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/540，大概就是说freedesktop的CI机器被人恶意用来挖矿了，所以现在只有有CI-OK权限的用户可以跑CI。我这种路过式贡献者（drive-by contributor）就直接提到仓库交给官方帮我跑就行了。