亲师友|git使用研发流程（企业新手git使用实例教程）

• 环球腕表资讯

1. Git Flow 实体模型

 


Git 流程使用规范

 

(图片出处：A successful Git branching model)

2. Git Flow 分支表明

Master

发版分支 维护分支。功能代码在 Release 分支上测试通过、或 BUG 已经在 Hotfix 分支上修补，就需要将代码合并到 Master 分支。代码合并到 Master 分支，即意味着随时都可以发版，发版成功时必须根据 Master 分支里的全新递交连接点打 Tag。

Hotfix

修补分支 临时性分支。网上发生应急 Bug 时，必须根据相匹配版本 Tag 创建修补分支，难题修补结束时为此分支开展提测。难题修补后，需在代码合并到 Develop 和 Master 分支。

根据发版 Tag 创建，最终合并到 Develop 和 Master 分支。

Release

预发布分支 临时性分支。功能开发设计进行并合并到 Develop 分支时，根据 Develop 分支创建 Release 分支开展提测 。Release 分支中出现危害发版的 Bug 时，必须创建 Feature 分支改动 Bug;当测试通过后，需在代码合并到 Develop 和 Master 分支。

根据 Develop 分支创建，最终合并到 Develop 和 Master 分支。

Develop

开发设计分支 维护分支。多人协作开发设计后的代码合并总分支，功能分支向 Develop 分支合并时，通常会有 CodeReview 步骤。

根据 Master 分支创建。

Feature

功能分支 临时性分支。有潜在需求时，根据最新 Deveop 分支创建功能分支，功能开发设计结束时，需在代码合并到 Develop 分支。

根据 Develop 分支创建，最终合并到 Develop 分支。

3. Tag&Branch 的差别

Tag 和 Branch 类似，全是引入换句话说者表针。在工程里 .git/refs 目录下可以很清楚的见到，每个 Tag 和 Branch 所说向的递交节点 SHA-1 值。

差别：

Tag：Tag 位置是不变的，在为特定递交做好标识之后，他就固定在此部位

Branch：Branch 位置会持续变化的，伴随着分支的往前变化或向后回退，都是在随时变化

最好使用 Tag，储存代码精彩片段。

1. Commit Message 文件格式

():

<空白行>

 

<空白行>

 

 

能够得知分成三个部分，头顶部、行为主体、底端。

头顶部

():

type 种类，改动的种类等级：

feat：新功能(feature)

fix：修复 bug

docs：文本文档(documentation)

style： 文件格式(不受影响代码运转的变化)

refactor：重新构建(即并不是新增加功能，并不是改动 bug 的代码变化)

test：提升检测

chore：搭建全过程或辅助软件的变化

scope 改动范畴：

通常是此次改动涉及的一部分，最好是简单归纳

subject 改动的小标题：

通常是实际改动的功能点

body：关键对此次 commit 的详细说明，能够分为多做。

footer：关键摆放兼容问题变动和 Issue 取消的信息内容。

为了更好地代码的高效递交，body 和 fotter 一部分能够省去。

2. 应用详细介绍

需求开发或是改动 Bug 时，递交代码时应加上相匹配 Jira 序号：

git commit -m "feat(CHESS-1217): 个人中心提升共享通道及共享功能开发设计"

改动 Bug 时，必须指出改动代码所属控制模块：

git commit -m "fix(共享): 改动修改一部分手机共享高清大图为空难题"

并没有实际控制模块、或是多模块代码一起递交时，可以使用别的递交方法：

git commit -m "fix(BUG): 改动消息推送小红点提醒逻辑性"

3. 有关专用工具

Git Hook 自定阻拦脚本制作：commit-msg

使用场景：python3.7

使用方法：

开启工程项目目录下的 .git/hooks 文件夹

将 commit-msg 脚本制作拷贝到文件夹下，就可以

全局性设定：利用下面方法，可全局性设定，每一次 git clone 时，全自动将 commit-msg 脚本制作导入到工程项目的 hooks 清单中：全局性设定 commit-msg。

别的专用工具：

Commitizen：协助编写达标 Commit message 的一种手段

