我有一个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
为了迫使中央回购的变化。
使用Git Bash面对这个场景。
我们的存储库有多个分支,每个分支都有不同的提交周期,合并偶尔会发生一次。 Old_Branch被用作New_Branch的父类
Old_Branch更新了一些更改,需要与New_Branch合并
正在使用下面的拉命令,没有任何分支,从所有分支获得所有来源。
Git拉源
奇怪的是,这并没有从所有分支中拉出所有的提交。曾经认为它正如所示显示几乎所有的分支和标签。
所以要解决这个问题,已经检查出Old_Branch拉了最新的使用
git checkout Old_Branch git拉原点Old_Branch
现在查看New_Branch
git checkout New_Branch
拉了一下,确认一下
git拉原点New_Branch git合并Old_Branch
viola得到了从Old_Branch到New_Branch的冲突来修复:),这是预期的
我有一种重新合并它的方法,我的场景是我需要合并一个发布分支。
条件:发布分支代码是金的。意思是master是不正确的而release分支是正确的。
现象:将发布版本合并到主版本时,主版本中不正确的部件没有与发布版本中的部件一起更新。
以下是步骤,免责声明:我对git的了解有限,一定有更好的方法来实现它。
checkout release branch, do a pull. [Commit #A] merge latest master to release [Commit #B] (incorrect file will write to release branch) do a reverse commit of the [Commit #B] BUT keep it in stage (if the reserve commit is committed as [Commit #C] then do a soft reset to Commit #B) (this essentially reverse the incorrect files) edit the files, check whether these are correct, discard the unwanted ones (if there is any) stash the changes in step 4 [Stash{X}] reset release back to Commit #A (same as remote) merge latest master to release again [Commit #D] (diff hash should be the same but commit hash is different than b) Apply stash {x} Commit and merge to master.
编辑:第9步可以发生在本地,只是看看预期的部分是否已应用,如果你碰巧不得不使用一个公关在远程。
发生这种情况是因为您要合并的分支的本地副本已经过期。我有我的分支,叫MyBranch我想把它合并到ProjectMaster中。
_>git status
On branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.
nothing to commit, working tree clean
_>git merge ProjectMaster
Already up-to-date.
但我知道有些变化需要合并!
事情是这样的,当我输入git合并ProjectMaster时,git会查看这个分支的本地副本,这可能不是当前的。要查看情况是否如此,我首先告诉Git检查并查看我的分支是否过期,如果是的话,使用fetch获取任何更改。然后我跳到我想合并的分支,看看那里发生了什么……
_>git fetch origin
_>git checkout ProjectMaster
Switched to branch ProjectMaster
**Your branch is behind 'origin/ProjectMaster' by 85 commits, and can be fast-forwarded.**
(use "git pull" to update your local branch)
啊哈!我的本地副本在85次提交时就过时了,这说明了一切!现在,我拉下我所遗漏的更改,然后跳转到MyBranch并再次尝试合并。
_>git pull
Updating 669f825..5b49912
Fast-forward
_>git checkout MyBranch-Issue2
Switched to branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.
_>git merge ProjectMaster
Auto-merging Runbooks/File1.ps1
CONFLICT (content): Merge conflict in Runbooks/Runbooks/File1.ps1
Automatic merge failed; fix conflicts and then commit the result.
现在我有另一个问题要解决…
合并总是在当前HEAD和一个或多个提交之间(通常是分支头或标签), 索引文件必须匹配HEAD提交的树(即上次提交的内容)。 换句话说,git diff——cached HEAD必须报告没有变化。 合并后的提交已经包含在HEAD中。这是最简单的情况,称为“Already - updated”。
这应该意味着测试中的提交已经合并到master中,但由于其他提交是在master上完成的,git diff test仍然会给出一些差异。