我有一个git仓库,有2个分支:master和test。
主分支和测试分支之间存在差异。
两个分支都提交了所有更改。
如果我这样做:
git checkout master
git diff test
屏幕上会出现一个充满变化的屏幕,显示不同之处。我想合并测试分支中的更改,这样做:
git merge test
但是得到的信息是"Already - updated "
但是,检查每个不同分支下的文件可以清楚地显示出差异。
这里的问题是什么,我如何解决它?
我有一个git仓库,有2个分支:master和test。
主分支和测试分支之间存在差异。
两个分支都提交了所有更改。
如果我这样做:
git checkout master
git diff test
屏幕上会出现一个充满变化的屏幕,显示不同之处。我想合并测试分支中的更改,这样做:
git merge test
但是得到的信息是"Already - updated "
但是,检查每个不同分支下的文件可以清楚地显示出差异。
这里的问题是什么,我如何解决它?
当前回答
如果将分支A合并到分支B报告“Already up to date”,则反过来并不总是正确的。只有当分支B是分支A的后代时才成立,否则 分支B可以有A中没有的变更。
例子:
在master上创建分支A和B 您在master中做了一些更改,并只将这些更改合并到分支B中(不更新或忘记更新分支A)。 你在分支A中做了一些改变,并将A合并到B。
在这一点上,合并A到B报告“已经更新”,但分支是不同的,因为分支B有来自主的更新,而分支A没有。
其他回答
“已经是最新的”消息意味着您试图合并的分支的所有更改都已经合并到您当前所在的分支。更具体地说,它意味着您试图合并的分支是当前分支的父分支。恭喜你,这是你做过的最简单的合并。:)
使用gitk查看您的存储库。“test”分支的标签应该在“master”分支标签的下方。
您的分支相对于其父分支是最新的。根据合并,自上次合并以来父节点中没有新的变化。这并不意味着分支是相同的,因为您可以在工作分支中进行大量更改,而且听起来确实如此。
编辑10/12/2019:
根据Charles Drake对这个答案的评论,解决这个问题的一个解决方案是:
git checkout master
git reset --hard test
这又回到了“测试”层面。
然后做:
git push --force origin master
为了迫使中央回购的变化。
这很傻,但可能会发生。假设你的分支名称前缀是一个问题引用(例如#91-fix-html-markup),如果你这样合并:
$ git merge #91-fix-html-markup
它不会像预期的那样工作,因为#之后的所有内容都被忽略,因为#开始一个内联注释。
在这种情况下,你可以重命名分支,省略#或使用单引号环绕分支名称:git merge '#91-fix-html-markup'。
这可能看起来微不足道,但我见过许多人忽略它,只是在父分支上进行git合并。这将自动导致“已经更新”的消息。
合并命令应该是git merge branchNametoMergeFrom
例如,假设你有2个分支branchA和branchB,你需要将B合并为a,你需要首先签出到branchA,然后使用merge命令,同时指定要合并的分支(在这种情况下是branchB)。
因此,命令不应该只是git merge,而应该是git merge branchB。
我在当前分支中提交了更改,然后来自Origin分支的合并工作正常。
合并总是在当前HEAD和一个或多个提交之间(通常是分支头或标签), 索引文件必须匹配HEAD提交的树(即上次提交的内容)。 换句话说,git diff——cached HEAD必须报告没有变化。 合并后的提交已经包含在HEAD中。这是最简单的情况,称为“Already - updated”。
这应该意味着测试中的提交已经合并到master中,但由于其他提交是在master上完成的,git diff test仍然会给出一些差异。