使用Git进行团队合作开发版本管理原则

 Git 是最流行的版本管理工具，我也是刚刚接触git，系统的学习了下Git的团队开发Branch Model，发现网上已经给出的最佳实践如下：

更详细的信息，请直接参考原文章链接：

http://nvie.com/posts/a-successful-git-branching-model/ （最佳实践的来源，强烈推荐读一下）。

http://www.ruanyifeng.com/blog/2012/07/git.html （上一篇文章的中文翻译和简化，没有原始文章清晰）

http://scottchacon.com/2011/08/31/github-flow.html （git-flow 根据第一篇的最佳实践总结出来的模式性的东西）

最佳实践如下（源于最佳实践一文）：

1. 任何系统或项目都常备两个 Branch， Master 和 Developer，这两个branch 永远不会删除。

• Master branch 标志了系统的最初版本和稳定功能，如果Master branch 有提交，那么一定表示有新的稳定功能或者 bug 修改，需要重新发布新版本。版本策略由项目组独立制定，比如较大的功能发布，可以升级大版本 （v1.1.0 -> v1.2.0）, hot bugfix 可以发布小版本 (v1.1.0 -> v1.1.1)等。

• Develop branch： 最初是从 Master branch 拉出。是功能开发的 upstream branch。 所有开发的功能都要 merge 到 此 branch，进行最终的集成或回归测试。如果测试通过了，那么会将功能merge 回 master（注意不是直接merge，下面会讲到），进行正式的发布。

    2. 中间的branch，随需要拉出，功能执行完成后删除。主要包括如下几种：

• feature branch。故名思议，feature branch 是真正的功能开发的branch。为什么 feature branch，而不是直接在 develop branch 上开发？ 因为团队合作！ 如果需要并行的开发多个feature，那么在一个 develop branch上开发明显是不合适的，不内聚，容易造成错误。每个 feature 开发，都需要单独从 develop branch 拉出一个独立的feature 分支，开发并测试完成后，需要在合并到 branch 分支，然后进行验证和回归测试。确认没有问题后，删除 feature branch。
• release branch。release branch 专门用于预发布的。 feature branch上进行了功能的开发，测试通过，并合并到develop branch 上了。这时可以发布新的功能了。为什么不直接从 develop branch merge 到 master branch 并直接发布？ 因为在发布的时候，我们可能还需要做一些细节上的微调工作，比如开发时版本号可能是 snapshot，到正式环境上需要去掉 snapshot，比如需要连接正式的数据库进行下验证，修复下验证中发现的一些bug。这些都是在 release branch 上进行的。release branch 工作完成后，需要 merge 到 master branch，正式发布。注意 release branch 也要 merge 回 develop 分支，确保所有的修改都同步到了 develop 分支。
• hotfix分支。上面的分支已经能够确保我们从开发到上线的流程都成功了。但是有时候在线上会发现一些比较hot 的bug，需要立即修复。这个时候走正常的 feature release 到发布显然是不能满足要求的。此时应该直接修改 master ，并合并到 develop branch. 这就是 hotfix branch 存在的理由。从 master branch 拉出 hotfix branch，bug fix 并验证后，合并到 master 和 develop。

 具体的拉出分支的命令及merge 命令，请参考最上面推荐的链接。