一文读懂Git工作流

Git是目前最流行的代码管理工具，相信大家也都是在用Git来管理自己团队的源代码。

团队一般为了规范开发，保持良好的代码提交记录以及维护 Git 分支结构清晰，方便后续维护等，都会迫切需要一个比较规范的 Git 工作流。

本文就是在这个背景下诞生的，如果你的团队正好有此需求，那你可以看一下，希望本文能给大家提供一些帮助，建立良好的团队代码流程规范。

本文的目录如下

• Git主要优点
• Git分支管理
• Git日志规范
• Git Flow工作流
• Git Flow实战

Git主要优点

• 分布式存储，本地仓库包含了远程仓库的所有内容。
• 安全性高，远程仓库文件丢失了也不怕。
• 优秀的分支模型，创建/合并分支都非常快速便捷。

Git分支管理

我们在实际工作中会创建很多分支以便于不同场景下的开发，但是如果没有分支规范就会造成分支杂乱，大家往往也搞不清楚某一个分支是在做什么，下面我们就介绍一下我们常用的并且推荐大家使用的分支类型。

Git分支类型

master 分支

• master 为产品主分支，该分支为只读唯一分支，也是用于部署生产环境的分支，需确保master分支的稳定性。
• master 分支一般由release分支或hotfix分支合并，任何情况下都不应该直接修改master分支代码。
• 产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签（tag）做记录，方便追溯。
• master 分支不可删除。

develop 分支

• develop 为主开发分支，基于master分支创建，始终保持最新完成功能的代码以及bug修复后的代码。
• develop 分支为只读唯一分支，只能从其他分支合并，不可以直接在该分支做功能开发或bug修复。
• 一般开发新功能时，feature分支都是基于develop分支下创建的。
• develop 分支包含所有要发布到下一个release的代码。
• feature功能分支完成后, 开发人员需合并到develop分支(不推送远程)，需先将develop分支合并到feature，解决完冲突后再合并到develop分支。
• 当所有新功能开发完成后，开发人员并自测完成后，此时从develop拉取release分支，进行提测。
• release或hotfix 分支上线完成后, 开发人员需合并到develop分支并推送远程。
• develop 分支不可删。

feature 分支

• feature 分支通常为新功能或新特性开发分支，以develop分支为基础创建feature分支。
• 分支命名: feature/ 开头的为新特性或新功能分支，建议的命名规则: feature/user_createtime_feature，例如：feature/ftd_20201018_alipay，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付的功能分支。
• 新特性或新功能开发完成后，开发人员需合到develop分支。
• feature 分支可同时存在多个，用于团队中多个功能同时开发。
• feature 分支属于临时分支，功能完成后可选删除。

release 分支

• release 分支为预上线分支，基于本次上线所有的feature分支合并到develop分支之后，从develop分支创建。
• 分支命名: release/ 开头的为预上线分支，建议的命名规则: rele