在公共功能分支中使用 git rebase

Use of git rebase in public feature branches

提问by Filipe Giusti

You can see all over the web people advising to not use git rebasein a public branch, but I can't see what's the problem, if you always rebase a feature branch.

你可以在网上看到人们建议不要git rebase在公共分支中使用，但我看不出有什么问题，如果你总是重新设置一个功能分支。

My team always uses branches for features (wow), we are used to have it just locally, so rebase isn't a problem, but sometimes we wanna show the code of a partially done feature to another developer, so we just publicize it, but then we lose all of the advantages of git rebase, or at least that's what you can read at the web.

我的团队总是为功能使用分支（哇），我们习惯于在本地拥有它，所以 rebase 不是问题，但有时我们想向另一个开发人员展示部分完成的功能的代码，所以我们只是宣传它，但随后我们就失去了 的所有优点git rebase，或者至少这是您可以在网络上阅读的内容。

I don't understand what's the problem, if the developers working at the same public branch never merge it to any branch (when there is still development on that branch) and when they pull it, they do it with a rebase operation. Any changes made to the branch will be always rebase on top of the remote branch, so never lost and you won't have the problem of having the same commit duplicated.

我不明白有什么问题，如果在同一个公共分支工作的开发人员从不将它合并到任何分支（当该分支上仍有开发时），并且当他们拉它时，他们会通过 rebase 操作来完成。对分支所做的任何更改都将始终基于远程分支的顶部，因此永远不会丢失，并且您不会遇到重复相同提交的问题。

Append 1:

附加1：

None of the answers until now showed the problems that will happen and how it will happen, so I will try to be clearer.

到目前为止，所有答案都没有显示将发生的问题以及如何发生，所以我会尽量说得更清楚。

I will give an example of a workflow using rebase (badly described in the previously paragraphs, sorry) that I don't see any problem.

我将给出一个使用 rebase 的工作流示例（在前面的段落中描述得很糟糕，抱歉）我没有看到任何问题。

Initial state:

初始状态：

master         ==========A
origin/feature           +=====AB
feature user A           +=====AB
feature user B           +=====AB

master get a few commits and user A does a few commits:

master 得到一些提交，用户 A 做了一些提交：

master         ==========A=====C
origin/feature           +=====AB
feature user A           +=====AB====D
feature user B           +=====AB

User A does a git pull --rebase(he always does it) to update his branch, nothing new comes, then he rebase to master and push:

用户 A 做了一个git pull --rebase（他总是这样做）来更新他的分支，没有新的东西出现，然后他变基到 master 和 push：

master         ==========A=====C
origin/feature                 +=====ACB'=====ACB'D
feature user A                 +=====ACB'=====ACB'D
feature user B           +=====AB

(notice the B' is the new commits that still represents the changes B)

（注意 B' 是仍然代表更改 B 的新提交）

Then user B does a few commits:

然后用户 B 做一些提交：

master         ==========A=====C
origin/feature                 +=====ACB'=====ACB'D
feature user A                 +=====ACB'=====ACB'D
feature user B           +=====AB======E

User B finally does a git pull --rebaseas always, there is no need to rebase on master, so he just pushes:

用户B终于git pull --rebase一如既往的做了一个，不需要rebase master，直接push：

master         ==========A=====C
origin/feature                 +=====ACB'=====ACB'D======E'
feature user A                 +=====ACB'=====ACB'D
feature user B                 +=====ACB'=====ACB'D======E'

回答by J?rg W Mittag

If you rebase, you rewrite history. And just like in the real world, if you want to rewrite history, you need a conspiracy: everybody has to be "in" on the conspiracy (at least everybody who knows about the history, i.e. everybody who has ever pulled from the branch).

如果你变基，你就会改写历史。就像在现实世界中一样，如果你想改写历史，你需要一个阴谋：每个人都必须“参与”这个阴谋（至少每个知道历史的人，即每个曾经从分支中撤出的人） .

As long as the circle of people who pull from the branch is tightly controlled, it is fairly easy to get a conspiracy going, however, as soon as you publish that history, it becomes a lotharder. It's not impossible, though: the pubranch in Junio C Hamano's Git repository for example, gets rebased after every release, and that is a widely published repository. The way this works is that the fact that the branch will be frequently rebased and the times when that will happen, are widely documented on the Git website, the Git wiki and the Git mailinglist, and every rebase is announced on the mailinglist in advance so that people can prepare for it.

只要谁从分支拉人的圈子受到严格控制，这是很容易得到一个阴谋然而去，只要你发布的历史，就变成了很多困难。不过，这并非不可能：pu例如，Junio C Hamano 的 Git 存储库中的分支在每次发布后都会重新定位，这是一个广泛发布的存储库。这样做的方式是，分支将频繁地重新定位以及发生这种情况的时间这一事实在 Git 网站、Git wiki 和 Git 邮件列表中得到了广泛的记录，并且每个重新定位都提前在邮件列表中公布，因此人们可以为此做好准备。

回答by Antony Hatchkins

When you rebase againstpublic branch, it's perfectly ok.

当您针对公共分支进行rebase 时，完全没问题。

But when you rebase public branch itself, it is not good for people which are also working with it.

但是，当您重新设置公共分支本身时，这对同时使用它的人不利。

Addition:

添加：

When rebase breaks unittest, you won't have an opportunity to git bisectthe faulty revision.

当 rebase 中断 unittest 时，您将没有机会进行git bisect错误的修订。

In more details:

更多详情：

• you have prepared some code to be added to the branch.
• you have debugged it so it passes all unit tests
• you've git-fetched new changes in the (remote) branch
• now you're rebasing your code against rebased remote branch
• and here unittests get broken
• you're running git bisect and it points at the remote rebase.
• your actions?

• 您已经准备了一些要添加到分支的代码。
• 你已经调试过它所以它通过了所有的单元测试
• 您已经在（远程）分支中 git-fetched 新更改
• 现在您正在针对重新定位的远程分支重新定位您的代码
• 在这里单元测试被破坏了
• 您正在运行 git bisect 并且它指向远程 rebase。
• 你的行为？

回答by moesef

http://git-scm.com/book/ch3-6.html

http://git-scm.com/book/ch3-6.html

Under the section called "Perils of rebasing"

在名为“变基的危险”的部分下

...you'll be scorned by friends and family.

...你会被朋友和家人鄙视。