Git - 合并与变基

Git - Merge vs rebase

提问by user2316341

I have had a look at When do you use git rebase instead of git merge? .

我看过你什么时候使用 git rebase 而不是 git merge？ .

But I'd like to be sure about which solution to choose in this case:

但我想确定在这种情况下选择哪种解决方案：

I want to implement a new feature on masterso I branch it to a new Feature branch.
I do 10 commits on Feature while someone else does other commits on Master.

我想实现一个新功能，master所以我将它分支到一个新的功能分支。
我在 Feature 上做了 10 次提交，而其他人在 Master 上做了其他提交。

My question is if I want to keep my branch apart from Master for testing purposes, but I need to test it with the new Master commits integrated. So, should I merge Master into Feature (and not Feature into Master which would apply my modifications on master before my testing) or do a rebase?

我的问题是我是否想将我的分支与 Master 分开以进行测试，但我需要使用集成的新 Master 提交来测试它。那么，我应该将 Master 合并到 Feature（而不是 Feature 合并到 Master，这将在我的测试之前对 master 应用我的修改）还是执行rebase?

采纳答案by Mark Longair

Why not create a new branch to test the merged version? For example:

为什么不创建一个新分支来测试合并版本？例如：

git checkout -b test-merged-feature master
git merge my-feature
[... do your testing ..]

There's no particularly reason to do a rebase here, but if you haven't already pushed your feature branch, that'd be fine as well. These questions are partly about how you would want your history to look - some people don't like seeing lots of merges; some prefer it as a way of keeping track of which commits contributed to a particular feature.

没有特别的理由在这里进行 rebase，但是如果您还没有推送您的功能分支，那也没关系。这些问题部分是关于你希望你的历史看起来如何——有些人不喜欢看到很多合并；有些人更喜欢它作为跟踪哪些提交对特定功能做出贡献的方式。

回答by VonC

Unless you have already pushed your branch (and you know others have cloned your repo), I would still do a rebase, as I mentioned in my own answer of "git rebase vs git merge".

除非你已经推送了你的分支（并且你知道其他人已经克隆了你的 repo），否则我仍然会做一个 rebase，正如我在我自己的“ git rebase vs git merge”回答中提到的。

Test or not, I usually do a rebase each time I update my local repo (git fetch), in order to ensure the final merge (Featureto master) will be a fast-forward one.

测试与否，我通常在每次更新我的本地存储库 (git fetch) 时执行 rebase，以确保最终合并 ( Featureto master) 将是快进的。

So it isn't just about how your history look, but it is mainly about making sure what you are developing isn't based on an old version of master, and keep working against the latest evolutions done in masterover time.

因此，这不仅仅是关于您的历史记录的外观，而且主要是关于确保您正在开发的内容不是基于旧版本的master，并继续针对master随着时间的推移所做的最新演变而工作。

回答by Chuck L

In workflows I'm familiar with, there is a trunk, and integration branch(s), and feature branches

在我熟悉的工作流中，有一个主干、集成分支和功能分支

I have been rebaseing towards the 'derivative' branches. (by derivative branches, I mean the direction AWAY from the trunk), and merging towards the integration branches.

我一直在转向“衍生”分支。（通过派生分支，我的意思是远离主干的方向），并向集成分支合并。

I like that I'm always working in a branch that has the same history as the branch I'll be integrating with. I like that the merge becomes a fast-forward, so, I know that what I just merged is exactly the same as what I just tested in my branch.

我喜欢我总是在一个与我将要集成的分支具有相同历史记录的分支中工作。我喜欢合并变得快进，因此，我知道我刚刚合并的内容与我刚刚在我的分支中测试的内容完全相同。

回答by Mahmoud Zalt

When 2 developers commit to the same repo (this will make a conflict) you can merge the 2 commits by creating a merge commit or you can rebase 1 of the commits (yours) on top of the other commit. it's always better to rebase instead of generating a merge commit.

当 2 个开发人员提交到同一个 repo（这会产生冲突）时，您可以通过创建一个合并提交来合并 2 个提交，或者您可以将 1 个提交（您的）重新绑定到另一个提交之上。最好是 rebase 而不是生成合并提交。