当我这样做时git rebase branch1,我branch1-local会发生冲突.我解决了冲突,做了git add <conflicted-add>然后git rebase --continue就像git要求我做的那样.之后,将应用新的提交.出现了新的冲突.但是再次发生同样的冲突!同一个文件!我再这样做,git add的git rebase --continue,然后这一切再次重复,直到我重复这一过程,每次提交被重建基础上.
为什么rebase让我一遍又一遍地重做同样的冲突解决方案？
故事:在一个项目的中间,我的同事从大师那里创建了一个新的分支,并开始进行繁重的重新分解工作.我从master创建了我的分支,并开始在页面上做新的东西.我们经常提交,但只有我可以修改代码才能掌握(因为同事的更改太重,无法从主服务器部署).不幸的是,我们的一些工作依赖于相同的文件.因此,经过几天的工作,她终于想要改变主人的变化,她有很多git冲突.
my_branch #---#----#-#-------#----#--#-----#---#----#----#
/ \ \ \ \ \ \
master *-------*--------------*---*---*--------------*----*----*
\ /
her branch #------#-------#-----------#-----------#------------#
问题1是:当我们处理相同的文件时,如何防止大量的git冲突？(或者在这种情况下最佳做法是什么？)
但这不是我们问题的结束,...绝对正确她试图从主人到她的分支进行变基(为了进行我所做的更改),所以提交映射应该看起来像这样
my_branch #---#----#-#-------#----#--#-----#---#----#----#
/ \ \ \ \ \ \
master *-------*--------------*---*---*--------------*----*----*
\ \ \ /
her branch #------#-------#----*------#-----*-----#------------#
这就是困扰我们的事情.在这些改变期间,她正在解决这些冲突.但是git不记得她关于冲突修复的决定,所以当她从主人到她的分支做另一个git rebase时,她不得不再次修复同样的git冲突,以至于她在以前的rebase 中修复了.
问题2是:如何告诉git在主分支git rebase之后记住git冲突修复,那么在下一个rebase之后我们不必再次修复相同的冲突了？
在完成一个主题分支的工作后,我将主题分支合并为master,如下所示:
o---*---o---o topic
/ \
o---o---o---*---o---o---+ master
标有"*"的提交修改了相同的代码,因此合并导致合并提交中解决的合并冲突(标记为"+").
当我合并并解决冲突时,我的同事将新的提交推送到主人(标记为'n'),导致以下历史记录:
o---*---o---o topic
/ \
o---o---o---*---o---o---+ master
\
n---n origin/master
现在,推送我的本地主分支当然会导致错误,因为它没有快进,所以我有两个选择:
扔掉我的工作,将master重置为origin/master并重做合并.我想避免这种情况,因为我必须重新解决冲突.
Rebase master到origin/master并推送.这就是我的问题:执行此rebase(即使使用-p开关)也不能顺利运行,合并提交再次显示相同的冲突,即使新提交('n')没有更改主题分支触及的任何内容.因此,我必须在rebase期间再次解决冲突,并且与选项1具有相同的结果.
我想要实现的是重新定义合并提交'+'而不必再次解决冲突:
o---*---o---o-------- topic
/ \
o---o---o---*---o---o---n---n---+ master & origin/master
编辑:
启用了rerere开关,但似乎没有任何帮助; 除了将config.rerere设置为true以解决我的问题,我还需要做什么吗？
编辑2:
将merge-commit('+')合并到origin/master也可以工作(如注释和答案中所提出的那样),但是会导致一种丑陋的历史记录,我只想通过一次合并提交来避免这种历史记录.
据我所知,通过保存冲突解决信息来实现项目同步非常有用,但我并不完全清楚如何使用和配置它.
我想配置我的持续集成(CI)环境.建议这样做吗？
请不要在另一个问题上标记副本:启用git rerere是否有任何缺点？.因为我的怀疑与"因此是否有任何不利因素"无关？它会导致哪些潜在的问题不会发生呢？
作为php-src的开发人员,我最近发现自己处于以下情况:
A B C
o---o---o version1
\
o---o-----o---o master
x y D E
o---o---o upstream/master
x y z
所以当我这样做时,我会git push --dry-run upstream master version1得到典型的:
! [rejected] master -> master (fetch first)
我的自然反应是重新绑定受影响的分支并保留合并提交:
git fetch upstream
git rebase -p upstream/master
重要的是要注意原始的合并提交并不简单,因为版本分支和主服务器之间有很多变化; 它需要努力来解决这样的合并.
执行上述rebase操作会导致合并冲突,我必须再次解决它; 这几乎与我已经完成的工作完全相同.
有一个更好的方法吗？或者我忘记了一个明显的rebase选项？
背景
我目前正在解决与启用git rerere的合并冲突.git status显示一条未合并的路径.当我查看文件时,没有<<<<<<< HEAD或>>>>>>> <SHA>标记识别冲突,这告诉我rerere已经完成了它的工作并根据我过去的方式解决了冲突.
我想确认rerere的决议是正确的.
我正在进行的合并过程非常复杂,涉及到Linux内核的多个遥控器.我昨天做了几个遥控器的测试合并,目的是识别冲突,通知维护者,然后丢弃最终的(肯定已损坏的)内核.在这样做的时候,我做了几个不小心的冲突解决方案,只是为了继续下一个遥控器,并且git rerere forget <pathspec>在我完成之后调用了所有冲突的路径,包括我正在处理的那个.因为我告诉rerere忘记这条路径,我不知道为什么它在这次运行中解决了任何问题,我担心它应用了我昨天做的修复,当时我不在乎结果是否正确.
问题
是否有任何方法可以查看在已经应用解决方案后重新解决的冲突？
我想避免重新启动合并,因为这是一个漫长的过程,我们还没有完全自动化.此外,因为我试图告诉rerere昨天忘记了这条路,但它今天仍然应用了一个解决方案,我想如果我不知道为什么git rerere forget <pathspec>先失败,我会最终处于相同的位置.
相关问题
撤消在rebase中完成的git rerere解决 方案< - 解决方案需要重新启动合并
启用git rerere是否有任何缺点？< - 只讨论git rerere forget <pathspec>
跟进注意/问题
我刚尝试输入git rerere forget没有pathspec,我知道这是不赞成的,但如果我理解正确,应该让rerere忘记所有的决议.我重新合并,它仍然对文件应用了一个解决方案.我也完全禁用了rerere并且第三次运行合并,所以我可以看到冲突,而rerere确实应用了我昨天所做的半心半意的决议.为什么forget不正确地丢弃我不想重用的解决方案？
这是我们当前的功能分支工作流程 ->
问题：
如果我们将功能分支合并到主分支中，那么就没有问题。如果我们进行定期合并，然后重新建立基础，我们必须再次解决所有冲突。在具有 100 个提交的功能分支上，这是一个很大的痛苦。
有没有办法将功能分支合并回master并rebase而不发生冲突？