git团队协作gitflow管理模型详解

gitflow分支管理模型

序号	分支名称	分支管理	功能描述	是否使用
1	master	持续集成，代码总是稳定的  命名规则： master分支只有一个，名称即为master	master-主分支，用于产品发布仅是一些关联的tag， 禁止直接在master分支进行修改。	是
2	develop	持续集成，开发代码持续集成 命名规则： develop分支只有一个，名称即为develop	汇总开发者完成的工作成果，develop分支上的产品可以是缺失功能模块的半成品，但是已有的功能模块不能是半成品。develop分支只能通过与其他分支合并来更新内容，禁止直接在develop分支进行修改。	是
3	release	继承分支：develop合并分支：develop master命名规则：release-<版本号>eg: release_v1.0.0	当 develop分支上的项目准备发布时，从develop分支上创建一个新的release进行测试 进行质量测试、bug修复、文档生成等面向发布的任务，一旦创建不能再添加功能。 测试完成后务必同时合并到develop和master。 版本号命名规范正常功能开发修改为X.1.X 更改中间一位 bug修复修改为X.X.1 更改最后一位 大版本更替修改2.0.0 第一位	 
4	feature	继承分支：develop合并分支：develop命名规则：feature-<版本号/时间>-<功能名>	用于日常的功能开发 一般一个功能分支代表一个功能 当一个功能开发完，合并到develop	是
5	hotfix	继承分支：master合并分支：develop master命名规则：hotfix-<版本号/时间>-<问题简述>	用于修复线上的bug或小粒度修改 从master分支上创建一个新的hotfix分支，并在hotfix分支上进行bug修复。 修复完成后，需要将hotfix分支合并到master分支和develop分支，并为master分支添加新的版本号tag，最后删除hotfix分支。	是

 

开发流程

一:新建分支

 每次开发新功能，都应该新建一个单独的分支 # 获取主干最新代码 $ git checkout develop $ git pull

# 新建一个开发分支myfeature $ git checkout -b feature/20190617_login

二:提交到本地

 功能完成一部分，或一天工作结束 $ git add . $ git commit -m some_comment

三:开发完毕部署到测试

 代码开发完毕，部署到测试时，同步develop分支最新代码 #拉取最新远程分支代码，但不合并 $ git fetch origin #本地分支rebase远程develop分支 $ git rebase origin/develop 打包部署到测试服务器

四:测试完毕，合并commit，推送到远程

 保持develop分支的整洁，develop不需要知道每个分支的提交细节 推送到远程develop分支前，最后一个rebase. 合并之前使用git log会看到多次commit记录 #拉取最新远程分支代码，但不合并 $ git fetch origin #本地分支rebase远程develop分支 $ git rebase -i origin/develop

出现提交记录页面，将除了第一行的pick之外的pick改为s. wq保存退出，弹出commit注释页面，编辑后点击退出。 此时git log，之前的多次提交变为一次提交。

#推送到远程 $ git push --set-upstream origin feature/20190617

五：提交合并请求

 网页端发起merger request，将自己的分支提交请求合并到develop分支，由特定的人review，并合并。

注参考资料：jekins可选择分支构建（https://www.cnblogs.com/yanghaotai/p/9927843.html）