【git分支管理策略】如何高效的管理好代码版本

素颜马尾好姑娘i 2024-04-25 20:22 6阅读 0赞

**目录**

1.分支管理策略

2.我用的分支管理策略

3.一些常见问题

--------------------

## 1.分支管理策略 ##

分支管理策略就是一些经过实践后总结出来的可靠的分支管理的办法，让分支之间能科学合理、高效的进行协作，帮助我们在整个开发流程中合理的管理好代码版本。

目前有两套Git分支管理策略GitHub Flow和GitFlow，它们各自定义了一套规范，帮助开发者更好地组织和管理源代码的版本控制流程。

**GitHub Flow**

**简介：**

GitHub Flow 是由GitHub团队推广的一种简单、灵活且快速的工作流程，特别适合小型团队和持续交付环境。

**核心概念：**

*  所有开发都是基于main分支（原称master，现在推荐使用main）。
 *  新的功能开发通过创建短期的特性分支（feature branches）。
 *  特性分支完成后，通过Pull Request (PR) 提交到main分支。
 *  PR期间进行讨论、审查和自动化测试，只有当所有工作满足要求时，才将其合并至main。

**优点：**

GitHub Flow的优势是快速迭代，频繁部署，强调每个特性分支都应具备随时可部署的状态。

**GitFlow**

**简介：**

GitFlow 是一种更为严谨和复杂的分支模型，适用于大型项目和需要严格版本控制的企业级开发环境。

**核心概念：**

*  分支分为两大类：持久分支和临时分支。
    
     *  持久分支包括：main（稳定版）、develop（开发版）。
     *  临时分支包括：feature（特性分支）、release（发布分支）、hotfix（热修复分支）。
 *  develop分支作为日常开发集成的分支，每次新增功能或修复都在独立的feature分支上完成，完成后合并回develop。
 *  当产品即将发布时，创建一个release分支，进行测试和最后的调整，确认无误后合并到main和develop，并打上版本标签。
 *  如果生产环境中发现了紧急问题，那么在main基础上创建hotfix分支进行修复，修复完毕后同样合并回main和develop。

![33fb0093957944cabd7c22e2f929b9f6.png][]

**优势：**

结构清晰，易于跟踪每个阶段的代码状态，有利于多人协同和大型项目管理，尤其对于那些有明确版本周期和稳定版需求的项目。 总结来说，GitHub Flow 更注重敏捷开发和快速迭代，简化了分支结构；而 GitFlow 则提供了详细的分支管理方案，更适合需要精细化版本管理和长周期开发的场景。目前市面上各团队常用的管理策略基本上都是基于GitHub Flow策略的。

##  ##

## 2.我用的分支管理策略 ##

目前作者所在的团队采用的分支管理策略就是基于GitHub Flow策略的。

我们有以下几个分支：

*  master，稳定主分支
 *  pre-release，稳定测试分支
 *  develop，开发分支
 *  feature，单人新特性分支
 *  release，发布分支
 *  patch，维护分支

当我们开发新功能的时候会先分一下任务，然后各自从develop分支上拉一个属于自己的feature分支，这个feature一般会命名为：下个版本的版本号-feature-自己名字的缩写

任务有轻重缓急和难易之分，一个大版本的所有新需求很难在统一的一个时间点上完成，所以一般都是分批次提测的，最后合并在一起发版。提测的时候各自将自己要提测的内容从自己的feature上合并到develop分支上，再从develop分支合并到pre-release上。将pre-release部署到测试环境中用于测试。之所以这样做是在实践中发现很多时候develop并不是稳定的，大家都在往上面合并代码，直接将develop用于部署测试往往无法保证测试环境的稳定，会造成阻塞。所以有一个pre-release用来保证测试环境的稳定。测试期间的bug修复也是先修自己的feature然后合并到develop然后合并到pre-release。

要注意上面的合并一般指的都是cherry pick，一条一条的合并，分支级别的merge是很容易将pre-release和develop合乱的。

所有新特性都测试完成后，将develop合并到release上，然后基于release打tag发版。

发版后有可能还会发现一些bug，一般会基于发版的tag拉一个patch分支来进行快速修复。这时候修复的bug会先在patch上修复，修复完毕后合并到develop分支上。最后这个patch分支在维护一段时间后会被丢弃。

##  ##

## 3.一些常见问题 ##

**1.如何打tag？**

在IDEA种可以通过图形化的界面来打tag：

![8839673f997247ed9a1bbfa7512aa419.png][]

也可以通过命令来打tag：

>     git tag -a <tag-name> -m "<tag-message>"

打完tag之后push到远端仓库即可。

**2.如何切到某个tag**

打完tag之后有些时候我们要用到打tag的代码版本，可以通过命令跳过去：

git checkout -b <new-branch-name> <tag-name>

**3.如何基于tag拉分支？**

打完tag代码就算是封板了，但是发版后仍然会有一些小问题会持续暴露出来，需要我们持续修复，于是我们需要基于tag拉出一个hotfix分支来，在这个分支上进行发版后的bug修复，可以通过命令来从某个tag拉出一个分支：

>     git checkout -b <new-branch-name> <tag-name>

**3.如何合并？**

在hotfix上修复的bug在当前的开发分支上当然也是存在的，所以我们要将hotfix上的bug修复持续的合并到开发分支上，这时候尽量不要用分支级别的合并命令merge来操作，尽量将bugfix一条一条的合并到开发分支上。

在IDEA上可以直接通过图形化界面将某个分支上的修改单条的合并到当前分支。操作很简单，首先保证自己当前在接收合并的分支上，然后在git log中找到要合并过来的提交，cherry pick过来即可：

![810c1156b6a6446692273459e53ec62a.png][]

4.如何比对分支之间的区别？

从hotfix合并到develop分支，这种两个分支之间一条一条的合并难免会合并漏，最好的方式当然是要比对出两个分支之间的差异，在IDEA中很好比对差异：

![a762c6101e6c4f2f8b6e2209ca011cdb.png][]

[33fb0093957944cabd7c22e2f929b9f6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/25/a2e33f14865e48e898b4834be52e05a5.png
[8839673f997247ed9a1bbfa7512aa419.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/25/c3692d76de1248d290ed65806dae0f7c.png
[810c1156b6a6446692273459e53ec62a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/25/d09bc63671ed496bb69fb6fb3a32a10b.png
[a762c6101e6c4f2f8b6e2209ca011cdb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/25/494d35fb02184c6bb5b858d9abddf86c.png