Blog/source/_posts/2022/06/magit使用随记暨Emacs随记(3).md
2022-06-08 19:34:11 +08:00

6.1 KiB
Raw Blame History

author title date tags category
SouthFox Magit使用随记暨Emacs随记3 2022-06-08 14:38:26
Emacs
Git
技术

magit 是个好东西。

Magit 是一个 Emacs 的包,将一大堆长又长的 Git 指令封装成了按键操作,对于受够了了在终端下按够了 TAB 键的人来说,是一种解放,无怪 Magit 的评价在整个 Emacs 生态里评价那么好了。

Git

Magit 是建立在 Git 上的,意味着要使用得先对 Git 有一定了解,Pro Git 是一本不错的入门书,而且做为一本「开源」书籍,也很容易在网上找到可在线浏览的方式。

奇怪比喻

Git 的精髓在于它的设计,工作区、暂存区以及版本库,用 Git 进行工作一般如下所示(图出自 Pro Git

用小学生写作业做比喻的话,草稿纸即是工作区,做好相关计算后把结果誊抄到作业本上,作业本既是暂存区(IndexStage),最后确认无误后即可把作业本放入书包,书包既是版本库了。

Git 的设计给了使用者操作上的灵活,却也让人感到冗长,设置别名可以缓解这种情况,不过还是没有优化到单键操作的 Magit 偷懒偷得多。

Magit

一般流程

Doom Emacs 下,使用 SPC g g 即可选择一个 Git 仓库(如果已经打开了一个 Git 仓库的的文件即可直接打开当前仓库下的 Magit 界面)打开 Magit 界面。

Magit 界面下可以很方便看到工作区发生变动的文件Unstaged changes以及已经加入到暂存区的文件Staged changes

光标在某个文件上时,按下 TAB 即可展示文件的变动,按下回车即可直接跳转到文件进行编辑,按下 s 即可将文件暂存,对处于暂存区文件按下 u 即可取消暂存(SU 则是应用于全体文件)。忘掉 git add xxx 吧,谁会怀念它?

确认暂存区的改动后即可进行提交commit将其送入版本库了对应的快捷键是 c,对于很多复杂的 Git 操作附带了很多选项来完成,Magit 把能用的操作都罗列了出来,做到了看菜下饭。

对于提交commit 操作,其里面常用的有:

  • - s- S 附上签名消息或使用 GPG 进行签名认证。
  • c 进行 commit 操作,之后会打开一个新区域输入消息,输入完毕后用 C-c C-c 进行确认(C-c C-k 为取消提交)。
  • a 进行 --amend 操作,即为重新进行提交操作,适用于提交完了才发现漏掉了几个文件没有添加,或者提交信息写错了的情况。

实际用习惯了之后基本就是无脑操作了,比如使用 p p 快捷键,即可直接推送到默认的分支上,如果要进行其他操作比如推送到其他分支上,那么按一下 p 之后再看信息提示进行操作也不会太难。

对于更多操作,按下 ? 即可进入提示菜单,或是翻阅 Magit手册了解更多操作。

从实战到跑路

现在来说说我拿 Magit 实际干过的事吧,

首先是要心动,看上了其他分支的功能,打算抄抄作业,那么第一件事就是把对方仓库克隆下来。在 Magit 界面按下 M 即可进入 Remote 界面,按下 a 添加,输入名称以及仓库地址来添加一个 Remote

接着开始检索对方仓库的提交,检出自己需要的提交,按下 l 打开 log 界面,按下 - F 搜索提交消息,之后输入想检索的提交消息,例如 exclusive list,再按下 o 选择搜索其他other分支的历史记录选择之前添加的 Remote 仓库的分支。

可以看到搜索出了相关的三条结果,从最旧的开始合并,将光标移动到最旧的提交,按下 A A 进行一次 cherry-pick

啊啊啊……!一大堆冲突,毕竟这次的提交很老旧了,是三年前的提交,发生变化很正常……

感叹一句没有银弹,Git 对于冲突也从不僭越,会去自作主张搞定。所以只能自己上了,对于这种老旧的提交,可以前去 GitHub 的那次提交消息里查看改动了哪些文件,再前去最新版本文件下仔细比对最新的样子是什么。当然 Magit 同时也提供了一个命令 magit-log-buffer-fileSPC g L)查看当前文件下有那些提交,

检出更改

不过用这种方式查看双方提交记录的话,得先 Stash 修改再切换到对方分支查看历史记录又切换回来,感觉挺麻烦……所以我就先用 GitHub 查看历史了,或许有更快速方便的方法?

总之,确定该怎样合并后即可进入 Unstaged changes 上的任一文件按下 E 打开 Ediff 选单,再按下 m 解决冲突。

进入冲突选单后,用 n 键跳转到下一冲突处(p 为上一个),接着按下 ab 选择保留那一方的修改,这次的提交要结合两者,所以首先选择一方,然后用 SPC w k 将焦点移动到上方文件编辑区进行编辑,编辑完后再用 SPC w j 将焦点移回 Ediff 区。处理完全部冲突后,按下 q 退出,再处理其他文件的冲突。

处理完全部冲突后,按下 c c 进行一次提交,之后按下 p p 推送到 GitHub 上,祈祷部署能够成功吧!

如果想要合并的提交不是那么久远的话,可以用 Y 按键对应的 Cherries 操作来检出自己想要的提交,虽然我没用过(