git分布式版本控制系统（六）

目前世界上最先进的分布式版本控制系统

官方网址：https://git-scm.com

学习目标：

1 了解 git 前世今生
2 掌握 git 基础概念、基础操作
3 各种 git 问题处理
4 互联网常用 gitflow(工作流程规范)
5 git 代码提交规范
6 git 分支管理及命名规范

代码提交规范

Commit message

我们每一次提交必定是有特殊的行为，或是开发新功能、或是修复bug等等。我们针对不同的操作有如下的分类：
type 必填，commit 的类型
•feat: 开发新的功能
•fix: 修复bug
•refactor: 代码重构
•docs: 文档修改
•style: 代码格式修改, 注意不是 css 修改
•test: 测试用例修改
•perf: 改善性能
•build: 变更项目构建或外部依赖（例如scopes: webpack、gulp、npm等）
•chore: 其他修改, 比如构建流程, 依赖管理.
•revert: 代码回退
•而commit的格式也有标准格式:
•scope: commit 影响的范围, 比如: route, component, utils, build…
•subject: commit 的概述
•body: commit 具体修改内容
•footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接
scope 可选，表示影响的范围、功能、模块
subject 必填，简单说明，不超过 50个字
body 选填，用于填写更详细的描述
footer 选填，用于填关联issus,或BREAK CHANGE
要注意的几点：
1.每一次commit的message需要明确对应代码的功能，无效信息不会通过，如“添加适配文件”、“First commit”等
2.对于多余无效的commits需要压缩，如连续的相同commit messages的commits、连续的codecheck修改等
示例一：需要压缩成一条

正确示范

错误示范

分支管理及命名规范

项目分支

一般来说，互联网项目有上线分支，预上线分支，测试分支，开发分支等．
保证不同的分支做不同的事情，防止分支污染。

1. 上线分支(RELEASE/master)，是发布到线上的分支，以这个分支为准，其他分支都是以这个分支为基础拉取。
2. 预上线分支(preonline)，在预上线环境当中，防止出错的最后一道保证。
3. 测试分支(testing)，可能测试环境大家共用一套，所以把代码都merge到这里，然后发布。这样大家各自测试自己的，互不打扰。如果有多个测试 环境的话，直接使用开发分支测试也是可以的。
4. 开发分支(feature/{功能名称(下划线命名)}_ {用户名(全拼)})，从上线分支(RELEASE)拉取，根据需求修改的新分支。

分支规范

1. 测试分支以及预上线分支要定时清理，和上线分支同步。
2. 上线分支以及预上线分支，merge权限保证在少数人手里。merge的时候，需要检查提交以及对线上的影响。
3. 只能在开发分支修改代码，其他分支都是等着被merge.
4. 提交之前，需要保证和上线分支没有冲突。
5. 防止分支被污染，特别是受到测试分支污染。

流程规范之外

人是最难管理的，以及人是懒惰的。这些话是非常准确的，所以会遇到以下问题，还得需要解决。

1. 需求改动非常小，是不是还得走整体流程。
2. 紧急修复问题，是不是还得走整体流程。
   具体怎么做，每一个公司和组都有自己的做法，是不是都必须都得走一遍流程。但是，分支规范是必须的，不能随意修改。直接在上线分支修改，坚决说NO!