git重设基础并共享功能分支？

基于此：

git rebase将使维护线性历史成为可能（合并“始终”会导致快进）

但是，如果我想强制执行线性历史记录，并要求开发人员始终在最新的master上重新设置其功能分支的基础，这会不会导致协作/共享功能分支退出窗口？见：

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

---

或者git rebase是否意味着一个功能分支只能有一个所有者？

是的，这是可能的。尽管建议一定程度的谨慎

使用rebase，要素分支更改将添加到主开发线中。这应该在审核之后发生（在GitLab/GitHub中：在接受合并/拉取请求之后）。因此，之前的开发不一定涉及任何早期的重新调整；功能分支可能已由多个开发人员共享、处理和提交

---

不要重新设定公共历史的基础

---

这通常意味着您不应重新设置其他人可能基于其工作的提交的基础（如

master

或

develope

公共存储库分支）。由于任何人都不应将他们的工作建立在已完成但尚未合并的功能分支上，因此这不适用于您的情况。

我建议您可以鼓励（而不是强制）线性历史，要求开发人员在同行评审前的最后一步重新确定其功能分支的基础

这将允许开发人员进行协作、交叉合并，并对该功能感到满意，然后再对历史进行最终重写，以便于审阅者阅读

当然，这仍然存在重新确定公共历史的风险，并且可能会给不太熟悉此类实践的开发人员带来问题。这就是为什么我会鼓励那些对它感到满意但不执行它的人重新定基调的原因。

不要重新定公共历史的基调是一个很好的开始规则。更全面的建议是，如果你要重新设定共享分支的基础，你需要所有拥有该分支的人的同意/合作

（在这一点上，通常有人喜欢插嘴，反对有时得到每个人的同意是不现实的。他们试图说的是规则太严格了；但这就像说光速太慢了，因为我需要走得更快。正确的分析是，是的，有时你不能让每个人都上船；而且那些情况下你不应该重新设置基础。因此简化了“不要重新设置公共历史基础”。如果你没有共享分支的每个人的合作，重新设置分支的基础是不安全的，你的尝试很容易被意外撤销。但我正在偏离…）

因此，如果这是一个团队规范，在人们在分支上合作之后，你准备合并它，你将重新设置它的基础，每个人都将扔掉他们的分支的本地副本，那么没关系-每个人都与重新设置基础合作

但这并不一定意味着这是一个好主意。rebase的营销文献喜欢将线性历史称为“更简单”，但却忽略了你闪亮的新线性历史主要是由从未测试过的代码状态组成的（这可能会打乱用

对分进行bug搜索的尝试）。一些项目在保留提交拓扑结构方面发现了价值，因此，例如，他们可以将功能分支作为一个单元进行回顾，而不必仅仅找出提交K到N恰好是一个功能分支

但所有这一切都取决于你/你的团队。如果你认为线性历史适合你，那么是的，即使在共享特征分支时也可以这样做，只要你在合并之后放弃它们（这…你为什么不呢？）.
我想你的问题源于一个通用的工作流程，即拥有一个中央git存储库而不是私有的分支。在这个远程存储库上，所有的分支都可以从所有开发人员那里推送。正是因为它们可以，每个开发人员都会感到有权推送和合并他们想要的任何东西。有了这样的工作流程，
git rebase
确实会变得很危险，因为开发人员可能会由于强制执行而删除提交，而不小心删除了已经推送的提交

如果您有这个牛仔git工作流，那么建议开发人员使用
--force with lease
而不是仅仅使用
--force
，这可能是明智的

我认为协作和共享功能分支走出窗口是一件好事

在我的团队的主要远程git存储库（真相之源）中，我的主分支受到了回扣保护

我建议这些规则：


始终从主功能派生功能分支，没有例外
再次说明：永远不要派生另一个要素分支的要素分支
如果您依赖于另一个开发人员当前正在开发的另一个功能，请等待他们将这些更改合并到主功能中
rebase
您的功能分支经常与
master
相对应（包括您的依赖项，或者只是让master保持最新），因为这有助于解决发生的合并冲突
可选：压缩提交到一个，如果您使用GitWeb前端（github、bitbucket等），它们提供了合并压缩请求的功能，您可能也需要使用该功能

创建分支的开发人员拥有该分支。他们可以做任何他们想做的事情：删除、重定基址、tango合并、与其他人在该分支上进行结对编程（其他人可能仍会在其分支上提交，但只有在拥有者明确同意和知情的情况下）

主要分支机构，如
master
或
develope
，都是公共分支机构。它们是神圣的。你不会改变它们的历史，你也不会改变它们