我已经在本地重新设置了一个已经推送的分支。
Git 建议我的分支和远程已经分歧,并且:
“并且分别有 109 和 73 个不同的提交”
推动我的分支会解决这个问题 - 即,这是在变基后预期的吗?
我已经在本地重新设置了一个已经推送的分支。
Git 建议我的分支和远程已经分歧,并且:
“并且分别有 109 和 73 个不同的提交”
推动我的分支会解决这个问题 - 即,这是在变基后预期的吗?
当你变基一个分支时,你必须重写任何高于你要变基的分支中的提交的提交。这是因为提交的属性之一是它的父级(或父级)。当您变基时,您正在更改分支上最旧的本地提交的父级 - 从而更改所有本地提交的提交哈希,因为此更改通过提交传递。
由于您已经推送了分支,因此您应该合并到源分支中,而不是针对它进行变基。可以“强制推送”您的新分支(使用-f
标志),但正常推送将不起作用,因为分支历史的完整性会受到干扰。如果你在这个分支上与其他人合作,强制推送是个坏主意,因为当他们的历史突然不匹配时,它会导致其他合作者变得非常困惑。
TL;DR - 如果您不合作,请使用 push -f 推送分支。如果是,请将分支重置为以前的状态,然后合并到源分支中。
你所有的提交都改变了 id,所以转移并不是真正的分歧。
要解决您的问题,您必须覆盖您的远程分支:
git push -f origin experiment
http://git-scm.com/book/ch3-6.html
解释:
看看在这张图片中,C3 是如何在变基之后不作为 C3 放置的,而是作为 C3'。这是因为它不完全是 C3,但它具有所有代码更改。
在另一张图片上,您可以看到当涉及远程时看到的变基,以及为什么会有转移。
无论如何,在您进行强制推送之后,它会告诉您它进行了(强制更新),此时您应该没问题。
查看顶部的链接,然后搜索“git push --force”。您将看到更详细的说明。
通过执行以下操作,我在 rebase 分歧方面取得了成功:
git checkout mybranch
git pull
git push origin mybranch
拉动解决了分歧。
拉之前
Your branch and 'origin/mybranch' have diverged, and have 2 and 1 different commit(s) each, respectively.
拉出输出
通过递归进行合并。我的路径/myfile.py | 12 +++++++++++- 1 个文件更改,11 个插入 (+),1 个删除 (-)
拉后
您的分支领先于 'origin/mybranch' 3 次提交。
推后
mybranch 在分支之前 3 仍然有一个打开的拉取请求合并消息添加到提交历史记录中将远程分支 mybranch 合并到 mybranch
我假设这可能是力推的作用,但我尚未验证。
正如其他人所说,如果您已经有一个开放的拉取请求,请避免变基。我提供这个例子作为对我有用的东西。
通过将目标分支重新定位到当前本地分支,切换到目标分支,然后将本地分支重新定位到目标,可以在不强制推送的情况下解决此问题。这不会产生分歧,因为可能缺少的提交已添加并且不再需要创建。更容易解释的例子:
如果你还没有更新你的开发分支,那么“git checkout develop”&&“git rebase feature/doing_stuff”将正常工作,因为自你结帐以来没有添加任何提交。但是,如果您已签出 develop 并取消了新提交,那么如果您由于看到新提交而尝试 rebase,您将看到这种差异。无需强制(在团队环境中通常不是一个好主意)的简单解决方法是:
第 2 步中的变基将丢失的提交带入 feature/doing_stuff,因此当第 4 步出现时,它是最新的,不需要为更改创建新提交。
这是一个我知道可行的解决方案,因为我刚刚遇到了这个问题并执行了上述步骤以成功推动开发而无需强制。我在一个由 50 多名开发人员组成的团队中工作,因此禁止强制推送除我自己的测试分支以外的任何内容,因此我必须找到解决方案。