不喜欢用一些额外的工具限制着，我更喜欢直接用 git 的命令 而且 git-flow 有点复杂，相比较下，我更喜欢更简单的 github-flow

我们再用，最大的好处就是，当团队规模超过三个人，而且大家的 Git 水平不一的时候。

Git-flow 可以作为一个工具来吧工作流程标准化。

我一直觉得，做技术上的 scale up 之前，开发团队必须先能做到 scale up.

现在也是感觉 github-flow 更好些，主要是 feature branch 可以 push 到 github 上，虽然 git-flow 也可以，但是毕竟好像有点跟 git-flow 脱离的感觉。另外就是 github-flow 没有版本号这样的问题，git-flow 的版本号很。。。我承认，我对版本号没什么感觉

在用，SourceTree 直接支持，很方便。

if you're not using command line, you're not :strong: hah 老大知道我一直在用 gitX 后开的玩笑。

I feel strong enough without the cmd line

#4 楼 @leopku sourcetree 看介绍似乎不错。

我们没在用，最主要的原因是分支模型不匹配。

团队旧有的习惯是 web app 项目每天 release 至少一次，release 之前就上 staging 测试。即使人为地区分出 develop / master / release 这么多长线分支，彼此间的代码也往往是很快就同步一致了。当你只有一个长线分支需要考虑的时候，问题本身就简单得多。

最终我们采用的流程是：中央仓库只有一个 master 分支，各个开发者从自己的 fork 上发起 pull request，code review 通过就 merge。不约定 branch 名字，也不限定每次 PR 提交的内容，只要 code review 时满意，其它的都无所谓。

花点时间多调研下，选择适合自己的才好。虽然 Git Flow 在博客圈声音很大，对于有些项目确实也很合适，但我们最终还是没去用。Srsly，“开始写代码之前先得按照分类去建 branch”这件事让我觉得实在是浑身不爽。