Git Flow 分支管理简述

概述

Git 是什么

Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Git 与经常使用的版本控制工具 CVS, Subversion 等不一样，它采用了分布式版本库的方式，没必要服务器端软件支持。

Git 有哪些特性

• 直接记录快照，而非差别比较
• 多数操做仅添加操做
• 近乎全部操做都是本地执行
• 时刻保持数据完整性

有关以上特性的详细解释，请查看Pro Git的Git基础章节。

为何要使用 Git

• 可以对文件版本控制和多人协做开发。
• 拥有强大的分支特性，因此可以灵活地以不一样的工做流协同开发。
• 分布式版本控制系统，即便协做服务器宕机，也能继续提交代码或文件到本地仓库，当协做服务器恢复正常工做时，再将本地仓库同步到远程仓库。
• 当团队中某个成员完成某个功能时，经过pull request操做来通知其余团队成员，其余团队成员可以review code后再合并代码。

Git Flow 简介

　　Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。

分支约定

　　Git Flow有主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；辅助分支组织为了解决特定的问题而进行的各类开发活动。

主分支

　　主分支是全部开发活动的核心分支。全部的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和develop分支。

master 分支

• master分支存放的是随时可供在生产环境中部署的稳定版本代码
• master分支保存官方发布版本历史，release tag标识不一样的发布版本
• 一个项目只能有一个master分支
• 仅在发布新的可供部署的代码时才更新master分支上的代码
• 每次更新master，都需对master添加指定格式的tag，用于发布或回滚
• master分支是保护分支，不可直接push到远程仓master分支
• master分支代码只能被release分支或hotfix分支合并

develop 分支

• develop分支是保存当前最新开发成果的分支
• 一个项目只能有一个develop分支
• develop分支衍生出各个feature分支
• develop分支是保护分支，不可直接push到远程仓库develop分支
• develop分支不能与master分支直接交互

辅助分支

　　辅助分支是用于组织解决特定问题的各类软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工做以及对生产代码的缺陷进行紧急修复工做。这些分支与主分支不一样，一般只会在有限的时间范围内存在。

辅助分支包括：

• 用于开发新功能时所使用的feature分支
• 用于辅助版本发布的release分支
• 用于修正生产代码中的缺陷的hotfix分支

　　以上这些分支都有固定的使用目的和分支操做限制。从单纯技术的角度说，这些分支与Git其余分支并无什么区别，但经过命名，咱们定义了使用这些分支的方法。

feature 分支

使用规范：

