恢复原始合并后合并 [英] Merge after reverting the original merge
问题描述
好的,当我将一些代码合并到存储库中时,我很专心(某些代码的流程发生了重大变化),所以我不得不还原合并提交.我整天回家,现在在master上有更多提交,而且我似乎无法触发合并以使我的代码可以进入master,因为我有2个文件之间的差异.我很笨拙,已经被迫编写代码.
这是最近一次提交的单线图历史记录:
如何返回适当的合并屏幕,以便我可以处理它?</p>
我当时想我可以在分支中添加另一个提交,然后尝试合并它,但这感觉有点黑.
提交代码然后在分支上还原时,由于原始还原,重新提交相同的代码将无效.例如,假设您在分支B
上有一个或多个提交,并使用提交R
还原了它们:
master
|
* R
|\
| * B
再次将 这里有2种可能的解决方案. 一种是还原还原(将此提交称为 此命令很简单. 另一种可能的解决方案是对整个分支 rebase的命令如下: Linus有一些不错的评论有关这种情况的更多信息. Alright I was inattentive when I was merging some code into a repository(There were major changes in the flow of some code), so I had to revert the merge commit. I went home for the day, and now there are more commits on master, and I can't seem to trigger a merge such that I can get my code into master, as in I have the diffs between the 2 files. I was clumsy and pushed to code to origin already. Here's the one line graph history of the most recent commits: How do I get back a proper merge screen so that I can take care of it? I was thinking I could add another commit to my branch then try to merge it, but that feels hackish. When code is committed and then reverted on a branch, re-committing the same code will have no effect because of the original revert. For example, say you have one or more commits on branch Merging There are 2 possible solutions here. One is to revert the revert (call this commit The command for this is simple. The other possible solution is to rebase the entire branch The commands for the rebase are as follows: Linus has some good commentary on this scenario for more reading. 这篇关于恢复原始合并后合并的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!B
合并为master不会产生任何效果,因为git意识到R
之后的所有提交在之后发生了R
还原R
(即使B
再次合并). /p>
还原还原
R'
).master
|
* R'
|
* R
|\
| * B
$ git revert R
重新设置分支机构
B
进行重新设置,以使它在 还原R
之后出现(称为重新定位的分支B'
).这有几种不同的变体,但是它们都依赖于用R
历史中不存在的新提交重写分支历史.master
|
* New merge commit
|\
| * B'
| \
| ...
* R
|\
| * B
| ...
|/
* A
$ git checkout B
$ git rebase --no-ff A
B
, and you revert them with commit R
:master
|
* R
|\
| * B
B
into master again will have no effect because git realizes that revert R
happened after all the commits in B
(even if B
is merged again).Revert the Revert
R'
).master
|
* R'
|
* R
|\
| * B
$ git revert R
Rebase the Branch
B
so that it comes after the revert R
(call the rebased branch B'
). There are a few different variations of this, but they all depend on rewriting the branch history with new commits that are not present in the history of R
.master
|
* New merge commit
|\
| * B'
| \
| ...
* R
|\
| * B
| ...
|/
* A
$ git checkout B
$ git rebase --no-ff A