Github认为合并后分支不同 [英] Github thinks branches are different after merge

查看:195
本文介绍了Github认为合并后分支不同的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经把这个Github问题撞到了墙上,终于来这里寻求帮助.我的存储库有两个感兴趣的分支:master,它是当前正在发布的分支,而,这正是听起来的样子.我们的开发过程具有功能分支,这些分支定期从alternate-testing分支(并分叉),然后合并回alternate-testing.最后,alternate-testing会定期合并到master中.请注意,测试分支是master的关守-除了进入alternate-testing之外,没有任何内容进入master.

I've banged my head against the wall with this Github issue enough to finally come here for help. My repo has two branches of interest: master, which is the currently live release branch, and alternate-testing, which is exactly what it sounds like. Our dev process has feature branches regularly branched (and forked) off alternate-testing, then merged back into alternate-testing. Finally, alternate-testing is periodically merged into master. Note that the testing branch is the gatekeeper to master - nothing gets into master but by going through alternate-testing.

非常清楚,这不是这样的情况:

To be perfectly clear, this is not a situation like this:

1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 [master]
       \                      /
        A -- B -- C -- D -- E [alternate-testing]

此问题中一样,因为主从不改变.一个更相关的图是:

as in this question, because master never changes by itself. A more relevant diagram is:

1 -- 2 ---------------------- * -- 8 [master]
       \                      /
        A -- B -- C -- D -- E [alternate-testing]

因此,在该图的末尾,masteralternate-testing必须相同.分支后,master没有任何更改,并且alternate-testing中的每个更改都已合并到master中.

So at the end of this diagram, master and alternate-testing have to be identical. There were no changes to master after the branching, and every change in alternate-testing has been merged into master.

但是,GH显示两个分支不同步.我今天早上才做合并,GH对master说:此分支前面3个提交,在备用测试之后29个提交."

Yet, GH shows that the two branches are out of sync. I just did the merge this morning, and GH says about master: "This branch is 3 commits ahead, 29 commits behind alternate-testing."

这怎么可能?我该如何解决这个令人抓狂的问题?

How is this possible, and how can I fix this maddening problem?

推荐答案

感谢评论者帮助我指出正确的方向.我们一直在将PR与Squash + Merge合并,这样做的好处是简化了提交历史记录.

Thank you to the commenters for helping point me in the correct direction with this. We had been merging our PRs with a Squash+Merge, which has the benefit of simplifying the commit history.

Squash通过创建一个新的提交来工作,然后将其合并,但仅 合并到基础分支中.因此,虽然合并后的基本分支中的代码与PR分支的代码相同,但基本分支具有额外的提交.似乎GH应该将南瓜提交放在两个分支上,以保持真实的历史记录.

The Squash works by creating a new commit which then gets merged but only into the base branch. Hence, while the code in the base branch is identical after the merge to that of the PR branch, the base branch has an extra commit. It seems that GH should put the squash commit on both branches to maintain the real history.

我们通过使用普通的香草合并(而非Squash + Merge)解决了这一问题.

We have solved this by using a plain vanilla Merge, rather than the Squash+Merge.

这篇关于Github认为合并后分支不同的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