有一条规则，不重新对推送到远程存储库的提交进行基础处理。只要我理解其中的一般原因，我就不清楚，它是否也适用于这种情况：
比方说，我正在开发一些功能，这将需要几天的时间。所以，我创建分支MyFeature，签出它，并提交一些东西。由于工作需要几天时间，我不想把它放在本地机器上，所以为了备份，我把这个分支推到了远程。
完成工作后，我想以某种方式将它合并到大师那里。
我的问题：
- 假设没有其他人永远不会签出和提取MyFeature分支，并且他的工作基于该分支的提交(为什么有人想提取一些随机分支？)，可以重新建立这样的远程分支的基础吗？(使用-强制开关)
- 如果出于某种原因仍然不可取(不过我想了解一下这个原因)，还有什么选择？简单的合并？但如果是这样的话，之后，我仍然希望从本地和远程存储库中删除MyFeature分支。那么，它与(1)有何不同？我仍然通过彻底删除它来改变历史
- 上述情况是罕见还是非典型？我的意思是，在搜索这个问题的答案、阅读教程和关于git rebase的SO问题时，人们总是强调重新建立远程分支的基础的危险，但从未考虑过其他类似的用例。IMHO在某些功能上花更长的时间是很常见的，我认为任何谨慎的开发人员都不应该只在他的电脑上进行更改
假设其他人永远不会签出和拉取MyFeature分支，并且他的工作基于来自该分支的提交，那么可以重新建立这样的远程分支的基础吗？(使用-强制开关)
不仅可以使用rebase并在master上强制推送远程功能分支，而且在保持线性的同时引入更改是保持领先于master的唯一方法。当您在另一个分支(如master)上rebase您的本地功能分支时，您必须强制推送到远程，因为您已经有效地重写了历史。没有造成任何伤害的风险，因为你将是唯一一个在这个分支机构工作的人。我采取的方法是，Git创建的任何东西都不是天生邪恶的，每个Git功能都有其时间和地点。这是一个可以接受力推的例子。
事实上，远程个人功能分支是唯一可以在已经推送到远程的分支上使用rebase的实例。如前所述，您不会给其他人带来问题，因为只有您签出了此分支。
也就是说，对许多用户共享的公共分支执行rebase是危险的，因为当他们进行下一次拉取时，这可能会给每个人带来冲突(当然，除了进行重新绑定的用户)。
非常主观"可以吗"给谁？给你？给你的雇主？问问他们。
关于技术可行性：
-
是的，没问题。
-
您可以合并并删除分支。我更喜欢这种方法(参见？主观)，我甚至使用
git merge --no-ff，这样即使合并是快进的，也会创建合并提交。删除分支不会修改历史记录；您只需移除分支指针，而不是提交。另一种选择是
git merge --squash，它压缩分支以合并为单个提交，该提交将应用于要合并的分支。我不喜欢，但有些人喜欢。 -
不，它既不罕见也不非典型。
在我看来，只有一个开发人员重新构建功能分支的基础不是问题。我的工作方式与您完全相同，我重新建立了自己的功能分支的基础。如果所有功能分支在合并之前都重新建立了基础，那么git历史记录会变得更容易查看。但这当然是个人偏好。
共享分支在重新定基时会造成麻烦。请在此处查看原因解释：https://superuser.com/a/667200
假设其他人永远不会签出和拉取MyFeature分支，并且他的工作基于该分支的提交(为什么有人想拉一些随机分支？)，可以重新建立这样的远程分支的基础吗？
当然，rebase步骤不需要--force
您只需要它来强制推送您的分支
git checkout MyFeature
git fetch
git rebase origin/master
git push --force
只要你在上游回购中更新你自己的分支机构，这就不应该是一个问题。