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

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

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

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

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

很明显你也拉低了 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 写的脚本吗？这种涉及到人脑输入的操作全部做成脚本自动化有意义吗？我写软件改源码都是要用脑子的，不知道你用不用。

假设，你要合并 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，就解决了？

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

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

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

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

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

我司做的是类似虚拟化管理平台的东西，也是卖的硬件 + 软件组合，基于 ESXi，用 Rails 写的。

现在虚拟化普及以后，基本不用担心平台性能问题，都是 x64 虚拟机一把梭，内核用发行版 Stock 就行，啥都不用干，还能享受发行版自己的安全补丁。

我们还有个类似小型路由器网关一样的虚拟机，里面跑的 Ubuntu 8.04 Stock……

还是那句话，楼主说的是不能收钱，和赚钱没关系。

只要收钱就涉及到商业行为，和你收几毛还是一分没有关系。行为定性变了。

有些领域有些事情是不能差这几毛钱甚至几分钱的。

（比如说我们做字幕组的，有个原则，侵权不收钱，收钱不侵权。做汉化，一分钱都不能收，一分钱都不能。收钱的，要签劳务合同，一旦发生纠纷，甲方承担责任。为什么呢？很简单，收了一分钱就是侵犯著作权罪，不收一分钱就是违反著作权法，前者公诉，警方可以抓人，后者自诉，法院调解赔偿。）

#4 说的是收钱，你说的是赚钱，两回事。

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

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

Unicorn 是不能用来服务大众的。你请求量大了，服务器失去响应，属于合理现象。

连求职贴都写成这样的，要我是 HR 我也不敢要啊。

https://guides.rubygems.org/run-your-own-gem-server/ 这样？

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

尾递归不会导致内存泄漏啊。

另外能用尾递归写出来的逻辑，一般也能用循环实现吧。通常只有函数式编程才会倾向于写成尾递归的形态。

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

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

困了，睡了。

我更倾向于这种做法。

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

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

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

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

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

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

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

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

你说我为什么要推 GUI？

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

为什么我们会用 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 的一个语法糖。

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

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

[
  ->{0},
  ->{puts 'call1'; `/bin/stty size 2>/dev/null`.split[1].to_i},
  ->{puts 'call2'; `/usr/bin/tput cols 2>/dev/null`.split[0].to_i},
  ->{puts 'call3'; 80}
].lazy.map(&:call).drop_while(&:zero?).first

（多余的内容是测试用的，请自行删除。）

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

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

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

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

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

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

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

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

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

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

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

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

请问你想表达什么？

说反了什么？