[英]Rebasing master onto feature branch?
I recently joined a new team and on the team wiki, it asks us to do the follow git workflow我最近加入了一个新团队,在团队 wiki 上,它要求我们遵循 git 工作流程
git checkout -b feature_branch
#do stuff and push if needed
git checkout master
git rebase feature_branch
git rebase -i HEAD~NUMBER_OF_COMMITS_AHEAD
This is different from the rebase workflow I've seen on basically all sources and it also seems to go against the golden rule of rebasing that I saw from this blog post https://www.atlassian.com/git/tutorials/merging-vs-rebasing .这与我在基本上所有来源上看到的变基工作流程不同,它似乎也违反了我从这篇博文 https://www.atlassian.com/git/tutorials/merging-看到的变基黄金法则与变基。 Can someone explain what could be the reasons for the workflow my team wiki suggests?
有人可以解释我的团队 wiki 建议的工作流程可能是什么原因吗?
Assuming the instructions are accurate, they would appear to be executing a splice of feature
into master
.假设指令是准确的,它们似乎正在执行一个拼接到
master
中的feature
。 Suppose we start with this:假设我们从这个开始:
* (HEAD -> master) E
* D
| * (feature) K
| * J
|/
* C
* B
* A
Now if we checkout master
and rebase feature
, we get this:现在,如果我们检查
master
和rebase feature
,我们会得到:
* (HEAD -> master) E
* D
* (feature) K
* J
* C
* B
* A
So the entirety of feature
has been incorporated into master
at the point where it split off from master
.因此,在 master 与
master
分离的地方,整个feature
都被合并到了master
中。 Subsequent commits on master
have been moved into the future so that they come after the end of feature
. master
上的后续提交已移至未来,以便它们在feature
结束之后进行。 J and K are spliced into the history A, B, C [splice], D, E. J和K拼接成历史A,B,C【拼接】,D,E。
It's hard to imagine what the purpose of that would be, and it's even harder to imagine what the interactive rebase at the end is supposed to accomplish.很难想象这样做的目的是什么,更难想象最后交互式 rebase 应该完成什么。
The opposite move, however, namely to checkout feature
and rebase master
, would give us this:然而,相反的举动,即 checkout
feature
和rebase master
,会给我们这个:
* (feature) K
* J
* (HEAD -> master) E
* D
* C
* B
* A
That is a sensible thing to do.这是明智的做法。 It brings
feature
up to date with the current state of master
, minimizing the likelihood of conflicts later.它使
feature
与master
的当前 state 保持同步,从而最大限度地减少以后发生冲突的可能性。 And the interactive rebase would then make sense too, because that's your chance to clean up feature
.并且交互式变基也将有意义,因为这是您清理
feature
的机会。 You would then push feature
and make a pull request.然后,您将推送
feature
并发出拉取请求。 That is the flow that is generally followed.这是通常遵循的流程。
So my guess is that the instructions are just a mistake.所以我的猜测是这些说明只是一个错误。 It's an easy mistake to make if you're not careful, because the sense of the operations
checkout X; merge Y
一不小心就很容易犯错,因为操作感是
checkout X; merge Y
checkout X; merge Y
is the opposite of the sense of the operations checkout X; rebase Y
checkout X; merge Y
与操作checkout X; rebase Y
checkout X; rebase Y
. checkout X; rebase Y
。 The former means "merge Y into X", but the latter means "rebase X onto Y".前者的意思是“将 Y 合并到 X 中”,而后者的意思是“将 X 重新定位到 Y 上”。 I'll bet whoever wrote the instructions was confused by that.
我敢打赌,写说明的人对此感到困惑。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.