一个简单的git开发流程

版本管理迁移

最近将手上svn的一些服务版本管理迁移到git库管理，下面简要描述一下使用的Git工作流程。

主分支

在开发中，始终保证有两条最基本的分支：

• master
• dev

origin/master

服务在正式环境发布使用的tag全部从origin/master拉取，master分支应当禁止开发人员使用命令行进行代码提交，只能从其他分支发起Merge Request，全员Code Review通过后进行合并。

origin/dev

平时使用这条分支进行日常开发，服务发布前，将该分支上的改动合并至origin/master。

dev-master-tag开发流程

紧急修复

服务有时候会出现线上bug，或者产品提的一些需要紧急修改发布的改动，此时我们可以使用另一条专用分支

• hotfix

基本步骤如下

1. 从master拉取hotfix分支
2. 在hotfix分支上进行修复
3. 将hotfix分支的改动merge到master
4. 从master拉取Tag，进行服务发布
5. 记得也要将hotfix上的改动merge到dev分支

hotfix修复流程

Simple and Stupid

git工作流程的话，其实还有很多业界标准的模式，包括feature分支的引入等等，但是如果一个服务的开发人员不是太多，1-2人的话，上述简单的工作模型已经可以满足需求，过于复杂效果反而适得其反，包括git的一些指令运用，在svn切换到git的初期，也尽量保持简单为佳，基本的commit、pull、push、merge已经够用了。

服务上正式环境之前，可以开放master的代码提交权限，直接在master上开发，上到正式环境之后再进行dev分支开发，这样比较方便。