Git分支命名规范

一、git分支命名规范

git分支分为集成分支，功能分支、和修复分支。分别命名为develop，feature和hotfix，均为单数。不可使用features、future、hotfixes、hotfixs 等错误名称。

• master（主分支，永远是可用的稳定版本，不能直接在该分支上开发）
• develop（开发主分支，所有新功能以这个分支来创建自己的开发分支，该分支只做合并操作，不能直接在该分支上进行开发）
• feature-xxx（功能开发分支，在develop上创建分支，以自己开发功能模块命名，功能测试正常后合并到develop分支）
• feature-xxx-fix（功能bug修复分支，feature分支合并之后发现bug，在develop上创建分支进行修复，之后合并回develop分支）
  • PS：feature分支在申请合并之后，未合并之前还是可以提交代码的，所以feature在合并之前还可以在原分支上继续修复bug
• hotfix-xxx（紧急bug修改分支，在master分支上创建，修复完成后合并到master）
• bugfix/*分支 （短期从develop创建）
• release/*分支（短期从develop创建）

注意事项：

• 一个分支尽量开发一个功能模块。不要多个功能模块在一个分支上开发
• feature分支在申请合并之前，最好是先pull一下主分支develop，看一下有没有冲突，如果有，先解决冲突后再申请合并

二、Branch功能详解

master负责记录上线版本的迭代，该分支代码与线上代码是完全一致的主分支。

develop负责记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建

开发分支feature/*用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成后并自测，自测通过之后，需要合并到develop分支，之后删除该分支。

bugfix/*用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测，pass之后合并到develop分支后删除该分支

release/*用于代码上线准备，该分支从develop分支创建，创建之后由测试人员发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完成后，在上线之前，需要合并该release分支到master分支和develop分支。

hotfix/*该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支紧急bug修复分支。

三、Branch命名规范

功能分支：

格式：feature/功能名称

例如：feature/loginbug

修复分支：

格式：bugfix/bug名称

例如：bugfix/add-user

紧急bug修复分支：

格式：hotfix/bug名称

例如：hotfix/delete

预发布分支：

格式：release/预发布版本名称

例如：release/add-user

四、分支用途详解

我们刚刚熟悉了git中常用的分支，那么这些分支有什么意义呢？这么说吧，如果你是一个人开发，那么这确实没什么用，当你在一个团队时就发挥了很大的作用。

一般作用下，master分支和线上版本是保持一致的，那么我们需要对它非常重视。一切开发任务都不能在这里进行。因为在开发过程中如果出现bug就会弄脏master分支。如果我们在develop分支上开发，不管出什么错误都不怕，因为master是干净的，实在不行可以从master重新拉取没有问题的项目。

这个就是分支其中一个作用。现在是这样的情况：我们在develop分支上完成了项目，那么之后对各个分支是怎么处理呢？

过程大概是这样的：将我们的develop分支合并到release分支，这个是一个预发布分支，这个预发布分支是交给测试的人员。测试人员在release分支上拉取完整项目进行测试，在测试过程中发现了一个bug。

测试人员找到了开发人员，开发人员在release分支上修改好问题，所有问题都解决了，这时release分支合并到master分支和develop分支。这时开发人员的develop是最新的，master分支也是最新的。另外一种情况是这样的：线上产品使用过程中突然出现了一个bug，这时非常紧急的情况，这时需要处理的步骤大致如下：创建一个紧急bug分支名为hotfix，将master分支拉取到hotfix分支。

紧急修改完bug之后将hotfix同步到master分支和develop分支，再删除hotfix分支。世界就恢复平静了。总之，分支会让你在更安全的环境下开发，git里面什么后悔药都有的。

五、工作流程

1. 克隆项目

2. 迁出并创建dev分支，使其跟踪远程的origin/dev分支

3. 在dev分支基础上创建自己的分支member*

4. 在自己的分支上添加文件

5. 在自己的分支上修改文件

6. 合并到dev分支

7. 推送dev分支到origin/dev分支

8. 更新.gitignore文件。从dev新建一个分支ignore
   如果预测变更频繁就建立一个远程分支,现在一般都有模板,偶尔有个没有忽略的直接在dev分支上修改就可以了

   忽略更新文件尽快合并推送到origin/dev分支（避免两个组员同时更改该文件造成冲突）

六、git提交记录规范

每个git commit记录都需要按照固定格式，具体格式为：

• 第一行：作者，功能模块名称或者 功能模块ID
• 第二行：提交描述。中英文均可
  • ： + 增加代码
  • ： * 修改代码
  • ： - 删除代码

七、原文链接

https://www.cnblogs.com/yorkyang/p/9147309.html

https://blog.csdn.net/weixin_34547883/article/details/112441888

https://blog.csdn.net/weixin_42134789/article/details/109349020

https://aiohttp-demos.readthedocs.io/en/latest/index.html#aiohttp-demos-polls-beginning

http://c.biancheng.net/design_pattern/

https://www.cnblogs.com/cndevops/p/14993331.html

https://www.cnblogs.com/tanshaoshenghao/p/14979531.html

https://www.cnblogs.com/daysme/p/9571489.html