QX 的笔记
0%

github提交pull request流程和commit重复解决办法

发表于 更新于 分类于
本文字数： 1.4k 阅读时长 ≈ 5 分钟

给Github上的开源项目贡献代码，就少不了 pull request 也会简称为 PR 或者 MR

为啥我不能直接给开源项目提交代码，非要通过 PR 贡献呢。
主要有两个方面吧

  1. 开源项目的作者要甄别提交的代码的质量，不能什么烂代码都可以提交到这个项目里，只有作者觉得合适的代码才可以加到项目里
  2. 防止别人搞破坏，要是谁都能随便提交代码，万一你给我来个删库跑路，作者想问候他全家

基于这两个方面的考虑吧，gitbub只能修改自己的项目的代码，然后向原项目提交 PR， 原项目作者可以选择性的合并到项目中。

所以，Github贡献代码基本流程如下：

fork

这个没什么好说的，找到你想要贡献代码的项目，然后点右上角的 fork 就好了

然后回到自己的 repositories 中就能看到刚才fork 的项目了，其实fork就是复制了当前项目的镜像，这个复制后的镜像就是你自己的了，你拥有最高的权限。

pull

pull 就是把fork 后的项目拉到本地，然后修改代码。这个没啥说的，就是常规操作。

commit

commit 也没啥，和正常的提交代码一样，写好提交信息就好了。

push

push 就是把这次的commit提交到自己的github上去。注意，这次push是push到自己fork后的仓库中，别搞混了。

pull request

现在就到最重要的一步了，创建 pull request了。
到自己的github中，能看到自己刚才的commit了，这时候github 就会提示我们去创建pull request了

或者按照下图中的顺序，一样可以到创建 PR的页面

通过下图标注的地方，选择要Merge的分支，一般默认都是正确的。

因为我已经把这个PR提交了，所以显示的是 View pull request，正常的显示的是 create pull request
然后根据提示创建这个PR就好了。

到这里，一次完整的PR流程基本就完成了，剩下的就等着原项目作者Merge就行了。

但是事情没有结束

如果原项目作者同意合并了，提交的代码就会合并到主项目中，或者有别人也提交PR了，这是你想再次提交PR的话，就要先同步仓库了，就是把自己fork的仓库和源项目的仓库保持同步。
如果直接在github上点 sync fork，github会自动帮你Merge两个仓库，也就是会把之前你的commit信息一起Merge过来，
当你下次再要提交PR的时候，就会出现之前的commit信息。因为在 sync fork 的时候是Merge的，所以会带上之前的提交信息。

先说已经sync fork后，在创建 PR时才发现的解决办法：

回到自己电脑上

把本地的代码回退到重复之前的那个版本
通过 git log 找到重复前的那个版本。
然后回退到那个版本

1
git reset 对应版本的id

这时候本地修改的代码就会回到未提交的状态，这时候先把改的代码复制一份出来，避免操作失误找不到了就尴尬了。
再通过

1
git checkout .

把放弃本地修改。

然后重点来了，给项目加一个上游地址。
先看一下当前的分支

1
2
3
4
git remote -v

origin    git@github.com:lqxhub/pika.git (fetch)
origin    git@github.com:lqxhub/pika.git (push)

此时只有自己fork后的仓库。
现在要给fork后的仓库，加一个上游地址，也就是指定这个仓库是从哪里fork来的

1
git remote add upstream https://github.com/OpenAtomFoundation/pika.git

upstream 后面跟上源仓库地址
现在来看看分支器情况

1
2
3
4
5
6
git remote -v
origin    git@github.com:lqxhub/pika.git (fetch)
origin    git@github.com:lqxhub/pika.git (push)

upstream    https://github.com/OpenAtomFoundation/pika.git (fetch)
upstream    https://github.com/OpenAtomFoundation/pika.git (push)

到这上游仓库已经加好了

然后执行

1
git fetch upstream

同步上游仓库到本地

等代码同步完成

1
git branch -a

看一下当前的分支情况

1
2
3
4
5
6
7
8
9
10
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/upstream/2.3
  remotes/upstream/3.0
  remotes/upstream/3.0.16
  remotes/upstream/3.2.9_beta_rocksdb5.18.3
  remotes/upstream/develop
  remotes/upstream/master
  remotes/upstream/pika_codis

这时候就能看到很多分支了，然后把自己本地的代码rebase到想要的分支，一般就是remote/upstream/master

执行

1
git rebase remotes/upstream/master

到这，本地的代码就已经和原仓库保持同步了。注意一定是 bebase 不要 merge

核心思想就是让本地代码落后于上游仓库，然后再把本地的rebase到最新的

然后就正常的修改代码 commit push

注意 这里push的时候要强制 push git push -f 要不然会失败

最后去github上 提交 PR就好了。

上面说的是出错了怎么补救，再说一下应该怎么正确操作

正确的操作

正确的操作是，每次修改代码都新建一个分支，在分支上修改代码，这样就不会带上之前的信息了。

或者一开始就在本地加上上游仓库地址，每次都是git fetch upstream 然后基于remote/upstream/master分支，在本地新建一个分支(假设新分支是 newDev)开始开发。

1
git checkout -b newDev remote/upstream/master

新版本的git可以用

1
git switch -c newDev remote/upstream/master

好了，问题解决了，又可以愉快的参与开源项目了。