git - 什么时候对推送的功能分支进行变基是安全的
问题描述
我已经读过，除非我知道后果，否则当它已经被推送到共享存储库时，我不应该重新设置功能分支（使用来自 master 的更改来更新它以允许以后进行无冲突合并）。
那么后果是什么？
我是该功能分支上唯一的开发人员，如果我重写它的历史，我不在乎自己。但是对其他人有什么影响？
我列出了一些我能想到的东西。如果您知道，请纠正我并添加更多内容。
- 有人从我的分支分支/重新定位：他们在下一次拉取时获得了未经请求的分支重新定位
- 有人将我的分支合并到他们的分支中：他们出人意料地得到了更改的合并提交，因此下次拉取时可能会发生冲突
- 有人精心挑选了一个提交：？？？
- 有一个开放的合并/拉取请求：现在指向重新定位的分支？？？
- 与问题、MR/PR、Platform-Markdown 中的提交相关的东西：指向更新的文件/提交？
解决方案
后果适用于在变基之前将工作基于您的分支的人。考虑一下，如果您对功能分支进行了 3 次修订，开发人员 B 然后从您的分支启动了一个分支并进行了 3 次提交......然后你重新设置......然后最终，你的分支被合并到，比如说，master。很好......其他开发人员在 3 次修订后完成并要求合并。如果该分支直接合并，历史会是什么样子？它将为您的 3 次提交（原始修订版和您的 rebase 后出现的修订版）重复......不是最好的东西，对吗？在这种情况下，其他开发人员在合并后必须在你的 rebase 分支或 master 之上进行 rebase。另一个棘手的情况是当您重新设置一个公共分支并且不告诉任何人时。