Git 小团队 (10 人下) 的 git flow
大家推荐下小团队 (在 10 人以下) 的 git 协作工作流，以产品开发/迭代为主。
git branch -b my_name # 私有分支
git commit
git checkout master
git pull
git merge my_name
git push origin master
比如说除了master分支外，一般都会有一个dev分支，featuren分支等，当几个人协作一个feature分支的时候，应该如何处理？
# just do thins on master branch
# hack hack hack
git commit
git fetch
git rebase
# sometimes you need git rebase --continue
git push
#3 楼 @flowerwrong 这个属于 github 模式吧？现在开发一直是这样，并且不建议 git merge(以前一直是)，后来使用了 git rebase，log 清晰很多，而且 git rebase 强大很多！
我理解的 git flow 是这样个子的：http://ihower.tw/blog/archives/5140
ihower 那篇文章我读了好多遍，补充几个理解：
1、我们开发组维护 develop 分支，branch 一个 feature。 2、QA 介入的时候，使用的是 release 分支。 3、hotfix 在 release 上做，也可以在 develop 上做，关键在于 6 4、release 分支在完成后，merge 到 develop 和 master，然后删掉 relase 分支。 5、staging 分支和 release 分支一个概念 6、经常重做 release 分支，保持 QA 测试到最新得 feature 和 hotfix。 7、rebase 的确比 merge 干净很多
这张图不错，看着干净很多。
git flow 开发会使 git 树很乱，因为有很多的分支去 merge, 但是好处是可以多分支开发。但是楼主的这种开发形式，完全可以用 git flow 来替换。
merge 会把 git 树搞的很乱，尤其几个人一起 merge 的时候。我觉得除了 PR 的那个 merge 无法避免，能 rebase 的就不要 merge。
#9 楼 @ruby_sky
#14 楼 @liwei78 是 git 模式。其实也就是团队的workflow。
另外，我试了下git rebase，发现他的 log 和merge的 log 也就是是多了一条merge xxxx。
还有
# in branch master
# commit a obj at 15.33
# in branch rebaseA
# commit a obj at 15.35
git rebase master
git checkout master
git merge master
git log
# commit a obj at 15.33 注意时间
# commit a obj at 15.35 注意时间
但是，如果我在master里面做rebase，log 结果就不一样了。
# in branch master
# commit a obj at 15.33
# in branch rebaseA
# commit a obj at 15.35
# in branch master
git checkout master
git rebase branchA
git log
# commit a obj at 15.35 注意时间
# commit a obj at 15.33 注意时间
我看 http://git-scm.com/book/zh/v2/Git-Branching-Rebasing , 是先rebase，然后通过merge移动指针，这样有什么区别？
#15 楼 @flowerwrong rebase 会重建 MD5，merge 不会而是加一个 merged 信息在目标分支上。所以小的 feature 开发是没必要 merge 回去的。 如果是重要的 feature，该 merge 还是要 merge 的，尤其是冲突比较多的时候。
