代码管理之 git flow

Q: 面对多人协作时，代码管理往往会出现令人头疼的问题，冲突、团队队员操作失误导致代码丢失、分支管理、版本管理等都容易引起回滚、排查提交日志等。

A: git flow

本文仅介绍个人经历及对代码管理的一个见解，若不适用或者不感兴趣则跳过哈！

虽然每个团队都有自己的一套代码管理方式，成熟的团队一般拥有更严谨更成熟的流程。但git flow（git 工作流）更适用于大部分团队大部分场景。Git Flow已经开始流行于基于主干的工作流，它现在被认为是现代连续软件开发和DevOps（开发、技术运营和质量保障三者的交集）实践的最佳实践。

以下是git flow的流程图

分支情况： 正常情况下，代码分支分为master、develop、feature、release、hotfix等，项目越大分支越多，但基本都基于这五类分支。以下说法纯属个人理解，并非官方说法

手动狗头

• master分支（production分支）： 一般指的是生产环境的代码（正式环境），即当前最新的稳定版本，不允许直接修改该分支代码，只允许由其他分支合并进来
• develop分支： 一般指的是主开发分支，允许直接修改（但不推荐），若需要添加功能建议在此拉出feature/xx分支，完成后合并至develop。
• feature分支：一般指的是为了完成某个新的模块或者功能的分支，一旦开发完成，则需合并至develop分支
• release分支：基于develop分支，表示当前版本开发完毕，用新创建的release分支作为测试环境及bugfix用的基础分支。
• hotfix分支：维护分支（可以理解为bugfix专用），一般是当生产环境有bug时，需要从master分支或者develop分支拉出一个hotfix分支专门修改bug（有些团队基于master，有些基于develop分支）。

在了解完git的常规分支后，咱们基于常规的代码管理来讲解一下对应git flow需如何操作，以及其优点。

相信很多开发人员都以常规的status->add->commit->push这一套流程为主要的代码流程（pull则看习惯看心情啥时候pull了 只要保证在push之前pull就好）。或者以sourcetree等可视化的git应用来实现代码管理。（本鸟习惯了命令行）。下面分场景来介绍一下git flow对应的操作.

场景一：开发新功能

（仅讨论项目现版本上开发新功能）

非git flow操作流程：

方式1： 一般发生在项目稍微小一点的团队中或者独立负责的项目,

// dev分支上码码码写bug -> 完事add -> commit -> push

方式2： 一般发生在流程稍微严谨一点的团队中：

// dev分支上拉取feature分支 -> 码码码写bug -> 完事add -> commit -> 
// 切换到dev -> merge功能分支feature -> 删除feature分支

git flow操作流程：

以完整流程为对比，

// git flow feature start xxx -> (git flow feature pull origin xxx) -> 
// (git flow feature pulish xxx) -> git flow feature finish xxx

其中xxx为分支名, git flow操作流程第一步对比非git flow操作流程方式2中的从dev分支上拉取feature分支步骤，方式2中命名一般为feature/模块_功能 或者 feature/功能。而git flow下xxx则直接为模块_功能 或者直接 功能。pulish及pull步骤则应用于多人开发中避免冲突的一种操作方式，按需使用，若只是独立负责大可在本地git flow start 完成后 finish，finish后会合并feature至develop，删除本地feature分支.

优点： 若以方式2开发的团队，用git flow可以简化很多流程，例如开发完毕后删除多余的feature分支、自动合并至develop分支等。若以方式1开发的团队，使用git flow虽然感觉有点没必要，但可以规范自己养成一个好的代码管理习惯，在多人协作中，可以更好的管理代码，避免出现各种问题。

场景二：测试阶段

非git flow操作流程：

方式1：一般发生在项目稍微小一点的团队中或者独立负责的项目,

直接以develop分支为当前版本的测试分支，修复完bug后常规流程提交复测，没问题就以当前develop分支为最新稳定版本合并至master作为生产环境代码，弊端：若修复过程中有新版本的需求，处理起来便会稍微麻烦一点，得考虑如何避开新代码等问题，尤其是新版本的需求也需要在这个阶段测试。

方式2：基于develop分支拉取release分支，此时develop分支已没有当前版本需要开发的feature，以该release分支作为当前版本的定版作为测试，不影响新功能的开发（不会出现方式1各种奇葩的时间节点），退一万步讲有新功能在此时介入，到时候发版也是把稳定后的release合并回develop跟master分支即可， 若有冲突还是需要手工解决。具体情况具体分析哈，以上是个人见解。

// git checkout -b release-0.1.0 develop -> git checkout master / develop ->
// git merge -no-ff release-0.1.0 -> git push -> git branch -d release-0.1.0 -> 
// git push origin --delete release-0.1.0 -> 打tag

git flow操作流程：

// git flow release start xxx -> (git flow release pull origin xxx) ->
// (git flow release publish xxx) -> git flow release finish xxx

操作流程与指令与feature相似，因此特别的好记，使用feature还是release就按场景来选择即可，但记得push的时候打上tag噢，毕竟release没问题就意味着这是一个新的稳定版本，需要合并到master跟develop的，打上tag则可以根据该标识快速定位各种问题。

场景三：突发！生产环境有个bug！

非git flow操作流程：

master拉取hotfix分支 -> 处理bug -> 测试 -> 合并到master

// git checkout -b hotfix-0.1.1 master -> git checkout master -> git merge --no-ff hotfix-0.1.1 ->git push

git flow操作流程：

// git flow start hotfix 0.1.1-> git flow finish hotfix 0.1.1

两者流程一样，但操作明显git flow会方便很多，此外，若使用非git flow操作流程，则另外考虑代码合并问题，由master 合并至develop。而使用git flow，则会在finish的时候将hotfix分支合并至master及develop分支，并且删除hotfix分支。但使用hotfix有个特殊场景需要注意： 若当前存在release分支，则在finish时会合并到release分支，而不会合并至develop分支上。

常用的git flow操作就是以上几种场景了，虽然流程上来说与非git flow相比大同小异，但操作上方便省事不少，尤其是从哪拉分支、完成后删除分支。感兴趣的小伙伴们可以试试哈， 个人觉得还是比较规范比较方便的，对于萌芽期发展期的团队，一个规范的代码管理方式能够为日后节省不少意外的事（dddd，轻则conflict，重则代码给别人干掉了T_T）。在本地查log， reset，再自己去处理合并的冲突简直头大且低效。

总而言之，若团队这方面已经特别成熟，尤其是使用过或者正在使用git flow的，常规git操作能满足的、或者习惯常规git流程的，都可以无视这篇文章。

若对git的流程还不太熟悉的，可以先去了解一下常规的git开发流程。本文较浅，算是个人学习并实践git flow的一个见解及复盘。感兴趣的小伙伴可以自己试试呢，感谢观看，祝好