yield content_for

#22 楼 @ery 我这推广了一段时间 rebase，现在组员对 git 熟练起来后，开始提倡 merge 和 rebase 并用。rebase 用在短小的补丁 commit 上，merge 用在特性开发，因为希望 logs 不单要线索清晰（merge 点不要太多），也要反映协作情况（多线进行），不然一个两天前的 commit rebase 到了今天的 commit 上，以后查看起来会很奇怪。

#20 楼 @ery 比如 B 分支有两个人在上面开发，然后把 B rebase A。

这里有详细例子 http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E8%A1%8D%E5%90%88

一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。

#17 楼 @zlx_star #18 楼 @ery

rebase 适合于少量的补丁性质的 commit，不要把已经提交到公共区域的分支 rebase。

#14 楼 @zlx_star 项目刚开始的时候是频繁 merge，大概一天 merge 1 ～2 次。到上线以后就不太会出现两个分支互相依赖了，因为可以按功能划分，有依赖的都在同一个分支。早期因为架子还没成熟，就会相互依赖，这时候通过一个主线分支（主开发分支）来作为 merge 的中心，而不是 branch 之间互现 merge。

-编辑掉 -

#10 楼 @zlx_star bugfix merge 进 develop 分支，然后到 feature 分支把 develop merge 进来。

#30 楼 @hawkflying 你可以用顶楼右下角的「收藏」图标，不要回复 mark。

习惯了。倒是坐姿问题要矫正。

#5 楼 @zlx_star 依赖是指什么？

我现在 2 人开发一个新项目，一个 master 分支，然后两人分别负责前后台各一个分支，前后台分支不断 merge --no-ff master，解决冲突后 checkout master & merge --no-ff feature。

我最近买了 linode 东京，也是 110ms 左右。

#12 楼 @Peter 越简单越好修改

http://nvie.com/posts/a-successful-git-branching-model/

第一代人，出国了 第二代人，都进了国内大公司关键部门 第三代人，Ruby China 这一波

铁轨上的 Ruby（更快）

http://ruby-china.org/topics/node54 开好了

good

可以试试基于我写的网站开发，没有这个问题 http://codecampo.com/ ，源码 https://github.com/chloerei/code_campo

场地很好。贵在坚持，看好楼主的活动。

不过我最近肚子没墨水了所以要闭关修炼一段时间暂时不参加。

#4 楼 @chucai 可以搞些周热门存档，月热门存档。首页老帖多了的话以前已经看过的人会觉得很无趣。

我反倒觉得老帖子不应该顶上来。

我觉得不错，等 @huacnlee 拍板。

gem "nokogiri", "~> 1.4.2"

on a version of nokogiri that is >= 1.4.2 but < 1.5.0

#4 楼 @azhao ree 已经停止更新了

好像指针引用那样，把 defaults 的内容导入 development。

#4 楼 @ruby_sky 槽点是不要截图……

图片字太小看不清

#21 楼 @moonjourney 其实你打开 Linux 的终端，Ctrl + p，Ctrl + n，Ctrl + w，都是继承 Emacs 的快捷键。