我更倾向于这种做法。

一般每次 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 的使用技巧。

请问你想表达什么？

说反了什么？

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

首先这是 gzip 压缩，不是 zip 压缩。

其次 production 应该由 web server 负责静态文件。

nginx 如何实现？大多数发行版安装的 nginx 就已经配置成压缩了，具体可以读各大发行版 nginx 包里的默认配置。

只说了结论，没有说原因，看上去也就是省掉了一个 Enumerator 的初始化，我不觉得是什么严重的性能问题。

而且写代码本来可读性就是很重要的，我觉得 x.times.map 读起来比 Array.new(x) 更直观一些。

.to_i(+3) 应该是很容易猜的。

foo (bar, baz) 这种调用方法也是很久之前就被废止了，要求括号与函数名之间不得有空格。其后对于 foo (1) + 2一律解释成 foo( (1) + 2 )。

0.upto(arr.size - 1)

->

arr.size.times

还可以考虑用ensure包起来。

我只是纠正一下用词。这种编码，最多可以叫混淆，轮不到加密这个词。

自带加密效果。

Gzip 不叫加密效果……

一般是为了省函数，再加上英语读起来比较顺口。

if whatever?
  redirect_to root_url
  return
end

vs

redirect_to root_url and return if whatever?

根本不知道现在 imgur 都要梯子了。

顺便上图一张（网络源，出处不详）

你不如去隔壁 v 站躺一会儿，回来就知道这里环境有多好了。

White lives matter （手动滑稽

Rails 本来就是激进风格的，否则就像你说的，为什么不去用其他语言和框架呢？

要是不激进，岂不是要一直落在别人后面了。

RESTful 是一种约定的规范。

意义就是有一定的规范，没了。

你当然可以和前端自己约定一套自己的规范，其意义当然也是有一定的规范，没了。