当我使用 Git 时，我应该在合并之前重新设置基准吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9117128/
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
When I am using Git, should I rebase before I merge?
提问by Code Junkie
I am working on a large scale Rails project, and the team I am working with is using Github to manage the project. While many changes are worked on locally and then pushed directly to our development branch, we create a branch when we are going to work on a very large change. When the time comes to merge that branch back into develop, I often try to rebase develop back into my feature branch before I merge my feature branch into develop (to prevent overwriting of other people's work). I find that when I do this, I seem to run into the same merge conflicts twice. I run into a whole list of conflicts while rebasing, then run into the same list of conflicts again while merging. Should I rebase develop into my feature branch before I merge my feature into develop, or should I just merge my feature into develop?
我正在从事一个大型 Rails 项目，与我合作的团队正在使用 Github 来管理该项目。虽然许多更改在本地进行，然后直接推送到我们的开发分支，但当我们要处理非常大的更改时，我们会创建一个分支。当需要将该分支合并回 develop 时，我经常尝试在将我的功能分支合并到 develop 之前将 develop 变基回我的功能分支（以防止覆盖其他人的工作）。我发现当我这样做时，我似乎两次遇到相同的合并冲突。我在变基时遇到了整个冲突列表，然后在合并时再次遇到了相同的冲突列表。在将我的功能合并到开发之前，我应该将开发重新绑定到我的功能分支，还是应该将我的功能合并到开发？
Let's say my feature branch is called "new_feature". My process for merging it with the "develop" branch goes like this:
假设我的功能分支称为“new_feature”。我将它与“开发”分支合并的过程是这样的：
git checkout develop
git pull (this is set up on our rig to always pull rebase)
git checkout new_feature
git rebase develop
(lots of merge conflicts ensue)
git checkout develop
git merge -no-ff new_feature
(same set of merge conflicts again)
It's as if the timeline changes from my rebase cause my new feature branch to kind of mirror develop all the way back, and then develop conflicts with a psudo-copy of itself.
就好像时间线从我的 rebase 更改导致我的新功能分支一路向后发展，然后与自身的伪副本发生冲突。
回答by Useless
OK, this is too long for a comment now.
好的，现在评论太长了。
To paraphrase the manual (git help rebase)
解释手册 ( git help rebase)
Assume the following history exists and the current branch is "new_feature":
A---B---C new_feature
/
D---E---F---G develop
From this point, the result of either of the following commands:
git rebase develop
git rebase develop new_feature
would be:
A'--B'--C' <new_feature
/
D---E---F---G <develop
Now, if you had conflicts, the actual state after first running rebasewill be
现在，如果你有冲突，第一次运行后的实际状态rebase将是
A'--B'--C'--[local state]
/ ^
D---E---F---G new_feature
^ develop
where [local state]is the conflicted merge you have yet to fix.
Once you've resolved the merge conflicts and added the resolved files to the index, you run git rebase --continue: now your state will be
[local state]您尚未修复的冲突合并在哪里。一旦您解决了合并冲突并将解决的文件添加到索引中，您git rebase --continue就可以运行：现在您的状态将是
A'--B'--C'--H <new_feature
/
D---E---F---G <develop
Obviously at this point merging new_feature back onto develop can be fast-forwarded like so:
显然，此时将 new_feature 合并回 develop 可以像这样快进：
A'--B'--C'--H <new_feature <develop
/
D---E---F---G
but if it isn't you'll get this instead
但如果不是，你会得到这个
A'--B'--C'--H <new_feature
/ \
D---E---F---G---------------I <develop
Now whichever of these you prefer from a timeline perspective, it isn't obvious why either would have a problem ... unless you never completed the rebase and resolved the conflicts with H, but I would think git would complain about that.
现在，从时间线的角度来看，无论您喜欢哪种方式，都不清楚为什么会有问题……除非您从未完成变基并解决了与 的冲突H，但我认为 git 会抱怨这一点。
回答by madth3
Sounds to me like you are using rebase backwards but it might be just a confusing phrasing.
在我看来，您正在向后使用 rebase，但这可能只是一个令人困惑的措辞。
I'd rebase the feature branch ontodevelop and then (on develop) do a git merge --ff-only feature.
我变基的特性分支上开发，然后（在开发）做了git merge --ff-only feature。
回答by Adam Dymitruk
Since you are specifying "large-scale" and "rebase" in the same question, I would advise you to not do that. Use merges instead.
由于您在同一问题中指定了“大规模”和“变基”，我建议您不要这样做。改用合并。
Using --no-ff in merges is great for the purpose of preserving the original branch point. I support using it.
在合并中使用 --no-ff 非常适合保留原始分支点。我支持使用它。
