版本管理迁移
最近将手上 svn 的一些服务版本管理迁移到 git 库管理, 下面简要描述一下使用的 Git 工作流程.
主分支
在开发中, 始终保证有两条最基本的分支:
- master
- dev
- origin/master
服务在正式环境发布使用的 tag 全部从 origin/master 拉取, master 分支应当禁止开发人员使用命令行进行代码提交, 只能从其他分支发起 Merge Request, 全员 Code Review 通过后进行合并.
origin/dev
平时使用这条分支进行日常开发, 服务发布前, 将该分支上的改动合并至 origin/master.
dev-master-tag 开发流程
紧急修复
服务有时候会出现线上 bug, 或者产品提的一些需要紧急修改发布的改动, 此时我们可以使用另一条专用分支
hotfix
基本步骤如下
从 master 拉取 hotfix 分支
在 hotfix 分支上进行修复
将 hotfix 分支的改动 merge 到 master
从 master 拉取 Tag, 进行服务发布
记得也要将 hotfix 上的改动 merge 到 dev 分支
hotfix 修复流程
Simple and Stupid
git 工作流程的话, 其实还有很多业界标准的模式, 包括 feature 分支的引入等等, 但是如果一个服务的开发人员不是太多, 1-2 人的话, 上述简单的工作模型已经可以满足需求, 过于复杂效果反而适得其反, 包括 git 的一些指令运用, 在 svn 切换到 git 的初期, 也尽量保持简单为佳, 基本的 commit,pull,push,merge 已经够用了.
服务上正式环境之前, 可以开放 master 的代码提交权限, 直接在 master 上开发, 上到正式环境之后再进行 dev 分支开发, 这样比较方便.
来源: https://www.qcloud.com/developer/article/1159949