目前团队比较小,在协作开发中,对git的操作并没有一套规范.以至于我们在开发中,分支命名比较随意,测试/上线分支也没有明确的规范.提交的message也是随心所欲.以至于在合并分支部署时经常性的出现冲突,查看提交的日志也是比较随意,不能让其他维护者一目了然的了解代码的变化或者被修改的原因.

     基于以上的一些弊端,参考网上的git规范文档,我们整理出一套git操作命名规范以及开发流程. 希望大家以此为准绳,统一git命名以及操作规范,提高协同开发的效率.

分支类型和命名

1. 常设分支

git版本库的两条主要的分支: master和develop .

master分支

• master分支由版本库初始化后自动创建,主要用于部署生产环境的分支,要确保master分支的稳定性

• master分支一般由develop以及hotfix分支合并,任何时间都不能直接修改代码

• master分支只能管理员可以进行push操作, 他人若要合并分支到master需要提merge request由管理员进行code review之后再合并

develop分支

• develop为开发分支, 始终保持最新开发完成以及bug修复后的代码

• 一般开发新的功能时, feature分支都是基于develop分支创建的

2. 临时性分支

功能分支 feature

• 开发新功能时,从develop分支上切出feature分支

• 分支命名规范: feature/开头,后面跟有意义的新功能名或模块名,如: feature/user_management(用户管理需求)、feature/power_manangement(电源管理)

• 如果多人共用一个功能分支,那么本地代码push之前一定要经过自测,至少保证主流程走通,页面正常访问.

测试分支 test

• 当feature/XX分支开发完成后，合并代码到test分支并部署到测试环境，进入测试阶段

• 若测试的过程中存在bug需要修复，则由开发者在其功能分支feature/XX进行修复并合并到test分支回归测试

• 当测试通过后，需要将功能分支feature/XX合并到develop分支进行回归测试

• 测试分支test可能同时合并了多个开发分支feature/XX，不同的开发需求可能上线时间不一样，所以test分支不可以直接合并到到develop

修复分支 hotfix

• 如果线上出现紧急问题，需及时处理时，则需要修复分支hotfix进行bug修复

• 分支命名规范：hotfix/xxx，命名规则和feature类似

• 修复分支需从master主分支上创建，修复完成后，需要合并到develop和master分支

常用操作

1. 新增功能

当接到一个新需求，需要新建分支，开发需求，提交代码

(master)$: git pull                           # 基于master分支 创建新分支之前 拉最新代码(feature/xxx)$: git checkout -b feature/xxx   # 创建新的功能分支# coding...(feature/xxx)$: git add -A                    # 即将提交代码 将修改，删除和新增的文件存放在暂存区(feature/xxx)$: git commit -m '提交内容描述'    # 将暂存区代码添加到本地仓库中(feature/xxx)$: git push origin feature/xxx   # 将本地分支版本上传到远程仓库

注意： git add .和git add -A的区别 前者包括内容修改和新增但不包括删除 后者是所有

2. 合并到测试分支

当需求开发完成后，需要合并到测试分支

(feature/xxx)$: git checkout test             # 将当前功能分支 切换到测试分支(test)$: git pull origin test                 # 拉去test分支最新代码(test)$: git merge feature/xxx                # 将功能分支合并到测试分支# 若有冲突 需要现在本地解决完所有冲突(test|MERGING)$: git add -A                   # 将刚才修改的文件存放到暂存区(test|MERGING)$: git commit -m '解决文件冲突..' # 将暂存区代码添加到本地仓库中(test|MERGING)$: git push origin test         # 将本地分支版本上传到远程仓库# 若没有冲突 直接push到远程仓库(test)$: git push origin test                 # 将本地分支版本上传到远程仓库

3. 其他常用操作

$: git clone xxxxx.git                        # 从远程代码库克隆代码到本地(develop)$: git status                        # 显示当前修改的文件(develop)$: git branch                        # 查看本地分支(develop)$: git branch -r                     # 查看远程分支(develop)$: git checkout [文件名]/.            # 文件还在工作区 这个命令可以还原指定的文件/所有修改的文件(不包括新增的文件)(develop)$: git log                           # 查看当前分支的版本历史 可以查看提交记录的[HEAD]和[message](develop)$: git diff [文件名]                  # 显示指定文件修改前后的差异 不指定文件名则显示所有修改的文件的差异

注意：

git fetch是将远程主机的最新内容拉到本地，用户在检查了以后决定是否合并到工作本机分支中。

而git pull 则是将远程主机的最新内容拉下来后直接合并，即：git pull = git fetch + git merge，这样可能会产生冲突，需要手动解决。

git是目前最流行的版本控制工具，书写良好的commit message能大大提高代码维护的效率。不仅可以作为版本发布日志的一个重要参考，也让以后的维护者更清晰的了解当前代码变化的原因。

1. 用什么规范

现在市面上比较流行的方案是约定式提交规范（Conventional Commits），它受到了Angular提交准则的启发，并在很大程度上以其为依据。约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于创建清晰的提交历史的简单规则；在提交信息中描述新特性、bug 修复和破坏性变更。它的 message 格式如下:

<类型>[可选的作用域]:<描述>[可选的正文]

2. 怎么用

我们约定，提交message时的格式为：<类型>[可选的作用域]:<描述>

Type<类型>说明：

• feat: 添加新特性

• fix：修复Bug

• style: 仅仅修改了样式

• refactor: 代码重构

其中：feat和fix最为常用

类型为必填项

Scope[作用域]:

作用域填写此次代码修改的范围，比如修改的user模块, account模块等等，作用域非必填

disc<描述>:

描述主要的变更内容，如果是feat可以写需求的标题，如果是bug可以描述一下具体解决了什么问题。

内容一定是有意义的描述，禁止使用aaaaa 提交代码等等这类没有意义的描述

举例说明：

(feature/xxx)$: git commit -am 'feat[user]: 用户中心增加头像上传功能'# 或者(feature/xxx)$: git commit -am 'fix: 修复了用户上传头像失败的bug'

对于前端来说，如果日常开发中缺少对commit message的约束，会导致填写的内容随意，质量参差不齐，可读性差。除了我们约定的规范靠自觉遵守之外，可以引入插件工具，进行commit message格式校验，并结合git hook在提交代码时进行格式校验，不满足条件禁止commit。具体的校验工具和配置方法可以自行搜索。

可根据这几个关键词搜索响应的文档：

commitizen & cz-conventional-changelog

commitlint & husky

多人在同一代码仓库开发时，会经常遇到代码冲突的问题，所以，好的操作习惯可以尽量去减少不必要的代码冲突。

具体的操作流程参考如下:

• 新建分支之前，一定要先pull最新的代码，然后再创建分支

• commit之前，要先将代码add到暂存区，以免代码没有被提交

• commit之后，要先pull一下当前分支的最新代码(如果多个人公用一个分支开发)

• 如果要将当前分支合并到分支B，先要切到分支B，pull最新的代码再合并

• 合并分支如果有冲突，必须先再本地解决完冲突，再add和commit代码

• 最后再进行push

总之，不管是提交代码还是合并代码，push之前，都要先pull一下，确保当前分支是最新的代码。

最后欢迎访问我们的微信小程序【前端面试题宝典】，我们将继续持续更新前端面试题。