Git分支管理常见三种方式

1，TBD

1），所有团队成员都在单个主干分支上进行开发。

2），发布时，先考虑使用标签Tag，如果打标签不能满足要求，则从主干创建发布分支。

3），Bug在主干上修复，然后挑选时机发布到发布分支上。

2，GitHub flow

GitHub使用一种简单流程，使用两类分支，Master，代码修改分支，主要对应GitHub得pull，request功能。

master分支，

包含稳定得代码，该分支已经或即将被部署到生产环境，分支的作用是提供一个稳定可靠的代码基础。任何开发人员都不允许把未测试或未审核的代码直接提交到master分支。

代码修改分支

当需要进行任何修改时（包括bug修复，hotfix，新功能开发等），总是从master分支创建新分支。

分支合并流程

当新分支中的代码全部完成之后，通过GitHub提交一个新的pull request。团队中的其他人员会对代码进行审查，提出相关的修改意见。由持续集成服务器对新分支进行自动化测试。当代码通过自动化测试和代码审查之后，该分支的代码被合并到master分支。再从master分支部署到生产环境。

Git-flow

目前流传最广得Git分支管理实践。围绕得核心概念是版本发布（release）.git-flow流程中包含5类分支，分别是master/develop/feature/release/hotfix。

1，Master分支中包含的是可以部署到生产环境中的代码，这一点和GitHub Flow是相同的。

2， develop 分支中包含的是下个版本需要发布的内容，当develop分支集成了足够的新功能和bug修复代码之后，通过一个发布流程来完成新版本的发布。

发布完成之后，develop分支的代码会被合并到master分支中。

3，feature，release和hotfix均为临时分支，只在需要时才从develop或master分支创建，在完成之后合并到develop或master分支。合并完成后该分支被删除。

总结：

1，如果发布周期较长，则git-flow是最好的选择，git-flow可以很好的解决新功能开发，版本发布，生产系统维护。

2，如果发布周期较短，则TBD和GitHub flow都是不错的选择。