July 10, 2024
By: Kevin

Magit使用指南

  1. f a 获取所有远程提交(fetch all)
  2. r u 基于上游的rebase
  3. b s 分支分离(branch spin-off)
  4. b c 创建分支(create branch)
  5. P ... 推送(push)
  6. c ... 提交(commit)
  7. l l 日志(log)
  8. y 分支查看(show)
  9. l r 引用日志(reflog)
  10. r s 部分rebase
  11. r i 交互式(interactive rebase)
  12. 最后
  13. 参考资料

magit

在Emacs中的所有扩展包中, Magit可能是节省我时间最多的, 同时也进一步加深了我对git的理解.

本文列出了每天都会用到的Magit命令.

f a 获取所有远程提交(fetch all)

通常是开始一天的方式. 拉取所有远程分支的更新(提交), 不涉及到合并, 所以完全不影响本地的分支.

r u 基于上游的rebase

上游(upstream)通常指的是本地branch对应的远端branch, 对于master上游是origin/master.

如果fetch-all发的本地分支与上游不同步, 这将快速使它们同步.

如果不想对这个分支进行rebase, 我可以选择 m m 合并. 由于fetch-all已经完成了所有网络操作, merge和rebase都非常快.

b s 分支分离(branch spin-off)

创建并checkout一个新分支, 同时带过来任何正在进行的(可能已提交的)更改. 它的主要卖点是自动撤销前一个分支上(尚未提交到上游)的提交.

如果在开始工作之前忘了从master分支分离, 这非常有用.

b c 创建分支(create branch)

当需要一个新的工作分支时, 不需要切换到master, 拉取origin, 然后再分离, 只需直接从origin/master开始 b c (我的本地master是否过时并不重要).

P ... 推送(push)

P p 在98%的情形下够用了, 但P t对应特定tag的push, 如果已经推到了远端 -f 给我们提供了一个最后修改(在别人推送之前)的机会.

c ... 提交(commit)

c c 是基础. 但是要知道commit推送之前是非常灵活的. c w (快速修正commit msg)或 c e (将更多更改加入最后一次commit)会极大降低提交的负担.

l l 日志(log)

l l 是日常, 但是需要知道两个l之间还有很多的选项.

当输入第一个 l 的时候, 会有很多选项可供选择, 比如只看特定文件的修改记录, 搜索包含特定文字的commit msg, 或者diff包含特定内容的commit等.

y 分支查看(show)

简洁地列出所有refs. 非常适合找到并删除旧分支(包括本地和远程). 如果试图删除一个未合并的分支, Magit会给出警告.

l r 引用日志(reflog)

不知道什么是ref log? 想抢救下丢失的提交, 是时候了解一下了.

r s 部分rebase

在工作中, 当我需要紧急修复某些问题时, 我会从origin/production而不是origin/master分支离开.

有时候我会忘了这么做, 提交了我的热修补, 然后才意识到我的分支现在比生产环境领先了100个提交.

部分rebase可以在一瞬间解决这个问题, 只把我想要的提交放在另一个分支上.

r i 交互式(interactive rebase)

我得承认, 几年前尝试这个功能时有点害怕. 我也不知道它究竟在干嘛, 但那个"交互式" 菜单选项一直看起来很高级.

这里解释它, 我觉得我会剥夺你的发现乐趣, 我只能将其描述为"无所不能的篡改历史".

所有这些武器结合成一些快速而强大的git操控.

最后

大概在10年前, "你用什么工具管理代码版本"是个常规问题. 今天的git已经让这个问题成为历史.

git在强大的同时, 有它内在的复杂性, 这是我们必须面对的.

"学会这几个命令就行了"从来不是个好建议. 系统学习, 深入使用, 融入日常才是.

Magit提供方便的操作的同时, 把更高级的一些功能放置其侧, 等待你的发现.

更重要的是, 在编辑器处理代码历史中顺畅且自然. 编辑器是我操作源代码的地方, 我应该在那里更改分支, 而不是切换到终端.

参考资料

篇幅有限, reset, cherry-pick 等等操作不在此一一展开了. 更多请参考

magit 官方文档

Tags: git