Question

我最近加入了一个新团队，并且在团队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

这与我在所有资源上看到的变基工作流不同，它似乎还违背了我在此博客文章https://www.atlassian.com/git/tutorials/merging-vs-rebasing中看到的变基的黄金法则。有人可以解释我的团队Wiki建议工作流程的原因是什么吗？

Answer 1

假设指令正确无误，它们似乎正在将feature拼接到master中。假设我们从这里开始：

* (HEAD -> master) E
* D
| * (feature) K
| * J
|/  
* C
* B
* A

现在，如果我们结帐master和rebase feature，我们会得到：

* (HEAD -> master) E
* D
* (feature) K
* J
* C
* B
* A

因此，feature的整体已在与master分离的位置合并到master中。 master上的后续提交已移至将来，以便它们在feature结束之后提交。 J和K拼接到历史A，B，C [拼接]，D，E中。

很难想象这样做的目的是什么，甚至更难以想象最后的交互式基础应该完成什么。

相反的做法是结帐feature和rebase master，这会给我们带来以下好处：

* (feature) K
* J
* (HEAD -> master) E
* D
* C
* B
* A

这是明智的选择。它将feature的当前状态更新为master，从而最大程度地减少了以后发生冲突的可能性。然后，交互式重新设置也很有意义，因为这是清理feature的机会。然后，您将推feature并发出拉请求。这就是通常遵循的流程。

所以我的猜测是这些说明只是一个错误。如果您不小心，很容易犯一个错误，因为操作checkout X; merge Y的含义与操作checkout X; rebase Y的含义相反。前者的意思是“将Y合并到X”，而后者的意思是“将X重新合并到Y”。我敢打赌写指令的人对此感到困惑。