magit 太好用了,没用的朋友一定要试试

cli git不卡

哈哈行吧我猜的,不过大部分项目 magit 应该都足够流畅了,我现在在做的项目就千级别的 commit 数量然后几十个 branch,不卡

相关的issue Improve performance · Issue #2982 · magit/magit (github.com)

目前只能尽量dispatch,不过即使是dispatch依然有时候比较慢

@Vitaly 话说llvm project上使用magit会觉得magit慢吗

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 个赞

你这个更好,对这种针对性打补丁的场景而言