为什么合并后重新变基不是一个好习惯? [英] why it is not a good practice to rebase again after merge?

问题描述

我正在阅读Pro Git书，并陷入重新定级的问题.

I'm reading the Pro Git book and get stuck on rebasing.

下面是场景:

第1步

第2步

我们可以看到遥控器进行了重新设置(这不是一个好习惯，因为其他人可能会基于它进行工作).

We can see that the remote did a rebasing, (not a good practice, because someone else might work based on it).

然后作者说:

如果您进行git pull，将创建一个包含两行历史记录的合并提交，并且您的存储库将如下所示:

If you do a git pull, you’ll create a merge commit which includes both lines of history, and your repository will look like this:

我不明白为什么git pull会自动合并C4和C7，因为我们知道通常git pull不会为您合并，而您必须自己合并，所以在这种情况下为什么会合并git pull为您合并吗?

I do not understand why git pull will automatically merge C4 and C7, because we know that normally git pull does not do merges for you and you have to merge by yourself, so why in this case does git pull merge for you?

对不起，我打打字并想得太快了，我说的是git fetch不会自动合并，git pull会合并并且git pull = git fetch + git merge.

Sorry, I typed and thinked too fast,I was talking about git fetch that doesn't automatically merge, git pull does merge and git pull = git fetch + git merge.

所以我的问题是，为什么作者说:

So my question is, why the author says:

重新设置内容的基础时，您将放弃现有的提交并创建相似但不同的新提交.如果您将提交推送到某个地方，而其他人则将其拉下并基于它们进行工作，然后使用git rebase重写这些提交，然后再次将其上推，那么您的协作者将不得不重新合并他们的工作，并且当您尝试执行以下操作时，事情会变得混乱将他们的工作重新归还给您.

我真的很困惑，如果开发人员在合并后没有进行基础调整，那么我们将第一步中的图片作为开始，然后开发人员在C6之后添加了一个名为C8的新提交，然后，如果我在计算机上调用git pull，则仍需要将C8与C7合并，因此无论如何它都必须重新合并工作，无法避免，并且事情会变得混乱，所以这是什么问题那个吗?

I'm really confused, if the developer didn't do rebasing after the merge so we have the picture in step 1 as the beginning, , then the developer added a new commit called C8 right after C6, then if I call git pull on my computer, C8 will still need to be merged with C7, so it will have to re-merge work anyway, it cannot be avoided and things will get messy, so what's the problem with that?

推荐答案

我认为您只是误解了书中所说的话.

I think you're just misunderstanding what the book says.

所以无论如何都将不得不重新合并工作，这是不可避免的，事情会变得一团糟，那么这又是什么问题呢?

so it will have to re-merge work anyway, it cannot be avoided and things will get messy, so what's the problem with that?

这不是一团糟，只是在进行合并.合并不是一团糟，合并很容易.没问题.

That's not things getting messy, that's just doing a merge. A merge is not messy, a merge is easy. There's no problem with that.

一个混乱的情况是，当其他人拥有您的仓库的副本时，您通过重新定基来重写仓库的历史记录，然后尝试从其他人的副本中合并.它们的副本仍然包含您的回购中不再存在的旧提交，因为您具有等效的，但通过重新创建创建的提交不相同.它变得混乱，因为它将尝试合并不需要合并的提交.

The messy case is when other people have a copy of your repo and you rewrite your repo's history by rebasing, then you try to merge from the other person's copy. Their copy still contains your old commits that no longer exist in your repo, because you have equivalent, but not identical commits created by rebasing. It gets messy because it will try to merge commits that don't need to be merged.

您正在用书中的内容描述重新定级后事情为何混乱的原因，然后尝试在假设的情况下无需重新定级就可以理解它们.当然，这没有任何意义，因为您正在考虑一种完全不同的情况.

You're taking the book's description of why things are messy after rebasing, and then trying to understand them in a hypothetical situation without rebasing. Of course it doesn't make sense, because you're considering a completely different situation.

这篇关于为什么合并后重新变基不是一个好习惯?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！