当我在功能分支上工作时，我倾向于在使用我的工作进行审查并将其集成到主分支之前，使用交互式rebase清理分支中的提交。

在开发功能期间，我想将我的中间工作推送到远程存储库作为备份措施。即，当我的硬盘崩溃时，我不想丢失整个功能分支。

但是，这导致这样一个事实，即git push --force在重新设置基准之后，我经常不得不对远程存储库执行“ a” 操作，这种操作通常不被接受。或如链接的github页面所说：

由于更改提交历史记录可能会使使用存储库的其他所有人感到困难，因此，当您已经将其推送到存储库时，对提交进行重新基准设置是不明智的做法。

是否有解决这一冲突的（通常被接受的）政策？

为什么这不是git的“重订黄金法则”那么重要吗？

我在这里的问题是要寻求一种解决方案，以解决要在远程存储库中备份您的工作和重新部署工作之间的冲突，而另一个问题试图否认存在冲突，并问为什么有些人认为冲突根本存在，并因此问为什么不强制变基是“必要的”？

问自己的关键问题：

• 合并回master后，您是否保留远程分支？

如果在合并到master之后删除远程功能分支，则您已经失去了历史记录。假设您在合并/ PR之前先压缩/重新设置分支，那么您将丢失此历史记录。在这种情况下，您所需要执行的所有操作就是允许您使用github作为备份。

您希望保留历史记录而不是强制推送的情况是，如果您的远程分支在合并后仍然存在并且不仅存在了一段短暂的时间，而且仍然存在。

我想你是在问我是否保留未重新建立基础的分支？不，AFAIC。尽管如此，推强制它从理论上可能会导致其他用户的损失，而这些用户都被推到同一分支

听起来您有多个人同时推送到该分支。这意味着您确实关心分支的历史记录。

您可以为中间工作做的是创建该分支的派生。您可以执行此操作，然后在合并之前将所有提交重新设置为单个提交，因此，将它们合并到功能分支中时，您只有1个提交（具有整个分支的重新记录的历史记录）。

我在这里列出了一些我无法想到的可能性。

始终基于新分支

当分支混乱时some-feature，请将其重新建立在新分支上。例如

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

然后进行some-feature-rebase了审查和整合。

问题：严格来说，这是一个很大的缺点，您需要为每个重新配置一个新分支。（例如，如果在代码审查后进行更改，则可能有多个基准）

利用 git push --force-with-lease

我刚刚了解的git push --force-with-lease替代品git push --force，其

拒绝更新分支，除非它是我们期望的状态；即没有人更新上游分支。

问题：这似乎在我们使用just的情况下直接改善了--force，但是仍然存在一些警告，尤其是当我用a git fetch代替a时git pull，它更新了本地上游分支，并欺骗--force-with-lease认为远程没有进行任何未合并的更改科。