问题描述
基于此: https://www.atlassian.com/git/tutorials/rewriting-历史记录/git-rebase
git rebase将使维护线性历史记录成为可能(合并总是"会导致快进)
git rebase will make it possible to maintain a linear history (a merge "always" results in a fast-forward)
但是，如果我想强制执行线性历史记录，并要求开发人员始终将其功能分支基于最新的 master ，这是否会导致协作/共享功能分支消失在窗外?参见:
But if I want to enforce a linear history and require developers to always rebase their feature branches on latest master will that not result in collaboration/sharing feature branches going out the window? See:
是否可以使用git rebase强制执行线性历史记录，并同时允许多个开发人员为同一功能分支做出贡献?
so is it possible to enforce linear history using git rebase and at the same time allow multiple developers to contribute to the same feature branch?
还是git rebase暗示功能分支只有一个所有者?
Or will git rebase imply that there can only be one owner of a feature branch?
推荐答案
不要以公共历史为基础"是一个很好的入门规则.更全面的建议是，如果您要为共享分支机构建立基础，则需要拥有该副本的每个人的协议/合作.
"Don't rebase public history" is a good starter rule. More comprehensive advice is, if you're going to rebase a shared branch, you need the agreement/cooperation of everyone who has a copy of it.
(在这一点上，通常有人喜欢进入并反对有时获得所有人的同意是不切实际的.他们想说的是规则太严格；但这就像说光速太快了一样.慢点，因为我需要更快地旅行.正确的分析是，有时候您不能让所有人都参加；在那种情况下，您不应该根据基准进行简化，因此简化的请勿根据公共历史进行分类". 没有共享分支机构的每个人的合作，对分支机构进行重新设置是不安全的，而您尝试这样做可能很容易最终被意外撤消.但是我离题了……)
(At this point usually someone likes to jump in and object that sometimes getting everyone's consent isn't practical. What they're trying to say is that the rule is too strict; but that's like saying the speed of light is too slow because I need to travel faster. The correct analysis is that yes, sometimes you can't get everyone on board; and in those cases you shouldn't rebase. Hence the simplified "don't rebase public history". If you don't have the cooperation of everyone who shares the branch, it's unsafe to rebase the branch and your attempt to do it could easily end up being accidentally undone. But I'm digressing...)
因此，如果团队成员在 之后进行协作，并且准备合并它，那么就需要重新设置它的基础，每个人都将放弃他们的分支的本地副本，那么就可以了-您需要所有人与rebase的合作.
So, if it's a team norm that after people have collaborated on the branch, and you're ready to merge it, you're going to rebase it and everybody is going to throw away their local copy of the branch, then it's ok - you have everyone's cooperation with the rebase.
但这并不意味着它是一个好主意.用于rebase的市场营销文献喜欢将线性历史描述为简单"，但忽略了闪亮的新线性历史记录主要由从未测试过的代码状态组成(这可能会破坏使用bisect进行错误查找的尝试).一些项目在保留提交拓扑方面具有价值，例如他们可以将特征分支作为一个单元回顾，而不必只弄清一次提交K到N恰好是一个特征分支.
But that doesn't necessarily mean it's a good idea. The marketing literature for rebase likes to talk up linear histories as "simpler", but leaves out that your shiny new linear history is made mostly of code states that have never been tested (which can mess up attempts to bug-hunt with bisect). Some projects find value in preserving the commit topology, so e.g. they can look back on a feature branch as a unit rather than just having to figure out that commits K through N happen to have been a feature branch at one time.
但这一切取决于您/您的团队.如果您认为线性历史记录很适合您，那么是的，即使共享要素分支，也可以做到 ，只要您在合并后仍将其丢弃(这...为什么不是吗?).
But all that's up to you/your team. If you think a linear history is what suits you, then yes, it can be done even when feature branches are shared, so long as you'd discard them after merging anyway (which... why wouldn't you?).
这篇关于git rebase和共享功能分支?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！