到目前为止，我一直在做交互式 git rebase 相当频繁的工作：未推送的工作，或者我确信我是唯一一个工作的推送的工作。
我知道当涉及到协作工作时，压缩提交和整体重写历史可能会很棘手。
尽可能减少疼痛的最佳做法是什么？
如果我 squash 一些提交并 push，当他 pull 时，repo 在同事的站上会是什么样子？
我知道重写历史的概念是一场永无止境的辩论，但在这里我只是在寻找一种技术解决方案来处理这个问题。
尽可能减少疼痛的最佳做法是什么？
最好的做法是避免它。
正如 ElpieKay 所建议的那样，拥有一个“发布分支”是一个很好的做法，其中历史是安全的并且事情是稳定的，但也有一个“开发/功能分支”，你可以在其中做任何你想做的事情，直到你将它们合并/变基到再次稳定您的主分支。
要回答您的问题：
- 当他没有做任何改变，只需要更新？
当没有更改任何内容并拉取时，git 会将遥控器的历史记录作为正确的历史记录（因为显然有人--force-push，所以它必须是正确的。）所以它只会覆盖您的协作者的工作并使提交历史记录与历史记录匹配在远程服务器上。它将显示附加消息，就像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分支。您的存储库是最新的，您的更改将应用在它之上。
但同样，尽量避免这些情况。在合并之前在单独的功能分支中压缩/rebase，或者让提交在合并后保持原样。