git之分支解说和提交规范-企业级（实习生一定要看）

入职没多久，因为git不会，犯错，被叼了，快来记载一波

1.通常大家入职的时候，都会去gitlab或者gitBucket，拉取一个分支，那么很多小伙伴其实都是懵的。别担心，这不有我讲解吗

1.首先，真的没什么，和往常逛gitee一样，打开给的地址，输入给的帐号密码就OK了。但是，接下来重头戏来了。

有的公司会说，让你fork一个工程从master，好家伙，这是什么玩意？其实是这样的

随便找一个gitee 看我标点的地方 点击

 直接确认我的宝，然后会看到以下页面

再然后点开个人主页，就会发现，好家伙 我的仓库多了这个项目，然后呢，你在公司也是如此，你操作的代码都是你fork出来的工程。简单一点，就是分身。但是，上面领导如果让你到哪个分支写代码，你也得在你fork的那个主工程进行切换分支。然后提交规范，下面说，但是提交完以后，你得点击pull Request

 

那么就可以将你写的代码请求合并到主分身去了。记住目标分支得和你提交的源分支一致，不要乱搞，不然你会被骂了

2.熟悉开发模式的规范

简称	全称
DEV	开发者调试使用
FAT	功能验收测试环境，用于测试环境下的软件测试者测试使用
UAT	用户验收测试环境，用于生产环境下的软件测试者测试使用
PRO	生产环境

3.了解了这些分支的名字，那么你在开发过程中，就不会那么迷惑了。但是这些的顺序又是怎么样的呢？

代码管理中常用的分支模型包括主分支（master）、预上线分支（release）、紧急修复分支（hotfix）、测试分支（develop）和需求开发分支（feature）。

主分支（master）是用于部署到正式环境（PRO）的主要分支，禁止直接在该分支上修改代码。一般情况下，主分支会合并来自预上线分支或紧急修复分支的代码。

预上线分支（release）是用于部署到预上线环境（UAT）的分支，始终保持与主分支一致。一般情况下，预上线分支会合并来自测试分支或紧急修复分支的代码。如果在预上线分支测试过程中发现问题，需要回归验证测试分支，看是否存在该问题。

紧急修复分支（hotfix）是用于紧急修复线上问题的分支，命名规则为 hotfix- 开头。当出现需要立即修复的紧急问题时，需要基于预上线分支或主分支创建紧急修复分支。修复完成后，将其合并至预上线分支或测试分支，并删除该分支。

测试分支（develop）是用于部署到测试环境（FAT）的分支，始终保持最新的完成和 bug 修复后的代码。根据需求的大小和程度，可以选择合并需求开发分支或直接在测试分支上进行开发。只有经过测试的代码才能够合并或提交至该分支。

需求开发分支（feature）是用于需求开发的分支，命名规则为 feature- 开头。一旦需求上线，会将其删除。

以上是一个常见的分支模型，接下来我会举几个开发场景来解释一下。

4.商品管理的迭代需求有以下流程：

1. 如果开发工时小于1天，直接在develop分支上进行开发。如果开发工时大于1天，则需要创建一个新的分支，在该分支上进行开发。

2. 开发完成后，准备提测时，需要先确认develop分支上不存在未测试完毕的需求。只有在这种情况下，研发人员才能将代码合并到develop（测试环境）供测试人员测试。

3. 测试人员在develop（测试环境）中完成测试后，研发人员将代码发布到release（预上线环境），供测试人员进行进一步的测试。

4. 测试人员在release（预上线环境）中完成测试后，研发人员将代码发布到master（正式环境），供测试人员进行最后的测试。

5. 当测试人员在master（正式环境）中完成测试后，研发人员需要删除该特性分支（feature-order）。

在修复测试环境、预上线环境和正式环境中出现Bug的过程中，流程与新需求加入的流程类似。

1. 如果修复工时小于2小时，可以直接在相应的环境中修复（develop或release或master）。

2. 如果修复工时大于2小时，则需要在相应的分支上进行修复。修复完成后，按照相同的流程进行提测和上线。

对于紧急修复正式环境中的Bug，有以下几种情况：

1. 如果release分支存在未测试完毕的需求，则基于master创建一个hotfix-xxx分支。修复完成后，发布到master进行验证。验证完毕后，将代码合并到release和develop分支，并删除hotfix-xxx分支。

2. 如果release分支不存在未测试完毕的需求，但develop分支存在未测试完毕的需求，则基于release创建一个hotfix-xxx分支。修复完成后，发布到release进行验证。验证完毕后，将代码合并到develop分支，并删除hotfix-xxx分支。

3. 如果release和develop分支都不存在未测试完毕的需求，则直接在develop分支上进行修复。修复完成后，发布到release进行验证。验证完毕后，按照上线流程进行操作。

在项目中并行开发多个需求，并行提测但上线日期不同，有两种方案可选择：

1. 部署另一个供测试人员测试的分支。

2. 使用git cherry-pick命令将相关提交挑选出来。

最后，为了保证提交信息的规范性，请在提交信息中按照以下格式填写："<动作类型>(范围)：<主题>"，例如："fix(首页模块)：修复弹窗JS Bug"。动作类型可包括fix（bug）、feat（新增功能）、test（调试）、style（更改代码格式或者注释）、docs和refactor（重构代码或者方法）等。

说白了，就是每完成一个features分支，成功以后，都要合并到devlop，而你也要每次从devlop进行分支拉取和新建分支，不要从当前什么的分支，新建，不然一切都要重头来。