到目前为止，我一直经常在以下两种方式进行交互式git变基调：未完成的工作，或者我所知道的推动工作，我确实是唯一可以工作的人。
我知道压缩提交和整体重写历史在进行协作时可能会非常棘手。
尽可能少的疼痛，最好的做法是什么？
如果我压制一些提交并推动，当他拉回时，回购的工作站会怎么样？
我知道重写历史的概念是一场永无止境的辩论，但在这里我只是在寻找一种技术解决方案来解决这个问题。
答案 0 :(得分：3)
尽可能少的疼痛，最好的做法是什么？
最佳做法是避免它。
正如ElpieKay建议的那样，拥有一个“发布分支”是一个很好的做法，历史是安全的，事情是稳定的，但也有“开发/功能分支”，你可以做任何你想做的事情，直到你合并/再次将它们变成稳定的主分支。
回答您的问题：
- 当他没有做任何改变而只需要更新？
当没有改变任何东西并且拉动时，git会将遥控器的历史视为正确的（因为有人显然--force - 被推，所以它必须是正确的。）所以它只会覆盖你的合作者的工作并使提交历史记录与远程服务器上的历史记录匹配。它会显示一个额外的消息，如force update，就像你强迫推送一样。
请注意，旧的提交实际上不会被删除 - 只是“隐藏”，因为它们与提交图的其余部分取消链接。因此，如果您突然需要再次访问“已删除”提交，那么只要您在某处拥有丢失提交的SHA哈希，就可能实现。 git垃圾清理程序在存储库上执行一定量的操作后删除无法访问的对象。
- 当他做了一些改变，并且在做出更新之前想要更新？
这显然是最糟糕的情况。无论如何，通过提交更改，确保您拥有所有更改和分支的备份副本（即使您之后要应用它们！），创建一个临时的，新的
git add . ; git commit -am "Describe all my changes here" ; git branch backup
现在您的更改已安全地存储在备份分支中，您可以再次删除提交。
git reset --hard HEAD~
然后拉出当前分支
git pull
这应该在没有任何合并冲突的情况下工作，因为它基本上代表情况＃1，其中没有进行任何更改，它只会使本地历史记录与远程历史记录匹配。现在，您可以通过再次应用更改（= backup分支上的最新提交）再次应用更改。
git cherry-pick backup
显然，当远程存储库更新了相同的代码行时，这可能会导致合并冲突。如果没有冲突，则可以删除backup分支。您的存储库是最新的，您的更改将应用于其上。
但是再一次，尝试避免这些情况。在合并之前在单独的功能分支中进行压缩/变基，或者让它们在合并之后保持原样。