将主分支（master）变基到特性分支（feature branch）上？

Question

我最近加入了一个新团队，在团队的维基上，要求我们遵循以下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）。有人能解释一下为什么我的团队维基建议使用这种工作流吗？

- leetcode269

---

在你分享的摘录中，展示了一些非常有趣的东西。我永远不会这样做。相反，git pull --rebase origin master 是一个很好的工具来开始。 - 0andriy

这似乎是相反的。也许只是打错了（或多次打错了）？你有问过任何团队成员他们是否真的这样做吗？ - TTT

确实看起来很奇怪。向你的团队询问。 - LeGEC

第一次看到这个可能不太清楚。在本地将特性分支与主分支重新定位不是常见的情况。通常，一旦特性分支更改被审查并合并，我们就会从远程拉取它。让我们知道上述准则的用例是什么。 - Abhishek

听起来像是写那篇维基百科的人需要花几个小时学习Git的工作原理。 - JoelFan

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中。在feature结束之后，master上的后续提交被移动到未来。J和K被拼接到历史A、B、C [splice]、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"。我敢打赌，写这篇指南的人被这个搞混了。

- matt

---

这正是我所想的。结果发现它只是一个指南，我们不需要严格遵循它。我猜这很可能是一个打字错误。感谢你详尽的回答。 - leetcode269