git rebase 大量提交时如何防止大量 git 冲突?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/7241678/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to prevent lot of git conflicts when git rebasing lot of commits?
提问by equivalent8
Story: in the middle of a project my colleague created a new branch from masterand started doing her heavy re-factoring work. I created my branch from masterand started doing new stuff on the page. We are committing regularly, but only I can rebase code to master(because colleagues changes are too heavy and cannot be deployed from master yet). Unfortunately some of our work rely on the same files. So after few days of work when she finally wanted to rebase her changes to master, she had a lot of git conflicts.
故事:在一个项目中,我的同事从master创建了一个新分支,并开始进行繁重的重构工作。我从master创建了我的分支并开始在页面上做新的事情。我们定期提交,但只有我可以将代码 rebase 到master(因为同事更改太重,还不能从 master 部署)。不幸的是,我们的一些工作依赖于相同的文件。因此,经过几天的工作,当她最终想要将更改重新设置为master 时,她遇到了很多 git 冲突。
my_branch #---#----#-#-------#----#--#-----#---#----#----#
/ \ \ \ \ \ \
master *-------*--------------*---*---*--------------*----*----*
\ /
her branch #------#-------#-----------#-----------#------------#
Question 1 is: how to prevent lot of git conflicts when we are working on same files? (or what is the best practice in this situation?)
问题 1 是:如何在处理相同文件时防止大量 git 冲突?(或者在这种情况下最好的做法是什么?)
but this isn't the end of our question, ...to be absolutely correct she tried to do rebase from master to her branch (to have changes I committed), so the commit map should look something like this
但这不是我们问题的结束,......绝对正确,她试图从 master 到她的分支进行 rebase(为了我提交的更改),所以提交映射应该看起来像这样
my_branch #---#----#-#-------#----#--#-----#---#----#----#
/ \ \ \ \ \ \
master *-------*--------------*---*---*--------------*----*----*
\ \ \ /
her branch #------#-------#----*------#-----*-----#------------#
And this is what is bothering us. During these rebases she was fixing those conflicts. But git doesn't remember her decision on conflict fix, so when she did another git rebase from masterto her-branchshe had to fix the same git conflicts againthat she was fixing in previous rebases.
而这正是困扰我们的地方。在这些变基期间,她正在解决这些冲突。但是 git 不记得她关于冲突修复的决定,所以当她从master到她的分支进行另一个 git rebase 时,她不得不再次修复她在以前的rebase中修复的相同 git 冲突。
Question 2 is: how to tell git to remember git conflict fix after git rebase from masterbranch, so after next rebase we don't have to fix the same conflicts again?
问题 2 是:如何告诉 git 在master分支的git rebase 之后记住 git 冲突修复,所以在下一次 rebase 之后我们不必再次修复相同的冲突?
回答by Mark Longair
Fortunately, git has a mechanism for dealing with exactly this problem called git rerere
- essentially, if you have git rerere
enabled, then each time your resolve a conflict the fact that you resolved that exact conflict in a particular way is remembered. If the same conflict comes up again, the same resolution is automatically used. There are some helpful articles below:
幸运的是,git 有一种机制可以准确地处理这个问题,称为git rerere
- 本质上,如果您git rerere
启用了,那么每次解决冲突时,都会记住您以特定方式解决该确切冲突的事实。如果再次出现相同的冲突,则会自动使用相同的解决方案。下面有一些有用的文章:
- http://scottchacon.com/2010/03/08/rerere.html(blog post)
- http://git-scm.com/docs/git-rerere.html(manual entry)
- Are there any downsides to enabling git rerere?(question in stackoverflow)
- http://progit.org/2010/03/08/rerere.html(original answer link: seems broken)
- http://scottchacon.com/2010/03/08/rerere.html(博客文章)
- http://git-scm.com/docs/git-rerere.html(手动输入)
- 启用 git rerere 有什么缺点吗?(stackoverflow 中的问题)
- http://progit.org/2010/03/08/rerere.html(原答案链接:好像坏了)
... but essentially you can just do:
...但基本上你可以这样做:
git config --global rerere.enabled 1
... and forget about it, while enjoying easier rebasing / merging :)
...忘记它,同时享受更轻松的变基/合并:)
回答by ?imon Tóth
Make sure that you are always rebasing using the --onto
switch.
确保您始终使用--onto
开关进行变基。
To prevent conflicts, use floating development branches. Each developer will continuously rebase their development branch. This is easy since the developer knows what he just implemented and shouldn't have problem with solving conflicts. Instead of rebasing, just merge the final version (it will already be rebased).
为防止冲突,请使用浮动开发分支。每个开发人员将不断地重新设定他们的开发分支。这很容易,因为开发人员知道他刚刚实现了什么,并且在解决冲突时应该没有问题。而不是重新定位,只需合并最终版本(它已经重新定位)。