谈一谈开发中git版本管理方式

参考git flow管理方式。

说明

涉及到的主要版本，master，dev及v(x)分支，其他分支均为临时分支，开发完毕并merge到master后，应及时删除分支。

master: 一定是线上上线版本，merge其他代码要慎重，要有merge request及code review。

dev: 自测版本，名称可自由定义，开发的某个feature，merge到该分支上，在开发机上进行自测。

v(x):提测版本，名称可自由定义，待提测的版本都需要merge到该分支上，可能包含多个feature同时提测，在测试机上由测试同学进行测试。

feature(x):功能分支，名称可自由定义，经过自测，提测，bug修改的多轮迭代，确认自己开发的分支无问题后，merge到master上线。

hotfix:紧急修复分支，名称可自由定义，紧急修复线上bug，修复后简单自测，无问题后merge到master上线修复。

为什么要分支管理(Why)？

开发过程中，分支管理太乱，如果只有大版本管理，如v(x)，dev，上线时一般是将v(x) merge进master进行上线，但此时有些feature可能并不想上线，导致线上代码会包含一些新feature，影响稳定性。

原则

1. v(x)、dev只能merge master代码，不能将这两个分支的代码merge到master。
2. 新feature分支的branch，一定要由master检出，遵循包含最少代码原则。这两条原则都是为了保证上线代码不要包含多余的feature。
3. hotfix一定要从master分支检出，并保证fix上线的代码同步merge进dev和v(x)。
4. 已经merge进master分支并上线的feature分支要及时删除。

问题

1. 如果有多个feature需要上线，怎么办？
   多个分支merge进某个分支如feature1，然后将feature1 merge进master进行上线。

欢迎大家评论和补充不足的地方！