=== has absolutely nothing whatsoever to do with equality. In particular, it violates pretty much every law that you would ecpect an equality operator to follow. And it does that very much by design. – Jörg W Mittag Dec 17 '10 at 5:08 [1]

 (1..5) === 3           # => true
 (1..5) === 6           # => false

Integer === 42          # => true
Integer === 'fourtytwo' # => false

  /ell/ === 'Hello'     # => true
  /ell/ === 'Foobar'    # => false

除了上面说的 User === User.first 以外，还有 User.first.is_a? User 可以用。这里当然也可以 User.first.class == User。

=== 不是判断相等的运算符。

[1]: https://stackoverflow.com/questions/4467538/what-does-the-operator-do-in-ruby

找你们负责人谈谈。负责人说什么，就听他的。

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

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

但是我相信大家总会去使用一些图形界面（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 的使用技巧。