如何管理你的Git分支

Contents

本文主要介绍 Git 版本管理工具，在多人协同时，出现分支的管理混乱问题。为了响应市场需求的变化，版本的迭代速度和频率都不断提高，很容易出现发版与测试管理的混乱的问题，甚至可能导致生产环境会出现一些低级且严重的错误。

如图所示：GitFlow是一个已经相对成熟的Git分支管理模型。

Git：是对项目文件的跟踪与记录，但Git并没有规定分支的含义，大部分小型或者个人项目，基本只需要master, dev分支就足够了。但当项目复杂度提高，人员增多时，管理不当dev就会频繁的出现代码冲突，功能无法分割的问题。

GitFlow：原理就是给各分支赋予含义，让分支管理变得更加清晰，每个分支有自己的使用场景和主要职责。

1 2	PS：GitFlow的使用，一定要让团队内部人员，对分支的理解达成一致。

Production：是我们经常使用的master分支，这个分支最近发布到生产环境的代码，最近发布的release，这个分支只能从其他分支合并，不能在这个分支直接修改；
Develop：这个分支是主开发分支，包含所有要发布到下一个release的代码，这个分支主要用于合并其他feature分支代码；
Feature：这个分支主要是用来开发一个新的功能，开发测试完成后，将其合并回develop分支，进入下一个release；
Release：当你需要发布一个Beta测试版时，将develop分支合并到release分支，完成测试和修复后，将release合并到master和develop分支；
Hotfix：当我们在Production发现新的Bug时候，我们需要创建一个hotfix分支, 完成hotfix后，将其合并到master和develop分支；

1 2	PS：在实际应用中可根据项目复杂程度简化掉release分支。

打包命名： v1.0.0.19
使用场景：
- 对项目框架，构建等全局性修改的，可直接在develop修改；
- master的hotfix修改，需合并到develop；
- feature测试通过后，需合并到develop进行集成测试；
打包前：需先合并master分支合并到develop
测试通过后： 合并回master并重新执行集成测试；

打包命名： 1.0.0
使用场景：
- 通过develop集成测试，且要发版上线时，将develop集成测试通过的版本，合并到master分支打包发版。
- 线上有BUG热修复时，创建hotFix分支，修复bug并合并回master分支打包发版。