git rebase 和共享功能分支？

Question

基于此: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase

git rebase 将使维护线性历史成为可能( merge “总是”导致快进)

但是，如果我想强制执行线性历史并要求开发人员始终将他们的功能分支重新设置为最新的 ma​​ster，这不会导致协作/共享功能分支消失吗？见:

Don't rebase public history

那么是否可以使用 git rebase 强制执行线性历史，同时允许多个开发人员为同一功能分支做出贡献？

或者 git rebase 会暗示功能分支只能有一个所有者吗？

Answer 1

“不要改变公共(public)历史”是一个很好的入门规则。更全面的建议是，如果您要对共享分支进行 rebase ，则需要拥有该分支副本的每个人的同意/合作。

(在这一点上，通常有人喜欢插嘴反对，有时征得所有人的同意是不切实际的。他们想说的是规则太严格了；但这就像说光速太快了。慢是因为我需要走得更快。正确的分析是，是的，有时你不能让所有人都参与；在那些情况下你不应该 rebase 。因此简化的“不要 rebase 公共(public)历史”。如果你不这样做在共享分支的每个人的合作下，对分支进行 rebase 是不安全的，并且您尝试这样做很容易最终被意外撤消。但我离题了...)

因此，如果这是一个团队规范，在人们在分支上进行协作，并且您准备 merge 它，那么您将对其进行 rebase ，并且每个人都将丢弃他们的分支的本地副本，然后就可以了 - 你有每个人与 rebase 的合作。

但这并不一定意味着这是个好主意。 rebase 的营销文献喜欢将线性历史描述为“更简单”，但忽略了你 Shiny 的新线性历史主要由从未测试过的代码状态组成(这可能会扰乱使用 寻找错误的尝试一分为二)。一些项目发现保留提交拓扑的值(value)，例如他们可以回顾一个功能分支作为一个单元，而不是仅仅必须弄清楚提交 K 到 N 恰好曾经是一个功能分支。

但这一切都取决于您/您的团队。如果您认为线性历史适合您，那么是的，它可以即使在共享功能分支时也可以完成，只要您在 merge 后无论如何都丢弃它们(这......为什么不是吗？)。