git - 将 master 重新定位到功能分支？

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

这与我在基本上所有来源上看到的 rebase 工作流程不同，而且它似乎也违背了我从这篇博文 https://www.atlassian.com/git/tutorials/merging-vs-rebasing 中看到的 rebase 黄金法则。 .有人可以解释一下我的团队 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 分离的位置 merge 到 master 中。 master 上的后续提交已移至 future ，以便它们出现在 feature 结束之后。 J和K拼接成历史A,B,C[拼接],D,E。

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

然而，相反的做法，即检查 feature 和 rebase master，会给我们这个:

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

这是明智的做法。它使 feature 与 master 的当前状态保持同步，从而最大限度地减少以后发生冲突的可能性。交互式 rebase 也将变得有意义，因为这是您清理 feature 的机会。然后，您将推送 feature 并发出 pull 请求。这是通常遵循的流程。

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