gitming_git打tag流程

大家好，我是考100分的小小码，祝大家学习进步，加薪顺利呀。今天说一说gitming_git打tag流程,希望您对编程的造诣更进一步.

背景

目前团队比较小,在协作开发中,对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。具体的校验工具和配置方法可以自行搜索。