• 命名规则：feature/*
• develop分支的功能分支
• feature分支使用develop分支做为它们的父类分支
• 以功能为单位从develop拉一个feature分支
• 每一个feature分支颗粒要尽可能小，以利于快速迭代和避免冲突
• 当其中一个feature分支完成后，它会合并回develop分支
• 当一个功能由于各类缘由不开发了或者放弃了，这个分支直接废弃，不影响develop分支
• feature分支代码能够保存在开发者本身的代码库中而不强制提交到主代码库里
• feature分支只与develop分支交互，不能与master分支直接交互

　　若有几个同事同时开发，须要分割成几个小功能，每一个人都须要从develop中拉出一个feature分支，可是每一个feature颗粒要尽可能小，由于它须要咱们能尽早merge回develop分支，不然冲突解决起来就没完没了。同时，当一个功能由于各类缘由不开发了或者放弃了，这个分支直接废弃，不影响develop分支。

release 分支

使用规范：

• 命名规则：release/*，“*”以本次发布的版本号为标识
• release分支主要用来为发布新版的测试、修复作准备
• 当须要为发布新版作准备时，从develop衍生出一个release分支
• release分支能够从develop分支上指定commit派生出
• release分支测试经过后，合并到master分支而且给master标记一个版本号
• release分支一旦创建就将独立，不可再从其余分支pull代码
• 必须合并回develop分支和master分支

　　release分支是为发布新的产品版本而设计的。在这个分支上的代码容许作小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。经过在release分支上进行这些工做可让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

　　当develop分支上的代码已经包含了全部即将发布的版本中所计划包含的软件功能，而且已经过全部测试时，咱们就能够考虑准备建立release分支了。而全部在当前即将发布的版本以外的业务需求必定要确保不能混到release分支以内（避免由此引入一些不可控的系统缺陷）。

　　成功的派生了release分支，并被赋予版本号以后，develop分支就能够为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本以后发布的版本。版本号的命名能够依据项目定义的版本号命名规则进行。

hotfix 分支

使用规范：

• 命名规则：hotfix/*
• hotfix分支用来快速给已发布产品修复bug或微调功能
• 只能从master分支指定tag版本衍生出来
• 一旦完成修复bug，必须合并回master分支和develop分支
• master被合并后，应该被标记一个新的版本号
• hotfix分支一旦创建就将独立，不可再从其余分支pull代码

　　除了是计划外建立的之外，hotfix分支与release分支十分类似：均可以产生一个新的可供在生产环境部署的软件版本。

　　当生产环境中的软件遇到了异常状况或者发现了严重到必须当即修复的软件缺陷的时候，就须要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工做。

　　这样作的显而易见的好处是不会打断正在进行的develop分支的开发工做，可以让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工做。

使用规范

全部使用了本规范的项目，必须严格规范操做，不然不予以合并代码、提测、打包上线等后续操做。

基本要求

• 全部commit必须有注释，内容必须简洁明了的描述本次commit涵盖了哪些内容。严禁注释内容过于简单或不能明确表达提交内容的！
• 合理控制提交内容的颗粒度，一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。
• 正确为每一个项目设置Git提交用到的user.name和user.email信息，以公司邮箱为准，不可随意设置以影响没法正确识别。 查看当前项目配置信息的命令：git config -l

版本号(tag)

• 版本号(tag)命名规则：主版本号.次版本号.修订号，如2.1.13。(遵循GitHub语义化版本命名规范)
• 版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码
• 对master标记tag意味着该tag能发布到生产环境
• 对master分支代码的每一次更新(合并)必须标记版本号
• 仅项目管理员有权限对master进行合并和标记版本号

项目权限

• Git权限分管理员、开发者、浏览者三种类型
• 浏览者只能浏览代码，无push、pull request等全部写权限
• 开发者拥有浏览、push非主分支、提交pull request工单权限
• 管理员拥有创建和管理Git项目、合并分支和代码、给master打tag版本号等权限

分支使用

• 每一个Git项目固定含有上述全部分支类型。主分支master和develop是保护分支，只能进行合并请求，均不可直接提交代码。
• 功能需求或常规Bug修复，请从develop拉取feature分支；线上紧急问题修复，请从master拉去hotfix分支。

代码提交

• 一个提交就表明解决一个问题
• 大问题适当地分解为多个小问题，以便每次小型提交都更易于理解
  
  

经常使用命令

WorkSpace:  工做区 

Index/Stage: 暂存区       "git add ." 命令解释:    把新建立文件(Untracked files 变成 Changes to be commited) 在暂存区域生成了快照，等待被提交

Repository:   本地仓库   git commit -m "提交到本地仓库"  (只有暂存区域的文件（即：文件状态为“Changes to be committed”）才会被提交 )

Remote:        远程仓库   git pull origin / git push origin  master:master   (推送本地仓库分支代码到远程分支)

注释格式

• 第1行，标题行，对提交的简要总结，长度不超过50个字符，用语采用命令式而非过去式
• 第2行，空行
• 第3行开始，正文内容，对改动的详细介绍），能够是多行内容，建议每行长度不超过72个字符
• 正文用于解释是什么和为何，而不是如何作
• 若是有对应的issue，则将issue的id或连接放在注释正文中
• 并不是强制全部提交都要求3行+格式的注释，但除非标题行内容就能清晰的描述提交内容，不然必须采用3行+的注释格式

为何要约定注释格式？ 1. 加快 Reviewing Code 的过程 2. 帮助咱们写好 release note 3. 5年后帮你快速想起来某个分支，tag 或者 commit 增长了什么功能，改变了哪些代码 4. 让其余的开发者在运行 git blame 的时候想跪谢 5. 其余小伙伴不会出现想抽你的冲动 6. 总之，一个好的提交信息，会帮助你提升项目的总体质量

看看 Linus Torvalds 在Linux项目上写的提交注释：https://github.com/torvalds/linux/commits/master以及 Linus Torvalds 关于提交注释的讨论：https://github.com/torvalds/linux/pull/17#issuecomment-5659933

推荐工具

• SourceTree SourceTree集成了Git Flow功能，能简单方便的操做和实现常规的工做流程。支持OSX和Windows平台。
• Git Flow 扩展 Git Flow模型提出者nvie写的Git命令集扩展，提供了极出色的命令帮助以及输出提示。支持OSX，Linux和Windows平台。参考：git-flow 备忘清单

参考资料

• 企业级开发：Gitflow Workflow工做流

• 在阿里 咱们如何管理代码分支

• Git 在团队中的最佳实践--如何正确使用Git Flow

• 基于git的源代码管理模型——git flow
• Git版本控制与工做流
• Git分支管理策略
• 经常使用 Git 命令清单
• git-flow 备忘清单
• 语义化版本 - GitHub起草的版本号命名规范
• 写好Git Commit信息的7个建议
• 写出好的 commit message
• 如何设置Git提交注释模板
• GIT版本团队内部操做规范