这是一个创建于 440 天前的主题，其中的信息可能已经有所发展或是发生改变。
过程： 比如说现在有 dev 分支和 master 分支， dev 分支的提交历史：1 ，2 ，3 三个记录 master 分支的提交历史：1 ，2 现在生成一个 pull request ，把 3 的记录 merge 合并到 master 上， 所以现在 master 分支的记录是：1 ，2 ，3 ，Merge pull request ... 现在分支 dev 上有一个新的提交历史，现在 dev 的记录是：1 ，2 ，3 ，4 现在生成一个新的 pull request ，把 4 的记录合并到 master 上， 所以现在 master 的记录是：1 ，2 ，3 ，Merge pull request 1...，4 ，Merge pull request 2...
以上操作在 github 上没有问题的， 但是在 gitlab 上却有问题，第二次 merge request 的时候会有一个提醒，the source branch is 1 commit behind the target branch,
请问一下这个提醒是需要提交记录 4 到 dev 分支的时候需要先把 master 的 Merge pull request 1... 这个记录 rebase 或者 merge 到 dev 分支上么，然后后面再次提交记录 4 么，但是这样的话为什么 github 可以不用呢。
 |
1
FaiChou 2023-08-26 12:53:24 +08:00
没有弄懂你描述的问题。
你自己的项目的话，本地两个分支，整理干净后直接 push 到 github 即可，要保持本地和远端的分支记录一样。 但你又提到 pull request ，这个前提是 fork&clone 了别人的项目，然后自己改动过后给原项目提 pr 。 后面你提到 Merge pull request ，从这个描述来看，你是原仓库 owner ，在处理别人给你提的 pr ？ 最后“the source branch is 1 commit behind the target branch”，这情况就是俩分支不同步，提交前先 `git pull --rebase origin master` 一下。 所以不知道你用的什么工具操作的，最好将你执行的命令/谁的项目讲清楚一些。 |
 |
2
crysislinux 2023-08-26 12:59:42 +08:00 via Android
我也没搞懂这个描述。不过我建议只要 master branch ，开发直接向 master 提 pull request 。 发版的时候就直接建一个新的发布分支
|
 |
3
Helsing 2023-08-26 13:07:54 +08:00 via iPhone
肯定要先把 master 合入 dev ，再把 dev 合入 master 啊
有冲突的话，你不处理就可以合入 master ，那不就出问题了吗，别人写的代码就被你搞没了…… |
 |
4
hsfzxjy 2023-08-26 13:12:36 +08:00
github 也会提示 This branch is 1 commit behind ，不清楚你有没有例子展示你描述的现象
不过一般来说，PR 合并完原分支都是要删掉的。下次交 PR 直接从 official/master 重新拉一个分支 |
 |
5
otakustay 2023-08-26 13:14:52 +08:00
只是个提示，硬要合也是能合的，那个 merge commit 本身就不影响合并效果
真要做的话，应该 dev 上先 git fetch --all 再 git rebase origin/master 一下 |
 |
6
18870715400 OP @FaiChou ，额， 我的意思是在 github 上生成一个 pull request ，把 dev 的提交合并到 master 分支上，master 分支会生成两次的记录，一次是 dev 的提交记录， 另一个是 [Merge pull request #2 from xxx] 的记录，但是下次 dev 分支再次把新的提交记录合并到 master 分支上的时候，不需要把 [Merge pull request #2 from xxx] 这个记录拉到 dev 分支上
|
|
7
18870715400 OP @otakustay gitlab 上是需要这个，会有一个提醒， 但是 github 上却没有这个提醒
|
 |
8
hello2090 2023-08-26 13:47:47 +08:00 via iPhone
你为啥要在原来的 branch 上做 4 ，不是应该重开一个 branch 吗，或者你在原 branch 上做 4 ，rebase master 这样会相当于在 master 最新上拉了一个 branch 出来，只有一个 4 ？这样的话也可以。
但你既然 123 都到 master 上了，你道理上还是要从 master 最新重拉一个出来的 |
 |
9
klo424 2023-08-26 13:53:25 +08:00
以下是我总结的 GitLab 合并步骤，跟 GitHub 确实不太一样，不知道是不是社区版的原因导致的，反正我都是 rebase 而不是 merge 来合并的，就不会出现你说的问题了。
1. 先检查 gitlab 页面上的 review 是否都已解决，未解决的不能合并。 2. 解决 review 后，点击 rebase 变基，变基成功后可直接合并，不成功就需要手动变基。 3. 切到命令行，输入命令 git checkout dev ，切换到 dev 分支。 4. git pull 拉取当前分支代码及其他新分支。 5. git checkout feature-xxx-xxxxxx ，切换到要变基的分支。 6. git rebase dev ，变基到 dev 分支。 7. 变基后会有冲突需要解决，选用合适的代码解决冲突。 8. 解决冲突后，git add .，暂存代码。 9. git rebase --continue ，继续变基，如果没有出现 Successfully 的字样，说明没有成功，需要继续循环执行 7-9 步骤。 10. 变基成功后，git pull feature-xxx-xxxxxx ，拉取一下线上的代码，此时有可能还有冲突，如果没有冲突了则往下走 11 步。如果还有冲突，则再解决一遍冲突，git add .，git commit -m "解决冲突"。 11. git push feature-xxx-xxxxxx ，推送代码。 12. 切到 gitlab 页面，点击 merge 合并即可。 |
 |
10
v2eb 2023-08-26 18:25:59 +08:00  1
每开发一个新功能，就会新起一个 git 分支，只做这一件事。
开发过程中，随意 commit push ，只要在这个新的分支上就行。 开发完成，测试没问题了，切回 master 分支，拉取 master 的最新代码。 切回开发分支，git rebase -i master 。 从第二个 pick 开始，把所有 pick 都改成 s ，比如一共有 15 个 commit ，1 到 15 行都是 pick 大头的，在 vim 里，按冒号，然后输入「 2,15s/pick/s/g 」，把第 2 个到第 15 个 pick 都改成 s ，这样你的改动就被压缩成了一个 commit 。 然后继续 rebase ，如果有冲突，那就解决冲突，自己判断哪段代码要还是不要。 解决完后，会让你编辑一下 comment ，直接写这次改动的 comment 就行。 然后再在 gitlab 上往 master merge ，让别人 review 代码。 来源 b 乎 |
Select Language