我正在学习 git，之前使用过 CVS ...这是我遇到的情况，如果有人有任何关于如何学习这一点的提示。
我创建了一个错误修复分支(bug435)。我进行了 4 次提交，然后推送到 github(我们将其用于我们的集中存储库)。我看到了 PR(还在学习 PR 过程)，发现它生成的 diff 非常困惑，审阅者必须逐行费力地检查(在这种情况下，创建一个新函数，我调整了它)经过多次提交)。我希望它看起来只是一个附加项，将整个功能整合在一起。
所以我尝试了“git rebase -i HEAD~4”(有 4 次提交)，并指定了要压缩的提交。这似乎有效，并且我的本地存储库上的“git log”已被修改。但在远程存储库(在 github 本身上)，更改历史记录并没有反射(reflect)我的 rebase。所以我推断我需要进行“git Push”。 “git Push”给了我一条消息，说我需要一个“git pull”，所以我这样做了。但是——这产生了 merge ，这让我感到惊讶。
仍然对 merge 感到疑惑，我继续使用“git Push”。我在 github 上检查了 bug345 的分支历史记录，一切看起来都不错——我认为这是个好消息，rebase 成功了!我创建了一个新的 PR —— 但它们包含了我的原始提交、一个 merge 提交以及来 self 的 rebase 的两个新提交。它生成了 3 个额外的提交:) 不是我所期望的。
我在整个过程中的推理 - 我相信我可以进行 rebase ，基本上将分支 HEAD 指针更改回我的第一个更改所在的位置，在一次提交中应用更改(重写历史记录)，然后将此分支推送到远程存储库，这将仅反射(reflect)重新调整基准的更改。但我没有预料到的是，存在一次 merge (一次额外的提交)，并且远程仓库分支仍然“记住”了我的旧提交。
有关于幕后发生的事情的任何指示或提示吗？ :)
谢谢!
最佳答案
你只是在重写你自己的历史。远程历史不同。
根据定义，git pull 将获取远程更改并尝试 merge 。
您必须让远程存储库忘记历史记录或接受它被重写，例如使用 -f(强制)选项。或者干脆删除旧的 PR 并创建一个具有正确历史记录的新 PR。
关于git rebase -i 和干净的提交，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23770378/