【发布时间】:2013-09-25 23:10:21
【问题描述】:
我已经在本地重新设置了一个已推送的分支。
Git 建议我的分支和远程分支已经分道扬镳,并且:
“分别有 109 和 73 个不同的提交”
推送我的分支会解决这个问题吗?也就是说,在 rebase 之后会出现这种情况吗?
【问题讨论】:
-
我也有同样的问题。我们可以说“正确的做法”是 rebase 本地分支然后再推送吗?
标签: git
我已经在本地重新设置了一个已推送的分支。
Git 建议我的分支和远程分支已经分道扬镳,并且:
“分别有 109 和 73 个不同的提交”
推送我的分支会解决这个问题吗?也就是说,在 rebase 之后会出现这种情况吗?
【问题讨论】:
标签: git
当你变基一个分支时,你必须重写任何高于你变基的分支中的提交的提交。这是因为提交的属性之一是它的父级(或父级)。当您变基时,您正在更改分支上最旧的本地提交的父级 - 从而更改所有本地提交的提交哈希,因为此更改通过提交传递。
既然你已经推送了分支,你应该在源分支中合并,而不是针对它进行变基。可以“强制推送”您的新分支(使用-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”将正常工作,因为自您结帐以来没有添加任何提交。但是,如果您已签出开发并取消了新提交,那么如果您由于看到新提交而尝试重新设置基准,您将看到这种差异。无需强制(在团队环境中通常不是一个好主意)的简单解决方法是:
第 2 步中的变基将丢失的提交带入功能/doing_stuff,因此当第 4 步出现时,它是最新的,不需要为更改创建新提交。
我知道这是一个可行的解决方案,因为我刚刚遇到了这个问题并执行了上述步骤以成功推动开发而无需强制。我在一个由 50 多名开发人员组成的团队中工作,因此禁止强制推送除我自己的测试分支以外的任何内容,因此我必须找到解决方案。
【讨论】: