Git 你需要一个牛逼的 GUI。光用命令行，几乎干不了什么复杂的事情。

大三开始学 Ruby，最近也开始看精华帖了，我是上下班的路上看的，刚看完一半，楼主收集的很棒

哈，现在用 vscode 还是很爽的

你说反了吧...

啥？

很有意义！！ 感谢分享！！

这波操作 6

没用过 git gui

不这么放，我都不知道 Ruby China 有这么多精品内容了

其实个人觉得 ruby china 的维基很多都可以更新了 链接也有一些是损坏的。可不可以考虑放开 ruby china wiki 的维护权？这样大家都可以贡献一份力量，还能把平时论坛好的资料都放在 ruby china 的 wiki 上

还是感觉大佬们分享了这么多的内容

就用 GitHub 协作挺好的。

是啊，整理的时候发现好多的帖子和回复都有你。也非常感谢你分享的内容

写得很不错！很真诚哈

精品常在

啥 GUI？真的没用过，求推荐

再加上高手对战帖

不能给这篇加精啊，会 stack level too deep 的！！！@Rei

SourceTree

谢谢 @danielglh 告诉我用 tig, @dfguo 教我 git rebase -i

good job!

说反了什么？

请问你想表达什么？

可以尝试一下 SmartGit，边用边学可以让你学会很多 Git 的使用技巧。

大一开始学习 Ruby➡️现在大四即将毕业，没有从事 Ruby 方向的工作，但对 Ruby 不离不弃 discord：laxse#5627 欢迎添加好友 交流分享

Awesome job! 荣幸文章能被收录，一直觉得 Ruby-China 是技术讨论氛围最好的中文技术社区！

整理的好棒！

楼主厉害～

第一次听说 git 命令行几乎干不了复杂的事情....

记住了：GUI 能干的，命令行也能干，GUI 不能干的，命令行也能干

记住了，学好语文很重要。

我说的是 用命令行，几乎干不了什么复杂的事情，主语是人，说的是人类的能力无法达到充分利用命令行赋予的功能。

你说的是 命令行也能干，主语是命令行。命令行当然都能干，GUI 就是代替人类去调用命令行的。

回答牛头不对马嘴，还说什么记住，记个蛋蛋。请好好学习语文，谢谢。

另外，GUI 能干的，命令行不能干，命令行能干的，GUI 不能干，他们是互相对接的。刀柄能让你握，菜刀不能让你握。菜刀能切肉，刀柄不能让你切肉。

握着一把没有刀柄的菜刀的人，何必去鄙视那些用着有刀柄的菜刀的人呢。

我也是第一次听说，不知道你是哪里听来的。

git + tig + sublime/atom/任意编辑器，可以实现绝大部分需求。 git 需要的不是 GUI，而是使用者的细心研究。

你这智商已经基本告别 Git 了，来来来，说一个你认为命令行干不了的复杂的事情

楼主有点暴躁啊~

Git 从来不用 GUI, GUI 能做到的，命令行都能做到. 相反，我见过很多使用 GUI 的，在我看来，他们使用 Git 的方式跟 SVN 一样，根本不理解 Git 的工作模式，很多 Git 非常牛叉的特性完全不会用，暴殄天物。

是啊你说得对，我智商不行。

我经常做的事情：Git Flow 新建 Feature 分支以后，日常开发频繁提交，一个分支开发完成或者到一个阶段以后，整理分支提交记录，把涉及多于一个功能的提交拆分，按照功能和页面，代码和测试分开归类重新合并成多个大提交，每个提交测试跑通保证可以单独回滚，最后清理完分支以后从主线 Rebase 更新然后再 Merge 回主线。

我不知道你平时是怎么处理这样复杂的操作的，但是我用 GUI 操作的速度起码可以省掉我用 interactive rebase 至少 80% 的时间。可能你手速飞快，每个提交 rebase 单独编辑 stage index 再分开 commit 然后再重新排序提交再 squash commits 可以一气呵成，然而我做不到。特别是，GUI 可视化操作只要点几下鼠标就能可视化编辑 stage index 就能可视化重排 commits 的，我为什么要憋屈的去 vim 和 shell 来回切？我为什么要浪费我的宝贵时间干这些我不需要干的事情？

还有，能不要再瞎瘠薄捏造我没说过的话吗？

我智商捉急，刚刚才想起 git 的 rebase 也是个语法糖，说不定大神你是用更底层的 git commit -F 来重写提交链的，如果我低估了你的能力，那我十分抱歉。

不错啊，你们这样 commit 记录超整洁的

楼主运气真好，还有身边的老师，学长搞 Rails...我就是因为某大我 2 届的朋友跟我安利 Ruby，然后开始学。

先发现入门难度好像挺大的，对于一个小白。后来发现了 Rails Tutorial，用来入门...前后仔仔细细刷了 3 遍发现自己入门了，因为感觉这已是对于小白最好的辅助材料了....之后找到个实习...上路了

我们项目归我管了以后，我就要求每个 Feature 的提交记录都要干干净净，方便调试回滚，代码 Merge 前都必须要 Peer Review 过。以前招了一堆外国人，佛性提交，坚持只用命令行，但是又只会 commit pull push merge，推上来的提交乱七八糟，各种名为 root@ubuntu 的用户穿插其中，分支纵横交错，Merge 节点还偷偷藏着几个冲突处理更改，回头做 Blame 和 Rollback 的时候心态都崩了。

我觉得工具不是最主要的，主要还是你说的每一个 commit 记录是否能表达清楚做了什么。顺便也是给项目做很好的注释，这样子项目接手过来也能够通过 blame 知道每行代码的功能和作用。而且出问题的时候也能够责任到人。

工具不是最主要的，但是有一个趁手的工具可以极大地提高效率。

为什么我们会用 Ruby on Rails？难道就不能用 C 或者汇编写网站吗？当然可以，但是用更趁手的工具可以提高开发效率，减少失误。我一开始推 GUI 也是同样的道理。古人写代码，起手就是汇编，纸带打洞写代码，那是因为他们没有条件用高级工具。现在学编程，谁起手从汇编开始学起的？

我一开始就说，光用命令行，干不了多少复杂的东西。类比到编程也一样，光用 C，写不了多少大型网站。这当然不是说 C 语言写不了大型网站，C 当然能写，人家世界级大师水平的大佬，泡在牛逼公司里拿着高薪用 C 语言写核心业务，当然可以。我们这些普通人呢，为什么不去用 PHP Python Ruby Go，而要跑去死抠内存指针和汇编优化呢。

更理想的情况是，我很多 Git 技巧就是 GUI 教的。写商业版本 Git GUI 的人，自己是早就吃透 VCS 的方方面面，你去用这些 GUI，然后看他们是怎么一阵蛇皮走位骚操作的，再吸收回来为自己所用，这才是正确的学习方法。我要是丢给你一个 Git Manual，你去看一年都不一定能想通为什么 Git rebase 是 Git commit --author --date -F 的一个语法糖。

我进公司之前，他们是这么用 Git 的：

后来他们觉得单线程开发受不了了，开始用分支，那时候记录是这样的：

而现在我的要求是这样的：

其中一个分支是我带的新人写的，他之前是客服部的，说想来做开发，我带他学了 Ruby 和 Rails，教了他怎么用 Git GUI，大概一两个月就能按照要求完成任务了。而之前的那堆蛇皮走线，是好几位 Git 用了两三年的人搞出来的。

你说我为什么要推 GUI？

tig 算 gui 么

你所指的是一些人因为能力有限，使用 git 的命令行干不了什么复杂的事情，我们想表达的是，我们使用 git 命令行完成了一切复杂的事情。而你举的这个例子只是一个团队约定和流程的问题，总结起来还是某些人会不会用命令行、以及 git 的命令行。你说 git GUI 更适合新手上手做实际的东西，没有人会和你争论，这是事实，但是你要是把 git CLI 说的一无是处，那请问，GUI 是怎么完成复杂的操作的，不是调用 Git CLI 吗？

你这个挺好的，话说 Git 的 GUI 我比较推荐 SourceTree，之前带新人学 Git，用 SourceTree 就好了，掌握思想之后可以把一些操作迁移到命令行提高效率

你说的就是我一开始说的意思，麻烦你爬一下帖子可以吗？我不想一次又一次地纠正语文问题。

tig 我没用过，看了截图，我觉得应该是处于 GUI 和 CLI 之间的位置。也有人管这样的程序叫做 CUI。

请问你最后的图每次合并分支都是通过 rebase 吗？能分享下你们是按照怎么样的流程走的呢？

一般每次 develop 上有新的提交以后，分支都要阶段性地 rebase 到 develop HEAD，保证正在修改的程序和已经提交定稿的程序没有冲突。develop 上只提交一些比较简单、浅显的改动，比如修改日志格式、更新 gem 版本等等不会有太大影响的东西。分支则是先规划好大的模块（通常是一个或者半个功能），然后里面有多个小任务，一般一个小任务（通常是一张页面和一套 CRUD）一两个提交，相关的提交整理到相邻位置，或者如果量不大的话就直接 Squash 掉。页面我一般是前端后台代码一个提交，然后 RSpec 一个单独提交。如果是 lib 业务模块的话，则是一小块业务逻辑功能一个提交，可以参考下图：

有时候会遇到一个功能做不完的情况，比如我们曾经出现过一个想上一个大功能，但是最后因为人力限制或者需求不大而腰斩的情况，那就把要留下的功能整理到相邻位置，然后 Merge 回主线；不要的部分撇开，单独留一个尾巴分支挂在外面，每隔一两个月 Rebase 刷新一下，等以后功能重开的时候可以继续工作。

我想 @msg7086 这里的要点估计是，使用好用的 GUI 可以“更容易”看到当前整个 repo 的进度（这个也同样依赖于使用者或者 GUI 每次提交前 fetch/pull 要提交到的 branch 的所有最新的 commits），这样子能够尽量避免“蛇皮走线”的发生。 但其实这就像前面的兄弟说的那样，主要还是个流程控制的管理问题。

我不完全是这个意思，但是我觉得该说的我已经说了，能理解的人也应该已经理解了，不能理解的人不管说什么大概也不会理解，所以我不想再翻来覆去重复那些话了。如果大家想继续讨论的话当然没问题。如果有人还想杠的话我就直接 Block 得了。时间宝贵，不想浪费在无谓的争吵上。

我的观点是任何一个对 Git 有比较复杂需求的人都应该用 GUI 辅助而不是裸撸 CLI，从来不会犯错而且手速飞快 or 闲得没事干的人除外。

困了，睡了。

emacs 的 magit 算 git 的 GUI 吗？

嗯，我只是针对那个“蛇皮走线”来说。不可否认，你提到的 GUI 的好处，也是不难理解的。我想最大的好处应该是直观。然后就是好的 GUI 应该包含一些最佳实践，类似你说的语法糖那样的说法（发现 Ruby 社区大家都很喜欢用“语法糖”这个词），比如对一些常用操作的组合封装，使之成为简单的操作、按钮、菜单，不过我想这也需要 GUI 良好的设计支持，特别是中间某些步骤涉及到网络交互的时候，就像是在处理数据库事务那样，如果 GUI 设计没有做好这些的话，我想有时候也可能会一团糟，因为网络出问题或者服务器开小差那是常有的事情。使用 CLI 去实现一个比较复杂的功能的时候，比如把很多提交压缩成一个大的提交，或者 cherry-pick 很多 commits 等，可能需要多步操作，命令行输入出错那也是常有的事情，这样子的确费时费力，而且也容易出错。理想情况下应该是两者都熟悉，简单的操作使用哪个都无所谓，哪个自己使用更快用哪个，复杂的操作使用更直观更容易的，不过出了问题，估计还是得一步一步来解决，或者干脆整个 hard reset，然后再从垃圾堆里 cherry-pick 回重要的 commits 😓

git 蛇皮走位很正常。。。

花在 GIT 上的时间真的没什么用。。。用不明白命令行不如用 GUI(针对新人)

推荐 gitkraken 做的比 sourcetree 早https://www.gitkraken.com/

算吧，因为我现在已经不怎么会用命令行了。。。

理解了一下，我的理解是要做出这种提交历史，就是在分支开发的时候时不时地 rebase 到 develop，分支内部 squash 整理，最后合并分支用 merge，是这样吗？

是这样的。时不时这个间隔可以是一两天也可以是一两周，主要是保证迭代开发的基是比较新的，避免开发完成了要合并的时候才发现冲突。分支内部除了要 squash 以外，也可能会 split，比如一个 WIP 提交里包含两三处更改，可能会先 split 成多个提交，然后再归类合并。

