场景是这样的

1. 原始文件 A
2. 对 A 修改了第 2-10 行，90-100 行，并提交。
3. 中间又有若干个提交，单独或一起修改 2-美国服务器10 和 90-100 行。

现在我想保留 2-10 行的修改，让 90-100 行回到原始状态，而且让这几行的最后提交仍然原作者。

这要怎么做到？我们是代码谁修改谁负责，所以不想留下自己的名字。。。

这明明是修改的，你为啥不写名字。

只能把 3 过程的所有提交都撤销，直接 git reset 到 2 的状态(提前备份当前的代码)，然后重新做 3 过程对其它代码的修改

从原始分支上重新拉一个分支出来，然后把你现在的分支上所有的 commit 同时 squash merge 上去。

同意 L90-L100 的行为，然后一搞变成原作者把行为改回去了，岂不是锅从天上来？
当然，不爽可以把这几行重写一遍。
还有一种方法，就是干脆找原作者把 L90-L100 改回去。

第 90-100 行我没改动啊，恢复回原来的样子了，自然最后提交者的名字也不想变成我。

那把这些提交都当成是在我本地分支上进行的，没有合并到主分支里。所以暂且认为，没有其他地方依赖 90-100 行的变动，只是想改回去。

那就是纯手工操作。。。即使 2-10 行和 90-100 行的改动各自独立，不会发生冲突，也没有更智能的办法了么。。。

那把这个分支当作是我本地的 develop 分支。我做了好多个提交后，后悔了，想把 90-100 行改回原样。

那你就不要改动这一处，git 会留痕的，你没改动他自然不会记录。

搞笑 恢复等于没修改？ 把补丁给恢复没了找谁去？

rebase -i 到你第二步的开头
所有 commit 重新 edit
只修改 2-10 行
这样后面的历史里 90-100 就完全不会有修改的痕迹

这是本地开发分支，全部的提交都是我做的。我改了这几行后，后悔了，想改回原样。这样说你能理解吧？

rebase 是可以。但如果第二步后有很多提交，那就需要一步步解冲突，会很痛苦。。。
不过貌似没有啥好办法。

squash merge 会把很多提交都合并成一个吧。可能丢一些提交信息，不过这个貌似是最方便的办法了。多谢老哥。

你要一次性改掉一堆历史还能咋 要不就先 squash

就是想问问有没有更黑科技的办法