cli git不卡
哈哈行吧我猜的，不过大部分项目 magit 应该都足够流畅了，我现在在做的项目就千级别的 commit 数量然后几十个 branch，不卡
相关的issue Improve performance · Issue #2982 · magit/magit (github.com)
目前只能尽量dispatch，不过即使是dispatch依然有时候比较慢
windows 上确实慢.
eaf-git 可以做到 100 万commit 搜索不卡。
我不用magit哈哈哈，之前试过，挺好用的，但我用命令行习惯了
1 个赞
其实是Windows上git慢
更新：
今天遇到一个使用需求。过去两周都在 dev 分支上开发新的 feature +测试 UT + 一些杂七杂八的修改。然后我就积累了十几个小 commits。但是由于这是我的个人开发分支，commit 的时候内容逻辑性不强，比如测试 ut 遇到 bug 就小改一下，所以这些 commits 聚合后的改动是 ok 的，但是单独看，很凌乱，需要归类合并、整理。
看起来就是我需要先在 main 分支上 checkout 一个 base 分支（假设叫 dev-base)，然后逻辑上对这些 diff 做一个归类合并（比如 feature 单独一个 commit，bug fix 一个，ut 内容一个，一共3个 commits），最后在 dev-base 上依次生成然后提交即可。
看起来很简单，似乎只用到 magit 一些基础操作，但是后面才是重点。比如我分出来的3个 commits 如下：
- A: add new feature.
- B: add related test case.
- C: bug fix for the new feature.
假如我一不小心漏了一个 test case，那但是 ABC 都已经添加好了咋办？或者说，别人给你 review 的时候，需要对 A 和 B 进行补充修改，那咋办？
最开始我用了一种很粗暴的方法：本地新开一个分支，按顺序从 dev_base cherry-pick 这些 commit，如果当前 commit 有要改的，直接 fix 掉。这也是一种方法，也不是特别费力，具体操作如下：用 b c 新开一个分支，然后 A A 然后输入需要 pick 的commit-id 即可。
但是还有一种更简单的，可以直接对 old commit（A、B） 修改的方法：输入 r m ，此时会跳出 commit history，比如我要改 A，就在 A 那行 C-c C-c，此时会跳转回 status buffer，且 A 变成了临时的 HEAD，并且他显示了后续将要 apply 的 commits：
此时只需要用往常普通的 amend 操作修改 HEAD 即可。最后输入 r r 表示继续 rebase，一般没有 conflict 的话是很丝滑的 git finished.
总结：第二种方法好处是 edit-in-place，心智负担小，尽管第一次了解并学习这种方法需要一点点时间。
更新：
经楼下同学的提醒，instant fixup 对我这种场景更有效、简洁：
“Instant fixup” (c F) is essentially the same thing as “extend HEAD” (c e), except that it works for any commit, not just HEAD.
git 有一个功能叫 fixup
git commit --fixup <sha>
可以生成一条专门用来bugfix的commit，之后可以方便地知道如何rebase
magit 的快捷键是 c f 生成一条fixup的commit，c F 生成一条 fixup的 commit 并自动autosquash
8 个赞
你这个更好，对这种针对性打补丁的场景而言