Git的研发流程
1.1集中式工作流
集中式工作流以中央仓库作为项目所有修改的单点实体。相比 SVN 缺省的开发分支 trunk，Git 叫做 master，所有修改提交到这个分支上。该工作流只用到 master 这一个分支。
开发者开始先克隆中央仓库。在自己的项目拷贝中，像 SVN 一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
克隆代码
git clone ssh://user\@host/path/to/repo.gi
要发布修改到正式项目中，开发者要把本地 master 分支的修改『推（push）』到中央仓库中。这相当于 svn commit 操作，但 push 操作会把所有还不在中央仓库的本地提交都推上去。
git status # 查看仓库状态 git add # 暂存 git commit # 提交
git push origin master
优点
· 集中式工作流主要优点是简单，非常适合小型团队
· 对于要从 SVN 迁移过来的团队来说很友好
缺点
· 当您的团队规模扩大时，上面详述的冲突解决过程可能会成为瓶颈
· 完全没有发挥 Git 的优势，在实际使用 Git 协作的项目开发中很少使用集中式工作流
1.2分支管理工作流
优点
· 相比于前文介绍的集中式流程更为合理实用，可以减少工作中的冲突
· 由于工作流程的简单性，此 Git 分支策略对进行持续交付和持续集成很友好。
· 当需要在生产中维护单个版本时，它是理想的选择
· 这个 Git 分支策略非常适合小型团队和 Web 应用程序
缺点
· 这种 Git 分支策略无法同时支持多个版本的代码的部署
· 没有解决部署、环境区分、 releases、Bug 修复相关的问题
· 生产代码容易变得不稳定
