Git分支管理

Category: work Tags: Git

前言

创业公司早期没有严格的git管理规范，同时又有新同事的加入，对 git 分支的命名和管理方式有些许的模糊，因此重新进行了定义。

代码分支管理

项目代码分支为: master、release、feature 、hotfix 。

• master: 主分支，也称为线上分支，主要用来版本发布
• dev：日常开发分支
• release：预发版分支，大多数情况下和线上功能是一致的
• feature：具体的功能开发分支
• hotfix：线上bug修复分支

主分支：

主要包括master/release/dev三个分支

master：

预发环境测试完成后，把代码合并到master 分支，并由运维部署到生产环境。

release：

Release 分支 从 Master 检出，最终会合并到 Master。 所有新增功能的开发分支都是从 Dev 检出作为本地分支，以 feature/姓名首字母简拼/功能名，当功能开发完毕的时候，将 feature 合并到 Dev，在测试或预生产环境进行部署，测试通过后，再将 feature合并到 Release。 如果出现线上问题需要紧急修复，则从 Release 检出作为本地分支，以 hotfix/姓名首字母简拼/功能名， 当问题修复完毕的时候，将 hotfix合并到 Dev，测试通过后，再将 hotfix合并到 Release，在预发环境再次验证。 待所有的测试和准备工作做完之后，我们就可以将 release 分支合并到 master 分支上，并择机进行线上发布。

dev：

dev 就是我们的日常开发分支。

辅助分支

feature：

feature 分支用来开发具体的功能，一般 checkout自 Dev 分支，以 feature/姓名首字母简拼/功能名 进行命名，最终合并到 Dev 、Release 分支。比如我们要在下一个版本增加功能 1、功能 2、功能 3。那么我们就可以起三个 feature 分支：feature-abc-1，feature-def-2，feature-gjk-3。（公司目前基本是一个功能一个开发，也可以功能名/姓名）随着我们开发，功能 1 和功能 2 都被完成了，而功能 3 因为某些原因完成不了，那么最终前两分支将被合并到 Dev 分支，而第三个分支将延期继续进行本地开发工作，功能 1 和功能 2 测试完没有问题后，将 feature1 和 feature2 分支合并到 Release 分支，最终将 Release 分支合并到 Master 分支。

hotfix：

hotfix 分支用来修复线上 bug。当线上代码出现 bug 时，我们基于 Release 分支开一个 hotfix 分支，以 hotfix/功能名/姓名首字母简拼（例如：hotfix-model-base-zxz），修复 bug 之后再将 hotfix 分支合并到 Release 分支，同时 Dev 分支作为最新最全的代码分支，hotfix 分支也需要合并到 Dev 分支上去，同时在不同分支对应的不同环境进行 bug 回归验证，最终将 Release 分支合并到 Master 分支，进行线上发布。

关于Tag

• 为了保证生产回滚的可能性(由于某些情况导致生产发布失败，需要回滚)。每次发布生产需要生成对应的发布Tag。

代码分支提交与合并

1. 代码提交前，必须拉取最新代码，防止冲突。 如果拉取代码后需要冲突，需要解决代码冲突后再进行提交
2. 代码合并 在本地合并，不允许在远端进行merge操作

版权声明：自由转载-非商用-非衍生-保持署名

Go Top