Commitlint：Commit message 标准校检专用工具

4. 扩展

GitLab 与 Jira 关系

实际效果：Git Commit 时，在 message 里边加上订单号，可以从 Jira 相匹配订单宝贝详情查询到此次递交。

配备：官方文档。

1. 审查阶段

代码审查出现于 Feature 分支向 Develop 分支合并的过程当中：

 


Git 流程使用规范

 

(图片出处：ProcessOn 模版)

2. 代码评审流程

 


Git 流程使用规范

 

不一样的颜色块，意味着不一样角色

创建一个 Merge Request 能够进行数次 Push

开发者促进全部代码评审流程的落实，包括及时联系成员审查代码、通告小组长合并代码等

3. 维护分支设定

在 GitLab 开启要设定的工程项目 (Maintainers 人物角色)，挑选 Setting -> Repository -> Protected Branches：

 


Git 流程使用规范

 

将 master 和 develop 分支设为维护分支，也只能是 Maintainers 人物角色 能够合并要求，而且严禁立即 push 代码。

 


Git 流程使用规范

 

通过上述设定以后，全部代码只能依靠创建 Merge Request 的形式合并到 develop 和 master 分支;为了能代码库的安全性，必须回收利用 Maintainers 管理权限，除小组长以外开发者全是 Developer 管理权限。

4. Merge Request

1. 创建 Merge Request

开启 Project -> Merge Requests -> New merge request，挑选分支创建合并要求：

 


Git 流程使用规范

 

挑选源分支，必须合并的代码所属的分支

挑选总体目标分支，将全新代码合并过的分支

2. 填好必需信息内容

 


Git 流程使用规范


Git 流程使用规范

 

Title：简易汇总此次 Merge 的改动点

Description：详细说明修改内容，影响程度等

Assignee：受托人，挑选具备Maintainers 角色的成员，该成员会收到合并请求的邮件通知，最后由该成员合并请求

{n}{t}

{n}{t}{t}Approvers：一般选择小组成员，小组成员具有审核代码权限，对不合格代码可以要求开发者修改

{n}{t}

{n}{t}{t}分支选择，功能分支向 develop 分支合并时，会有删除源分支选项，建议勾选

{n}{t}

{n}{t}{t}针对本次合并的提交，一次合并请求可以包含多次提交

{n}{t}

{n}{t}{t}3. 代码评审及合并请求

{n}{t}

{n}{t}{t}{p}

{n}{t}

{n}{t}{t}Git 流程使用规范
{n}{t}
{n}{t}{t}Git 流程使用规范
{n}{t}

{n}{t}{t}{p}

{n}{t}

{n}{t}{t}只有评审成员评审通过时，合并按钮才会高亮，才能合并代码

{n}{t}

{n}{t}{t}参与代码评审的成员，认为代码没有问题时，可点击该按钮

{n}{t}

{n}{t}{t}针对当前代码创建的讨论，有讨论存在时，开发者需要及时解决

{n}{t}

{n}{t}{t}如果代码有问题，可直接创建一个讨论，即 3 列表会增加，开发者修改之后可点击 5 关闭讨论

{n}{t}

{n}{t}{t}代码修改之后，或者不需要修改，点击关闭讨论

{n}{t}

{n}{t}{t}5. 其他注意事项

{n}{t}

{n}{t}{t}1. 提交合并请求时，先同步最新代码

{n}{t}

{n}{t}{t}提交合并代码前，建议先执行 git fetch 和 git merge/rebase 将 develop 分支下的最新代码更新到开发分支，再提交合并请求，避免造成冲突。

{n}{t}

{n}{t}{t}2. 合并代码到 master 分支

{n}{t}

{n}{t}{t}通过 d

Git 流程使用规范

Git 流程使用规范

Git 流程使用规范

Git 流程使用规范

Git 流程使用规范

Git 流程使用规范

Git 流程使用规范

Git 流程使用规范

原创文章，作者：leping，如若转载，请注明出处：https://www.wxymghbl.com/hq-4164.html

赞 (0)
上一篇 2022年11月13日 上午7:40
下一篇 2022年11月13日 上午10:39

相关推荐