这个一定要赞

很好奇楼主加入的是哪个大学的怎样一个社团，从大一开始就安排这些学习任务，并且有毕业的学长带 …… 另外求问截图中使用的任务和 TODO 管理服务是？

杭州的一个学校，主要是学长很有想法和能力；工具的话叫做 trello

整理的简直了... 赞

感谢楼主分享，很不错的文章。刚入行，想自学一些东西来提升自己，请问大家有什么建议？如果可以的话，希望加个微信 306465105，期待回复

能有一个清晰的 git log 是好的。但是，和 gui 与否没关系。

你说的这些操作无非就是 rebase add commit reset checkout 就可以完成了。"光用命令行，几乎干不了什么复杂的事情" 太偏见了。

A：从中国横渡太平洋到达美国，不借助交通工具几乎无法到达。

B：你说的这个，无非就是走到岸边然后游泳就可以完成了。说不借助交通工具就几乎无法到达，太偏见了。

我证明@wpzero 实际工作中真的只用命令行，为了装其实真的也是很拼的。。。

@ericguo

这个帖子必须支持！

咳咳，我觉得你说的的确是反的，只有 UI 做不到的，没有 命令行做不到的，UI 都是调用命令行。

下面是普通的 git 命令行输出，不是一样有你截图的效果？(添加 --graph 参数即可)

 1  *   16299e9 - (HEAD -> develop, origin/develop, origin/HEAD) Merge branch 'release/1.6.0' into 'develop'(29 hours ago,tracy)
 2  |\
 3  | * 38cd519 - (origin/release/1.6.0, release/1.6.0) 🐛 修复feed物理删除引发的问题(29 hours ago,tracy)
 4  | * b890266 - Fix clazz.grade bug(30 hours ago,Billy.Zheng)
 5  |/
 6  * c9efa4f - update graphql_controller(31 hours ago,Billy.Zheng)
 7  * 54142be - refactor graphiql_basic_auth(31 hours ago,Billy.Zheng)
 8  *   1fd379a - Merge branch 'feature/update_1.8' into 'develop'(31 hours ago,Billy.Zheng)
 9  |\
10  | * 2c408a8 - (origin/feature/update_1.8) comment test(31 hours ago,Billy.Zheng)
11  | * 6417971 - refactor feed_connection(31 hours ago,Billy.Zheng)
12  | * 32e8141 - Fix test(31 hours ago,Billy.Zheng)
13  | * 738b3be - Add schema.grahpql(32 hours ago,Billy.Zheng)
14  | * 74a538a - delete recruit_image api(32 hours ago,Billy.Zheng)
15  | * 0aaa961 - delete delete_image api(32 hours ago,Billy.Zheng)
16  | * 8ee8140 - update fields to 1.8(32 hours ago,Billy.Zheng)
17  | * 54b3428 - fix query name(32 hours ago,Billy.Zheng)
18  | * b7a59f9 - remove all require in graph folder(32 hours ago,Billy.Zheng)
19  | * 19553b6 - replace @context to context(32 hours ago,Billy.Zheng)
20  | * 456cfa6 - replace @object to object(33 hours ago,Billy.Zheng)
21  | * 03789db - remove loaders require(33 hours ago,Billy.Zheng)
22  | * 38457a6 - update enums(33 hours ago,Billy.Zheng)
23  | * d8fab81 - move global constant to initializer(33 hours ago,Billy.Zheng)
24  | * e909d23 - Update sequel config(33 hours ago,Billy.Zheng)
25  |/
26  *   f508b67 - Merge branch 'release/1.5.0' into develop(33 hours ago,Billy.Zheng)

我说的是 用命令行，几乎干不了什么复杂的事情，主语是人，说的是人类的能力无法达到充分利用命令行赋予的功能。

感觉这个还是反的，最复杂的事情，都一定要通过命令行来自动化，如果 git 的标准命令你觉得有点麻烦，你可以写个 bash wrap 起来，我自己写了大把的类似的脚本，只是为了让我操作 git 时提供便利，这就是为什么有了 git, 还有 git-flow, 有个 docker, 还有 docker-compose.

客观而不带任何偏见的讲，如果你的话是对的，Linux/BSD/Unix 真的没有存在的必要了，每个人工作方式不一样，你喜欢 IDE, 习惯工具，却认为别人用命令行干不了复杂的事情，有点以偏概全了。

为了增加信服力 (不是我信口雌黄), 贴一下 git 相关的脚本目录：(虽然不是每个脚本都常用，其实就是心血来潮，写个脚本，当作笔记而已)

 abort*               cob@       fork*    gitb*                      gitdiff@                    gitll@                         gitv*           push*           skip*
 add*                 cofile*    fork1*   git-bcompare*              gitdiffc@                   gitls*                         gitzip@        'push!'@         stash*
 add_key_to_github*   com@       gc*      gitc*                      git-diff-wrapper*           gitls1@                        merge*          rebase*        'stash!'@
 anno*               'com!'@    'gc!'@    gitcat*                    git_find_big_files*         gitm*                          merged*         rebase_log*     stashp@
 clean*               commit*    gca@     git_clean_merged_branch*   git_find_blob_commit*       gitrm*                         merge_dev*      reflog*         submodule*
'clean!'@             cont*     'gca!'@   gitcp*                     git_find_dangling_object*   gits*                          merge_ours*     remote*         swap*
'clean!!'@            cor@       gcp*     gitd*                      git_find_delete_file*       gitsize*                       merge_theirs*   reset*          track*
 clean1@              cov@       gd@      gitd1@                     gitfsck*                    git_squash_branch_to_commit*   mergetool*     'reset!'*        unreset*
 co*                  drop*      gd1@     gitdc@                     github_create_repo          gitss*                         pop*            show*           up*
'co!'@                fetch*     gdc@     gitdd@                     gitinit*                    gitsub*                        pull*           shown*          upa@
 coa@                'fetch!'@   gg*      git_delete_big_files*      gitl*                       gittar*                        pullups*        show_restore*

再贴的你应该懂的最常见的命令：

function update_base () {
    branch=${1-develop}
    git checkout "$branch" &&
        git pull origin "$branch" --rebase &&
        git checkout - &&
        git rebase "$branch"
}

emacs 的 magit 算 git 的 GUI 吗？

这玩意儿超级强大的，因为太强大，所以我一直没敢用，还在用一个很老的包 (git-emacs) + 自己的 hack,

请问你最后的图每次合并分支都是通过 rebase 吗？能分享下你们是按照怎么样的流程走的呢？

这位小哥，我猜的没错的话， @msg7086 在合并代码前，会要求 feature 代码的开发者，做 rebase 然后重新强推一下。

假设，你要合并 feature/new_feature 到 dev 分支，你需要首先 checkout feature/new_feature 分支，然后运行 update_base dev(参见之前回帖写的那个函数), 解决冲突 (如果有), 然后强推 git push --force origin feature/new_feature

我不完全是这个意思，但是我觉得该说的我已经说了，能理解的人也应该已经理解了，不能理解的人不管说什么大概也不会理解，所以我不想再翻来覆去重复那些话了。如果大家想继续讨论的话当然没问题。如果有人还想杠的话我就直接 Block 得了。时间宝贵，不想浪费在无谓的争吵上。

我的观点是任何一个对 Git 有比较复杂需求的人都应该用 GUI 辅助而不是裸撸 CLI，从来不会犯错而且手速飞快 or 闲得没事干的人除外。

困了，睡了。

好吧，本来不想再说了，因为很多原因，我虽然加入 Ruby China 好几年了，也不常来，但是实在是不能忍了，从一开始，你定调的口气

Git 你需要一个牛逼的 GUI。光用命令行，几乎干不了什么复杂的事情。

我觉得就已经把整个 Ruby China 社区受众的理解能力的 level 降低了不止一个档次，这种话如果你实在一个 巨硬 产品主导的社区发出来，可能会大受赞赏，但是却偏偏在一个命令行操作挺多，而且 Ruby 语言本身其实和 CLI 很有渊源的一个语言之上谈这个，就有点小瞧社区的大众了。

我说的是 用命令行，几乎干不了什么复杂的事情，主语是人，说的是人类的能力无法达到充分利用命令行赋予的功能。

我只能说越解释越黑，很明显你也拉低了 linus 的智商，你写这么复杂的 git 功能干嘛？是让人用的吗？

但是我觉得该说的我已经说了，能理解的人也应该已经理解了，不能理解的人不管说什么大概也不会理解，所以我不想再翻来覆去重复那些话了。

我真的觉得，只有你自己在认为，和你争论的这些人不理解。

如果大家想继续讨论的话当然没问题。如果有人还想杠的话我就直接 Block 得了。时间宝贵，不想浪费在无谓的争吵上。

好吧，也许你时间宝贵，但是你不这样自我的将自己的那一套 GUI 工具当作使用 git 的救世主来这里传教，没人愿意花费时间和你争论。

本来只是来顶楼主小哥的，没忍住，歪楼了。

有些常用的命令可以用啊，很方便的。

你说得对。你是那种自己做出皮划艇就能从中国横渡美国的，Ruby-China 上的各位大佬我相信也有这个能力，自己重新开发出 GUI 里已经有了很久的功能，写出百来个脚本插进皮划艇里，然后自豪地说，看皮划艇才是横渡太平洋的最好方式，你们这些坐飞机的人都是傻逼，拉低了我们中国人的智商。你开心就好，我这个傻逼选择坐飞机。

对了，你提到你用了update_base dev，请问这玩意儿支持 3-way merge 吗？能做成左 + 中+右 diff 界面吗？能高亮显示段落差异和行内差异吗？

如果能，我很高兴地看到你也在用 GUI。

如果不能，我觉得我 1 分钟能做完的 merge conflicts，你 5 分钟根本做不完。

对了，你认为 vim 和 emacs 这种带有状态栏和菜单的全屏编辑器属于 GUI 吗？如果是，那我想你是不是平时都是用 sed 和 grep 来做文件编辑的？

假设，你要合并 feature/new_feature 到 dev 分支，你需要首先 checkout feature/new_feature 分支，然后运行 update_base dev(参见之前回帖写的那个函数), 解决冲突 (如果有)

这想得真是太美好了。

不知道你工作之外有没有参与一些比较大的开源软件的开发。

我维护的一个比较出名的软件的 mod 的时候，你想把 feature 直接 rebase 到 dev 上？简直是笑话。每隔半年的新稳定版，上游会多几百个提交，改了几十个文件的几百处地方，你自己的 feature 分支上十几个 mod 版提交，还改了几十个文件的几百处地方。你直接 rebase 试试，到下辈子你都解决不完冲突。

我们每次跟着上游新稳定版的时候，要一个一个 commit 查，看哪个 commit 会与我们现有的 mod 包冲突，然后在 commit 之前 rebase 一次，commit 之后 rebase 一次，解决冲突，检查逻辑，搞定以后编译一小时，然后跑 smoke test，确定工作正常，再继续往上 rebase。每半年的量我用 GUI 这么直观地做检查有时都要好几天才能完成一个新版本。我反正是不理解这种需要花费人脑去处理的程序源代码，你怎么就那么厉害，写了一堆脚本，duang，就解决了？

很明显你也拉低了 linus 的智商，你写这么复杂的 git 功能干嘛？是让人用的吗？

我倒是非常感谢 Linus 能做出这么复杂的 Git。一个能让我用软件去直接操作底层的工具，比一个只能在表面上挠痒痒的工具真是好用太多了。如果这玩意儿只需要简简单单几个命令就能完成任务，那我早就扔了。对，我说的就是 Mercurial。

我是不知道你为什么这么排斥 GUI。自动化的东西用 CLI 很正常。你做过视频转码吗？用过转码软件吗？我们字幕组做片是写 avs 模板，用 Rake 做工序依赖自动化，Flexget 走 rss 下片源，systemd 监控任务进度，telegram bot 反馈进度给组员，全都是脚本。为什么这些用 CLI 做？因为这些是电脑能够自己完成的工作。接下来的翻译，打轴，特效，这些为什么不是 CLI 做？因为这些是需要使用人脑来完成的工作。同样编辑文本文件，head+tail+sed+grep+awk 就能解决的，你为什么要用 vim 或者 emacs 甚至 textmate？为什么需要直观地把文件内容贴在屏幕上？为什么需要底下有个状态栏？为什么 vim 和 emacs 还支持鼠标操作？你想过吗？

你打开贵站回帖也是用的 CLI 吗？是用 poltergeist 还是 curl 写的脚本吗？这种涉及到人脑输入的操作全部做成脚本自动化有意义吗？我写软件改源码都是要用脑子的，不知道你用不用。

对了，你提到你用了 update_base dev，请问这玩意儿支持 3-way merge 吗？能做成左 + 中+右 diff 界面吗？能高亮显示段落差异和行内差异吗？

以前用 Beyond Compare 执行 3-way 合并，现在也会在提交代码前，用这个工具 code review 一遍。

但是后来发现，其实不好用 (可能 bc4 这方面比较弱吧，常出错), 最快的方式反倒是直接用编辑器逐个文件编辑来的最快.(这也是 Ruby China 社区一个大牛曾经提醒我的，直接搜索 <<<<<<, 自己编辑解决冲突，效果不错)

@msg7086 , 我承认你说的大部分都是对的，反倒是我第一时间看到你的观点时，对你的有些话有些误解，这里我道歉。

其实我也用很多 GUI 工具，dbeaver 用来连接数据库，beyond compare 用来目录同步，文件比较，只是更倾向于不依赖于这些工具而已，可能是目前我的操作方式够用，没有更多的需求的缘故，如果到那个地步，又有足够易用的，让我心动的工具可用，我也会选择他。

我就是这个意思。感谢你的理解。

比如数据库，你用命令行也能跑，而且对于反复执行的操作，大家都会写成脚本（比如数据库差异备份）。

但是我相信大家总会去使用一些图形界面（PMA，Heidi 等等），在日常环境下，打开，直观地检查数据，发现问题，修改数据库的数值。这种时候如何节约业务逻辑（数据库：修改资料；Git：检查代码）的消耗时间和保证高正确率才是人们最关心的。Git 命令行手一滑把 Working Directory 抹了的事情大家一定都听说过吧，数据库写 UPDATE 忘记加 WHERE 结果删库跑路的事情大家都听说过吧。对于刚入门不久的新手来说更是如此。

对我来说，我更倾向于依赖工具。工具工具，本身就是辅佐人类进行生产的。只要一份工具能改善人类的生产状况，那么就应该考虑去使用他。CLI 是应该学会，是应该懂，但是没必要迷信，全用 CLI 干活。适合用 CLI 的用 CLI，适合用 GUI 的用 GUI，这是我的观点。

顺便贴个我们用的 Diff 工具，不知道和 BC 比起来哪个看起来更直观些。

16 年学了一会 ruby，现在感觉区块链大佬都在用 ruby，学起来

@Rei 麻烦管理员帮忙删一下吧

不是吧，是多语言都在用吧，go 和 rust 了解下

我也很推崇 @msg7086 这种分支管理方式，其要诀就是，merge 之前此分支一定要和目标分支进行 rebase，发现冲突直接在本地解决后再 push，merge。这样形成的 commit 历史会很赏心悦目。

虽然我所有操作都是在命令行完成的，也比较推崇用命令行来使用 git，并不觉得用命令行我做不了什么复杂的事情，但我确实还是需一个 GUI 来看提交历史的 (不太喜欢用 git log)。windows 下有 gitk，但 mac 下好像没有，但有一个更好用的 gitup

如果分支开发过程中 rebase 了 develop，推送到远程分支是否必须 push -f？因为之前相同的提交 hash 不一样了。如果其他人 fetch 了 push -f 后的分支，就必须 git reset --hard origin/dev-branch。有更柔和的做法吗？

EDIT: 我想了想，只有尽量在大功告成前不要 rebase，local squash 也一样，也会造成一系列--force 操作

平时工作也用 ruby 么？

必须 push -f。

如果其他人 fetch 了，那应该是把他们还未 push 的提交 rebase 到 origin/feature 上。

具体是否实施 force push 还要看团队成员对 git 的掌握程度。如果对完全操控 git 库没有信心，那还是尽量少 force 比较好。

是的

你好 请问您知道怎么在 VS Code 上 debug Ruby 么 网上找了很久也没找到可用的答案

抱歉，不太清楚。

好口巴~谢谢您的回复

@Vucius 参考：https://marketplace.visualstudio.com/items?itemName=rebornix.Ruby#user-content-debugger

Emacs Magit 用户路过。。。
不过如果要跟踪，可以开两个线，一个线用来进行整齐的合并（rebase 整理 commit），大家平常合并是往这个线上合而不是直接合并到主线。
这样不用频繁的进行 rebase，而且最终主线会干净一点，既方便又美观。