我布吉岛啊，我看到雕大就点进来了

是不是可以理解为 ： 如何将多次 commit 合成一个 commit ？ 给你个教程，可以帮到你。 https://blog.share888.top/note/efficiency/gitHub/04-IDEA%E6%93%8D%E4%BD%9CGit.html#%E5%A6%82%E4%BD%95%E5%B0%86%E5%A4%9A%E6%AC%A1commit%E5%90%88%E6%88%90%E4%B8%80%E4%B8%AA

@geelaw #7 谢谢，你这个看起来目前是最有可行性的 但是有点疑问，《那么需要变成 tree B 》这个 B 是从哪来的，我看后面又要基于这个运算输出 hash 是 B ，怎么感觉陷入循环了

简单粗暴，复制粘贴大法： 1 、把现在的代码复制一份到新的文件夹 2 、找到 C1 前面的那个记录点，分出一个新分支 new_main ，切换到这个分支 3 、把第一步的代码复制过来，覆盖掉当前文件夹的内容 3.1 、还可以先删掉当前目录的代码文件，然后把第一步的代码复制过来 4 、git 命令新增文件（如果有新文件的话），然后 git 再提交 5 、旧的 main 分支改名叫 old_main ，然后 new_main 改成 main 6 、old_main 想保留就保留，想删除就删除，怎么方便怎么来

@geelaw #9 > 因为一条直线的 rebase 是不会失败的 是的，这个 main 分支曾经接受过少量其他分支的合并，它并不是线性的 感觉越来越复杂了，就是我希望更改后的 c1..c200 变成初始提交，其余的修改正常应用在上面 这个实现的复杂度具体在哪呢？

@cnbatch #13 旧代码可以直接 reset 到 c1 ，然后保留旧代码的.git ，其他文件删除换成最新代码，再 commit

@lisongeee #14 写了一个例子： https://gist.github.com/GeeLaw/7f40471442544a3aff166298cd462de0 如果 c201 到 c1000 “触及” c200 “以前” 的历史，那么 migrate 之后的效果是仍然会牵连到以前的历史，如果不触及，那么 c200 到 c1000 会变成 c'200 到 c'1000 且不触及 c1 到 c1000 。

@geelaw 感谢感谢，我参考参考

试试 git rebase --rebase-merge

@lisongeee #14 >其余的修改正常应用在上面 >这个实现的复杂度具体在哪呢？ “这个实现的”复杂性在于您尝试绕远，每个 Git commit 里面存的是 snapshot 而不是 diff ，所以“应用” (apply diff) 是多此一举。简单的方法是直接画出新的 commit graph 并关联已经知道的 snapshots 。 问题本身的复杂性：如果 c201 是 c100 和 c200 合并而来，要如何定义新的 c'201 。想好这个问题之后，实现不困难，而且执行过程不需要人工干预。