1、企业场景
先看下方聊天界面：
程序员-小播内心OS：今天是第一天来传智上班领导要考验我 阅读文档 和 总结文档 的能力，并且只是发了一个截图，那我可以发挥下我高超的 编写文档 能力啦！
那我需要好好加油啦。
2、解决思路
接下来我准备以下方步骤来梳理：
1、打开老大给我的图，梳理里面整体的流程
2、打开代码对比和流程图是否匹配
3、在以企业开发流程梳理其中重要需要注意的节点
4、总结传智教育公司git使用规范
3、动手实践
先打开老大发我的图，开始梳理：
详细梳理开始：
从整体上看公司的代码存在 **四大分支 **结构，分别为 Master、Dev、Feature、Hotfix 分支。
| 分支 | 说明 |
|---|---|
| Master | 代码的主分支，存放稳定代码的保护分支，不允许开发人员随意合并 |
| Dev | 日常开发分支，这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了 |
| Feature | 新功能分支 |
| Hotfix | bug修复分支 |
下面我以 开发、提测、部署、紧急bug 梳理对应的场景流程。
3.1、日常开发流程
背景：
1、传智上海员工A、B 开发功能1
2、传智北京员工C、D 开发功能2
基于上述时序图步骤如下：
- 基于Master稳定分支（运营一段时间稳定代码） 先打 标签tag ，如V 5.0
- 从tag：5.1 开始开发，从Master分支 merge合并到 Dev 分支
- 程序员 A和B 基于Dev 分支创建 feature1 分支
- 程序员 C和D 基于Dev 分支创建 feature2 分支
- 程序员 A和B 协同开发，feature1 开发完毕，完成自测
- 自测完毕后，将 feature1 分支合并到 Dev 分支
- 程序员 C和D 协同开发，feature2开发完毕，完成自测
- 自测完毕后，将 feature2 分支合并到 Dev 分支
- 程序员 A、B、C、D发邮件提交测试组做功能测试
3.2、代码提测流程
测试组：小黑上线！
- 小黑收到邮件，开始测试新功能代码
- 测试 feature1 功能对应的出现的bug 提交至 Jira（bug管理及追踪平台）并执行 程序员 A和B
- 程序员 A和B 收到指定的 bug后，开始修复bug
- 测试 feature2 功能对应的出现的bug 提交至 Jira（bug管理及追踪平台）并执行 程序员 C和D
- 程序员 C和D 收到指定的 bug后，开始修复bug
- 修复完成后，完成 V5.1 全功能提测
- 全功能提测完成后，将Dev分支代码合并到Master分支
3.3、代码部署流程
代码完成的后部署，一般都是 有 持续集成（流水线） 完成，代码只要提交到git项目会自动部署。具体流程后期分享！
- 持续集成部署发版，待功能完善后，需要打包发版-- V5.1
- 代码上线后，整体做一次完整测试，完成后开始打包发版
- 打包发版一般可以手动操作，或者也可以交由流水线操作都可以
3.4、线上出现紧急bug流程
正在此时，小播突然接到一个电话说有个很严重的问题需要紧急修补。
你将按照如下方式来处理：
- 切换到你的线上分支 V5.1（production branch）。
- 为这个紧急任务基于V5.1 新建一个Hotfix分支，并在其中修复它。
- 在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上Master分支。
- 代码上线后，整体做一次完整测试，完成后开始打包发版 V5.1.1
- 切换回你最初工作的分支上，继续工作。
4、企业规范建议
4.1、提交日志编写规范建议
在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。
编写良好的Commit messages可以达到3个重要的目的：
- 加快review的流程
- 帮助我们编写良好的版本发布日志
- 让之后的维护者了解代码里出现特定变化和feature被添加的原因
目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。如下图：
Commit messages的基本语法
具体格式为:
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
- type: 本次 commit 的类型，诸如 bugfix docs style 等
- scope: 本次 commit 波及的范围
- subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点 1. 使用祈使句，是不是很熟悉又陌生的一个词，来传送门在此 祈使句 2. 首字母不要大写 3. 结尾无需添加标点
- body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |
- footer: 描述下与之关联的 issue 或 break change
Type的类别说明：
- feat: 添加新特性
- fix: 修复bug
- docs: 仅仅修改了文档
- style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
- refactor: 代码重构，没有加新功能或者修复bug
- perf: 增加代码进行性能测试
- test: 增加测试用例
- chore: 改变构建流程、或者增加依赖库、工具等
Commit messages格式要求
标题行：50个字符以内，描述主要变更内容
主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
* 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
* 他如何解决这个问题? 具体描述解决问题的步骤
* 是否存在副作用、风险?
如果需要的化可以添加一个链接到issue地址或者其它文档
4.2、分支规范建议
master 分支
- master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性
- master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码
develop 分支
- develop 为开发分支，始终保持最新完成以及bug修复后的代码
- 一般开发的新功能时，feature分支都是基于develop分支下创建的
feature 分支
- 开发新功能时，以develop为基础创建feature分支
- 分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module
release分支
-
release 为预上线分支，发布提测阶段，会release分支代码为基准提测
当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。
如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。
hotfix 分支
- 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
- 线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支
4.3、标签tag规范建议
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
建议：
- 标准的版本号必须（MUST）采用 X.Y.Z 的格式，其中 X、Y 和 Z 为非负的整数，且禁止（MUST NOT）在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须（MUST）以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
- 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版
- 修订号 Z（x.y.Z | x > 0）必须（MUST）在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。
- 如果一天下来发版打标签很多次，那么就可以在修订号后添加到前日期作为区分
公司完整代码进行比对验证
1029
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
