#34 楼 @qinshulei 无关 Git 技巧，即使对于 Github 的开发团队来说，Gitflow 这套流程也过于复杂了。

#30 楼 @steveltn 你是说升级依赖的库或框架？没有太大的 break change 一两天就能搞定了吧直接提交呗。如果说有很大变更，原文引用的文献里有一篇是 Jez Humble 讲我们用 branch by abstraction 把一个项目的 ORM 整个换掉。

用 feature branch 的团队总爱说经常 rebase master 就没事了，事实是如果 feature branch 存在的时间较长，只 rebase master 是不够的，因为还有若干并行开发的 branch 没有被 merge 回 master。假设每个 feature 的开发周期 1 个月左右，可能第三周结束的时候另一个 team 把他们的 feature branch 合并回 master，你们 rebase 的时候发现这三周的工作所依赖的代码全部被改掉了。而如果集成能更早发生，你们也许在第一周的时候就能基于新的代码继续工作。

#27 楼 @steveltn 能举个不能被 toggle 的 feature 的例子吗？我承认有些改动 feature toggle 帮不上忙，需要 branch by abstraction 等其他手段。但大部分 feature 都可以使用 feature toggle。

新 feature 的 toggle、类库的 feature flag 这些很成熟的就不提了。我们项目曾经有一次 UI redesign 的大改版，从 UI v2 到 UI v3 的整个过程都是用 feature toggle 控制渐进开发的 (v1 改 v2 的时候项目还没上线)。整个过程始终基于 master 进行开发，小步提交和持续集成，没有影响到终端用户。由我们组负责的 UI redesign 开发周期有一个多月，于此同时其他几个组在开发其他的 feature。对于 UI 这种影响整个应用横切层的大规模改动，如果不小步增量修改持续集成，我没办法想象怎么把一个 big bang change merge 过去而不破坏其他功能。

#25 楼 @steveltn 代码还是正常 push，使用 feature toggle 将未完成的 feature turn off，master 还是可以部署。

#23 楼 @steveltn 是的，前面也提到了代码 clone 到本地就成为分支。分布式版本控制系统其实没有严格意义上 trunk 的概念，我们只是挑选一个 master 作为主分支。branch 按周期分有 long lived branch, short term branch 和 temporary branch，按用途分有 feature branch, release branch... branch 是一种事实，而 feature branch 特指利用 branch 隔离 feature 代码进行开发的一种使用方式。

原文的点在于避免 long lived branch，而 feature branch 会鼓励长期跟 master 并行的分支。原文鼓励的是频繁地跟 master 合并，以 release track(bug fix), 探索性活动为目的创建分支，而不是以 feature 代码隔离为目的创建分支。

#15 楼 @zxzllyj pull request 模型就是分支呀。fork 一个 codebase 也好，clone 一个 codebase 也好，都是分支。看你们发 PR 和合并 PR 的频率，如果频率太低攒一堆 commit 一块合并，上面提到的问题全都会遇到。

其实 pull request 的初衷是鼓励更多人参与到 open source 开发里。传统的 open source 模式，你做贡献要先从找 issue 提交补丁做起，每个补丁都是由开源软件的 commiter/maintainer 来 review 然后合并进去的。慢慢做的贡献多了被社区认可，成为 commiter。再慢慢进入 core team，可以参与设计方向的决策讨论。多少有点等级金字塔的感觉。

pull request 是把软件的分支和分裂常态化了。不管你是高手还是菜鸟，都可以 fork 一个自己的分支，然后你自己的分支就由自己维护自己说了算啦。如果需要你可以将自己的改动发 PR 反馈给上游社区。这么做虽然会让软件和社区分裂碎片化，却能极大促进创新和功能的衍化。以前我想往 emacs 加入一个 X、Y、Z feature 需要 RMS 同意需要说服社区一大批用户，现在我直接 fork 一个 XEmacs 单干，建立我自己是社区。此消彼长，有时候上游社区会逐渐接受分支的反馈便得更好，有时候新的分支反而取代原有版本成为主流。开源社区也因为这种分裂和衍化而蓬勃发展。

从企业软件开发的角度看，因为不会出现无限分裂的情况，代码最终还是回归一个主干，还是更接近传统的 open source 模式 (或者说传统 open source 模式是从传统软件开发沿袭而来)。pull request 除了改善 code review，这种协作模式下起到的作用有限。所以说技术的应用还要看上下文。

#12 楼 @msg7086 不仅要经常 rebase，还要经常往 dev branch rebase 或 merge 回去，要不然随着其他人的提交，相同一段代码可能要 rebase 很多遍。

#9 楼 @liuzelei 这不是代码松耦合。代码松耦合是说如果你的模块划分合理，修改模块 A 不用关心模块 B，二者可以独立地修改变化。而分支只是推迟了冲突解决，最终你的代码还是耦合在一起的。所以在原文里我提到分支是穷人版的模块架构，既没在本质上消除代码的耦合，又不能在运行时切换。

Hi, 我是原文的作者。很高兴能在这里看到对这篇文章的讨论。

原文的观点是 long lived branch considered harmful。关于什么是Gitflow章节的反驳我就不花太多精力了，关于如果不用gitflow章节的质疑，原文也给出了链接，TrunkBasedDevelopment 和 feature toggle 等技术是被 Google, Facebook, ThoughtWorks 等技术公司验证的最佳实践。

