在某些情况下，我有一个使用markdown文件保存的日志，使用OneDrive在设备之间同步。因为OneDrive有时会在文件冲突方面做一些愚蠢的事情，我用一个脚本将日志备份到git，该脚本每5分钟推送一次备份提交。为了防止提交数量增长太多，每一两周我都会把所有的自动提交压缩到一个快照提交中。还要注意的是，除了master，我没有任何分支，所有的事情都发生在这一个分支上。
所以目前我的提交历史看起来像snapshot1，snapshot2，. snapshotX，autocommit 1，autocommit 2，. autocommit Y.我希望它是snapshot1. snapshotX +1，所以我开始做我通常的git rebase --root -i例程，然后标记所有的自动提交为squash。但是在rebase期间，我得到了大量的合并冲突。不知道为什么会发生这种情况，这以前没有发生过。我猜是在某个地方，OneDrive做了一些奇怪的事情，我必须提交更改，也许我有一个合并冲突，我手动处理了一会儿，我不记得了。
我想要的是，无论我的存储库的当前状态是什么，现在都变成了快照X+1，并且自上一个快照以来的所有自动提交都被压缩到快照X+1中（即，我不关心文件在此期间如何变化，只要最终结果是存储库的当前状态）。
我不想手动解决合并冲突（我实际上尝试过这种方法，在某些时候文件变得混乱，并且rebase后它不能反映repo的当前状态）。
1条答案
按热度按时间9udxz4iz1#
至于 * 为什么 * 你会得到合并冲突，这可能是原因：
也许我有一个合并冲突，我手动处理了一会儿，我不记得了。
看起来你的历史记录是一堆你希望保留的“快照”提交，后面是一堆你希望压缩的自动提交。你可能只是把基准往回调得太远了，一直到root而不是最后一次好的提交。例如：
字符串
这应该可以解决这个问题，或者，假设你想压缩的提交都是你图中最新的提交（也就是说，在它们之后没有你想作为单独提交保留的提交），另一种更有效的压缩方法是：
型
这将把
snapshot-X之后的所有提交压缩为一次提交，而不会像交互式变基那样一次提交一次。