标签：用户   日常   nbsp   日志   菜单   提高   形式   code   2.3   

前言

无论是开源项目还是内部项目，使用Git都是大势所趋，尤其是在产品管理这块，使用Git大大提高了开发效率和产品的交付频率。本篇，针对Git的工作流和分支使用，进行了一些推荐。

目录

1     产品管理开发之Git工作流和分支规范推荐

1.1      Git工作流模型推荐

1.2      Git产品开发分支规范要求

1.2.1      永久分支

1.2.1.1  master（稳定版）

1.2.1.2   开发版（develop）

1.2.2      临时性分支

1.2.2.1   功能（feature）分支

1.2.2.2   预发布（release）分支

1.2.2.3   修补bug（hotfix）分支

1.2.3      代码分支提交使用规范

1 产品管理开发之Git工作流和分支规范推荐

无论是开源项目还是内部项目，使用Git都是大势所趋。因此，针对Git的工作流和分支使用，本篇进行了一些推荐：

1.1   Git工作流模型推荐

1.2   Git产品开发分支规范要求

在产品开发或者复杂项目开发，我们推荐严格遵循此规范进行开发。对于中小项目和个人开发，您可以按需来设计自己的规范和要求。

1.2.1    永久分支

1.2.1.1    master（稳定版）

主分支，主分支只用来发布重大版本。所有提供给用户使用的正式版本，都在这个主分支上发布。

1.2.1.2    开发版（develop）

日常开发应该基于此分支来完成。

如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。

1.2.2    临时性分支

除了永久分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

• 功能（feature）分支

• 预发布（release）分支

• 修补bug（hotfix）分支

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。

1.2.2.1    功能（feature）分支

功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

功能分支的名字，请采用feature/feature1  的形式命名。

1.2.2.2    预发布（release）分支

预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，请采用release/release1的形式。

1.2.2.3    修补bug（hotfix）分支

修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，请采用hotfix/fixbug1的形式。

1.2.3    代码分支提交使用规范

• 使用Git过程中，必须通过创建分支进行开发，坚决禁止在主干分支上直接开发。review的同事有责任检查其他同事是否遵循分支规范。

• 在Git中，默认是不会提交空目录的，如果想提交某个空目录到版本库中，需要在该目录下新建一个.gitignore 的空白文件，就可以提交了

• 把外部文件纳入到自己的Git 分支来的时候一定要记得是先比对，确认所有修改都是自己修改的，然后再纳入。

• 提交时，一定要填写有意义的注释。注释内容要求如下：第一行为提要，然后逐行罗列出功能点、主要变动、以及需要注意的问题等等。具体如下所示：

注释提交模板：

简要说明（第一行）

（空行）

1. （要点）

2. （要点）

注释提交参考：

1. 后台菜单管理增加区域菜单功能，修复日志记录器若干问题

2. 后台菜单管理增加区域菜单功能，目前分为系统平台和租户平台，根据属性MenuPlatform来设置增加若干系统管理菜单

3. 完善菜单模块，以便加载不同平台菜单

4. 修复日志记录器为NULL的情形

产品管理开发之Git工作流和分支规范推荐

标签：用户   日常   nbsp   日志   菜单   提高   形式   code   2.3   

原文地址：https://www.cnblogs.com/codelove/p/10640918.html