剩下的部分其实基于一个基本假设，这个假设也是软件开发行业几十年来的共识：我们应该尽可能地缩短反馈周期。在这里 feature branch 会鼓励长时间分支，每个分支在合并到主干前都无法获得及时的反馈。楼主举的例子很好：

我们新开一个分支，把功能做好，测试确认没问题，马上就合并到枝干上，把这个分支给删除了。这个分支，甚至都不会出现在中心仓库的分支里，升值自己的 remote 仓库里，仅仅在个人本地仓库出现，可能一天，或者半天我们就完成了一个 merge 迭代，把这个分支给删除了。

这也正是原文所鼓励的，避免 long lived branch。无论是否用 gitflow 或 feature branch，使用者在实践中都会发现频繁地跟主干合并代码 (频繁从主干 rebase 回 feature branch，频繁把 feature branch 代码 merge 回主干) 能大大减轻 big bang conflict 的 merge。而当你的每个 feature branch 只存在于本地一天或半天时，为什么还要单拉这么一个 branch 呢？毕竟本质上 git 并没有主干分支，每个 repository 都是一个独立分支。

楼主对于原文一些例子的质疑，可能因为楼主的工作背景是嵌入式领域，对于互联网模式/敏捷软件开发中的许多基本实践 (代码共有，重构，持续集成) 缺乏了解。如果不澄清这一点可能会对一些基本的实践产生观念冲突，而完全展开也不是三言两语就能覆盖的。如果有兴趣我们可以 case by case 地聊。

另外原文讨论的是基于企业软件开发的上下文。如果是开源软件开发的协作就是另外的情况了。事实上开源社区的繁荣和魅力的根源也正是其多样性——每个人都可以 fork 自己的分支。

#14 楼 @rasefon 因为通用编程语言比 SQL 表现力强，写起来也更流畅呀。当你的 sql 各种 join 临时表只是为了数据结构的转换时，你就会想念用通用编程语言操作内存数据结构了。另外从可测试性和可维护性角度来说，代码也比 sql 好的多。

#11 楼 @rasefon 你用的是什么 ORM 不能显示 join 多表？我用 hibnernate 经常生成 join 十几个表外和几个子查询的单条 sql。

ES6 之后 coffee 存在价值就不大了。

我觉得 XP 才是敏捷的核心，虽然要引入和接受比较难，但这部分是带来最大价值的。很多团队根据自己的情况量体裁衣，就把这最困难的部分扔掉了。

真是敢说，申通日均业务量都在百万级别以上。

#2 楼 @SErHo 开始应该是逻辑题吧？

人不够的话我可以打个酱油

#116 楼 @hooluupog 老赵那个系列反复强调 Java != JVM，他喷的是不思进取的 Java，不说语法说什么？

王垠发的是什么样的 paper 你知道么？05 年的时候他还没搞编程语言设计。像王垠博客里这种文章写上 10000 篇能发一个 paper 么？有哪些思想上的新东西么？他的文章里充斥着观点，你找得到支撑论点的论据么？

王垠最近一篇对 Go 的评价“Go 语言里面有很多新的和好的东西。可惜新的东西都不是好的，好的东西都不是新的”这个句式简直听到烂，既可以什么都不说又好像说了很多，反正等于没说。看思维导图也没什么新东西，都是之前别人喷过的。

技术界第一名笔肯定要数 Brian W. Kernighan，the creator of "hello, world", K&R 跟 AWK 中的那个 K，文风像 Unix 和 C 语言一样简洁明晰。 <程序设计实践>和＜The Elements of Programming Style>都是可以比肩 K&R 的经典，跟 Robe Pike 合著的＜The Unix Programming Environment>和跟 AWK 另外两名作者合著的＜The AWK Programming Language>也是了解 Unix 跟 AWK 的必读。

第二名笔力推 W.Richard Stevens，为我们留下了 APUE，UNP 两卷，TCP/IP Illustrated 三卷，学习 Unix 编程不可绕过的经典。

Bruce Eckel 的＜Thinking in C++>和 是不少人学习 C++ 和 Java 最好的参考书。

Martin Fowler 除了＜重构＞，还写过＜企业应用架构模式＞，＜领域特定语言＞等一系列好书。

Bob 大叔 Robert C. Martin 写的<敏捷软件开发＞，＜代码整洁之道＞都是很棒的技术书籍。

之前 DHH 在他博客里提到对他影响最大的书籍中就有 Kent Beck 的＜Smalltalk Best Practice Patterns＞，Kent Beck 更出名的书也许是那本<测试驱动开发＞和＜实现模式＞

FBI ! 一定是 FBI 干的！

#10 楼 @kgen 可以免备案。你想放国内机房自己备案也行。

点点的处理方法好像把没备案的放到香港的服务器上，打擦边球。当然这些不用你关心就是了。

#8 楼 @kgen 点点、lofter 好像都能绑定自己的域名吧

最近我也要为学校做一套 CMS，对楼主的项目挺感兴趣。请问楼主的项目最近什么进展？如果可以的话也希望能贡献一份力量。我的邮箱 [email protected]

SCUer +1 有活动可以联系我啊~ goooogle.liu#gmail.com

写爬虫，写测试

是不是想说 ECMAScript？社区里大部分人应该都有几种以上语言技能，尤其是 JS 和 Python 这种平时会用到的。

是不是跟风 V2EX = =

我在成都，最近明显感觉 ruby-china 很慢