#47 楼 @zw963

说归到底，git 是为开发流程服务的，而开发的流程又跟团队的构成和开放方式密切相关。

比如说，如果团队的程序员都坐在同一个办公室里，并且有对代码交流讨论的习惯，水准都不错而且互相信任；或者经常做结对编程有充分的讨论；这样的话用 rebase 就很好，可以把小块的代码快速集成而且高频率的 deploy, 大部分的 branch 都是很快就会剔除掉

如果团队不在同一个地方希望能加强交流，或者水平不一有些新手，这样象@HungYuHei的流程就很好，每一个 merge 的流程都清晰表现出来，而且要 merge 的 commits 也一目了然，很适合根据这个来进行 code review 和讨论。这个流程的代表是 Github, 他们的流程包含一个对自己 repo 的 pull request, 并且用 pull request 来作为讨论代码的一个工具。可以参看http://zachholman.com/talk/how-github-uses-github-to-build-github

这种方式需要注意的是因为需要等别人的 code review, 代码不能立刻 deploy 会放慢节奏，而且有可能会因此创建大量的 branches, 导致可能要多方 merge，而且也可能会让 commit history 杂乱。但确实对于团队的交流非常有好处。

所以就是根据团队的情况做选择了。

#7 楼 @fsword

obvious solution 就是优雅的 http://shipitsquirrel.github.com/

把 created_at 和 updated_at 拆出来就好了

json.(post, :token, :title, :content) json.created_at post.created_at.stamp("Jan 01, 2012") json.updated_at post.updated_at.stamp("Jan 01, 2012")

http://mongoid.org/en/mongoid/docs/documents.html#security

#3 楼 @fsword

请帖下你的代码

https://github.com/jeremyw/stamp

#43 楼 @zw963

是 fast forward, 因为别人如果按照同样的流程也一定集成了你的所有本地 commit，而没有 push 的 commit 又都不在 master 上。

需要在 branch 上很久的时候多半是要完成一整块的 feature set 才能整合在 master 里面，比如，凡是涉及到付费的时候就要把很多情形考虑到做完才能一起 deploy。可以每做完一小块测试通过后就 git checkout master; git pull --rebase origin master; git checkout my_branch; git rebase master

这样先把远程 master 别人的代码拿下来，再 rebase 到自己的 branch 上面。再跑测试。通过了之后 git push origin my_branch, 这样就不用担心比如电脑掉到水坑里，或者需要别人接着做这个大 feature set. 再继续做下一小块。原因还是每次集成少量代码，有问题早解决。而 remote branch 伤得的 commit message 也可以作为一种和同事的交流工具，让别人知道你做到哪里。

等到 feature set 做完，还是一样 git checkout master; git pull --rebase origin master; git checkout my_branch, git rebase master; run test; git checkout master; git merge my_branch (fast forward); git push origin master; deploy

总结下，

1) 所有 developer 的本地 master 都紧跟 remote master，而且都是 working code, 随时可以 deploy 2) 本地上推前先抓 remote master，整合测试通过后从 local master push remote master, no conflict. 3) push/deploy often, push/deploy early 4) remote branches 做备份和交流

要是出现了几个 long living branch 又都不能很快 deploy 的时候就比较复杂，可以考虑再开一个非 master 的 integration branch. 但这种情况一旦出现更多的是整个项目的筹划出了问题。

fugitive 也非常强大，我对他的依赖性仅差于 rails.vim

#55 楼 @zw963 谢谢，才发现的 ruby-china, 不过很多头像都看着眼熟

简单化的说不考虑 block,

object.try(:user) 相当于 object && object.user

是为了防着 nil. 如果只是 object.user 一旦 object 为 nil 就要出错。其实用这个也算无奈，最好还是应该提早处理 nil, 不要让 nil 溜的很远

这个为啥是瞎扯淡？

如果需要 Ruby 1.8.7,

rvm --create --rvmrc 1.8.7@mygemset 用 Ruby 1.8.7 并且创建新的 gemset, 并把设置保存在.rvmrc 文件里

bundle

smile :)

#31 楼 @HungYuHei 是的，我从来不用 git pull, 一律 git pull --rebase (alias 成 gpr)

我最近在做一个类似的介绍 Ruby 给新手的系列，到时候要大家捧场啊 :-)

Hacker News :)

#28 楼 @happypeter

1. 原理上是这样，如果把本地的 master 看成是远程的镜像可以把流程简化很多。也就是说，这要本地的 master 测试都通过就立刻 push remote master.这样别人可以立刻拿到你的 code，可以 integration test 或者 reconcile 等等，不至于要一次集成太多代码。还有，你可能有多个 remote, 比如一个 Github, 一个 staging server, 一个 production server, 等等，如果你的 deploy 用 git 的 workflow, 比如 Heroku。如果保持本地 master deployable, 就可以很方便的选择 deploy 到哪个上面

2. 如果你的 feature 需要 20 个 wip, 说明你 feature 本身太大，应该掰开成更细颗粒的 feature. reset -i 是很有用的，不过我一般最多是五六个 commit, 没用过 20 多个这么多。有时候我会需要在一个 branch 上面工作很久，但一般我都会很经常的 rebase master, 跟上 master。不然到最后一个大的 merge/rebase 太头痛

#38 楼 @ery 同意。Metaprogramming 是双刃剑，还是尽量要谨慎

Kent Beck 一个多月前发了个 twitter 说的就是这个意思

“metaprogramming depends on the structure of the program and hence constrains the future structure of the program”

http://twitter.com/KentBeck/status/230453290272436224

#24 楼 @happypeter 没错，如果只是小修改是不需要开分支的。如果修 bug 是不知道要多久，bug 修好可可能 remote master 已经前移了。而 remote 的新代码又很可能和修 bug 的代码有冲突。这样的话开分支就比较好，并且在 commit back to master 之前把当前远程的最新代码抓下来一起 integration test.

#21 楼 @knwang 在这里 http://blog.hashrocket.com/posts/feature-development-with-git-branching

#14 楼 @happypeter 我最近恰好做了个 screencast 关于这个的