我有一个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 "
但是,检查每个不同分支下的文件可以清楚地显示出差异。
这里的问题是什么,我如何解决它?
当前回答
下面是从另一个分支获得更改的方法,而不考虑合并历史(注意:这会清除工作树,所以git在尝试之前会隐藏或提交更改)
// stash changes to ensure you don't lose any edits
git checkout your-branch-that-won't-simply-merge
git stash
git checkout branch-with-changes -- .
——。参数将检出其他分支的所有文件,同时仍检出到同一分支。然后您可以按照自己的意愿添加和提交。
我还将它与 Git add -p 这将使你能够在“大块头”中进行任何变化。它会询问y/n您是否想要执行任何更改过的行块,这意味着您可以在下次提交时保留不想要的更改。
这是我找到的原始答案的链接,去点赞吧。: https://stackoverflow.com/a/15536640/8272035
89年问题 通过提供当前路径,.:
Git签出other-branch-name——。
此操作类似于在不签出文件的情况下将HEAD切换到另一个分支,但只是从“另一个方向”切换。
正如@김민준提到的,这将覆盖任何未提交的更改。如果需要的话,记得先把它们藏起来或提交到某个地方。
其他回答
我有一种重新合并它的方法,我的场景是我需要合并一个发布分支。
条件:发布分支代码是金的。意思是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步可以发生在本地,只是看看预期的部分是否已应用,如果你碰巧不得不使用一个公关在远程。
假设你有一个具有以下提交历史的分支master:
A -- B -- C -- D
现在,你创建了一个分支测试,处理它,并执行4次提交:
E -- F -- G -- H
/
A -- B -- C -- D
主人的头指向D,测试者的头指向H。
当你要合并的分支的HEAD是你想要合并的分支的提交链的父节点时,就会显示“Already - updated”消息。 这里的情况就是这样:D是E的父结点。
从测试到主服务器没有什么需要合并的,因为从那时起主服务器上没有任何变化。 你在这里要做的就是告诉Git让master的head指向H,所以master的分支有如下的提交历史:
A -- B -- C -- D -- E -- F -- G -- H
这是一个Git命令重置的作业。 你也想让工作目录反映这个变化,所以你要做一个硬重置:
git reset --hard H
如果将分支A合并到分支B报告“Already up to date”,则反过来并不总是正确的。只有当分支B是分支A的后代时才成立,否则 分支B可以有A中没有的变更。
例子:
在master上创建分支A和B 您在master中做了一些更改,并只将这些更改合并到分支B中(不更新或忘记更新分支A)。 你在分支A中做了一些改变,并将A合并到B。
在这一点上,合并A到B报告“已经更新”,但分支是不同的,因为分支B有来自主的更新,而分支A没有。
这很傻,但可能会发生。假设你的分支名称前缀是一个问题引用(例如#91-fix-html-markup),如果你这样合并:
$ git merge #91-fix-html-markup
它不会像预期的那样工作,因为#之后的所有内容都被忽略,因为#开始一个内联注释。
在这种情况下,你可以重命名分支,省略#或使用单引号环绕分支名称:git merge '#91-fix-html-markup'。
同样的事情也发生在我身上。 但是这个场景有点不同,我有一个master分支,我从它中分离出release_1(比如说)。 在release_1分支中做了一些更改,并将其合并到origin中。然后我在远程服务器上使用ssh 我再次使用命令git checkout -b release_1签出release_1,这实际上是一个新的分支release_!而不是从origin签出已经存在的分支release_1。 通过移除“-b”开关解决了问题