阅读 454

git命名规范和协作开发流程

img

背景

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

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

分支管理

分支类型和命名

1. 常设分支

git版本库的两条主要的分支: masterdevelop .

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主分支上创建,修复完成后,需要合并到developmaster分支

常用操作

image-20210904213133442.png

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: 代码重构

其中:featfix最为常用

类型为必填项

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最新的代码再合并
  • 合并分支如果有冲突,必须先再本地解决完冲突,再addcommit代码
  • 最后再进行push

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

最后

本文原贴地址在我们的另一个掘金账号: git命名规范和协作开发流程

欢迎大家访问我们的小程序小程序前端面试题宝典(点我点我点点点我),里面已经搜集了600+常见的前端面试题的题目和答案,希望能够帮助正在面试路上的同学。

也欢迎访问我们近期更新的文章:

前端社招神策数据二轮面经

明略前端三面面经(技术二面+HR面)

字节跳动商业化前端面试面经

美团四轮面试面经

爱奇艺前端二面面经

同时欢迎关注我们团队另一个掘金账号:

掘金前端面试题宝典

参考资料

前端面试题宝典

前端git操作命名规范和协作开发流程

您必须知道的 Git 分支开发规范

前端项目git操作命名规范和协作开发流程

Git常用命令及方法大全

文章分类
前端
文章标签