在公共功能分支中使用git rebase [英] Use of git rebase in public feature branches

问题描述

你可以看到所有网络人建议在公共分支中不要使用 git rebase ，但是我看不出有什么问题，功能分支。

我的团队总是使用分支来表示特征（哇），我们习惯在本地使用分支，所以rebase不是问题，但有时候我们想要向另一个开发人员展示部分完成功能的代码，所以我们只是宣传它，但是然后我们失去了 git rebase 的所有优点，或者至少可以这样做阅读。

我不明白是什么问题，如果在同一个公共分支上工作的开发者永远不会将它合并到任何分支（当还有开发时在那个分支上），并且当他们拉动它时，他们通过rebase操作来完成它。对分支所做的任何更改总是会在远程分支上重新分配，因此永远不会丢失，并且不会有重复执行相同的重复操作的问题。

追加1：

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

我会举一个使用rebase的工作流程示例（前面段落中严重描述，对不起），我没有看到任何问题。

初始状态：

 主人========== A 
 origin / feature + ===== AB 
功能用户A + ===== AB 
功能用户B + ===== AB 
  

master获得一些提交，并且用户A做了一些提交：

  master ========== A ===== C 
 origin / feature + ===== AB 
功能用户A + ===== AB ==== D 
功能用户B + ===== AB 
  

U ser A做了一个 git pull --rebase （他总是这样做）来更新他的分支，没有什么新东西出现，然后他重新掌握并推送：

  master ========== A ===== C 
原点/特征+ ===== ACB'===== ACB'D 
功能用户A + ===== ACB'===== ACB'D 
功能用户B + ===== AB 
  

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

然后用户B做了一些提交：

  master ========== A ===== C 
 origin / feature + ===== ACB'===== ACB'D 
功能用户A + ===== ACB'===== ACB'D 
功能用户B + ===== AB ====== E 
  

用户B终于和往常一样做了一个 git pull --rebase ，不需要在master上重新绑定，所以他只是推送：

  master ========== A ===== C 
原点/特征+ == === ACB'===== ACB'D ====== E'
功能用户A + ===== ACB'===== ACB'D 
功能用户B + ===== ACB'===== ACB'D ====== E'
  

解决方案

如果你改名，你会重写历史。就像在现实世界中一样，如果你想重写历史，你需要一个阴谋：每个人都必须在阴谋（至少每个人都知道历史，即每个人都从分支中拉出） 。

只要从分支中撤出的人员圈子受到严格控制，就很容易出现阴谋，但是，只要您发布历史，它变得很难。然而，这并非不可能：例如，Junio C Hamano的Git仓库中的 pu 分支在每次发布后都会重新发布，这是一个广泛发布的仓库。这种方式的工作原理是，分支机构经常重新分配以及这种情况发生的时间在Git网站，Git wiki和Git邮件列表中被广泛记录，每个rebase都会提前在邮件列表中公布人们可以为此做好准备。

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

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.

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.

Append 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.

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=====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:

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)

Then user B does a few commits:

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 --rebase as always, there is no need to rebase on master, so he just pushes:

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

解决方案

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 lot harder. It's not impossible, though: the pu branch 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.

这篇关于在公共功能分支中使用git rebase的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！