Git-flow学习


目录

    • Git-flow流程图
    • 中文版的git-flow流程图
    • 两种核心分支
    • 三种临时分支
    • Git Flow工具
    • 分支命名规范
    • 总结

首先感谢这位大神-mcgrady，博客基本上是copy这位大神的。

Git-flow流程图

git flow是Vincent Driessen提出了一个分支管理的策略，非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。

先看下Vincent Driessen提出的分支管理模型图，以便对git flow有个大概的了解。
在这里插入图片描述

中文版的git-flow流程图

此流程图是自己画的（英文的翻译版）
122
流程图说明：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1. 开始是一个主分支maser
2. 拉取一个开分支develop（简称dev），优化、修改等
3. 一旦线上版本有了紧急bug，拉取一个热补丁分支（hotfix），解决bug
        ① 合并到主分支master
        ② 打一个tag
        ③ 合并到开发分支dev
        ④ 删除hotfix分支
4. 一旦有了新的需求
        ① 从开发分支拉取一个feature特征分支
        ② 需求做完，合并到开发分支dev，然后删除feature分支
        ③ 从develop拉取一个发布分支release，用于修改测试测出来的bug
        ④ 在release修改bug的同时，每次提交要相应的合并到dev分支
        ⑤ 关键点： 此时如果又有新的需求怎么办？ （正在修第一个需求的bug，还未发布，新需求又来了）    
             1. 先要将release分支合并到dev分支
             2. 然后再从dev分支拉取一个feature分支（之前的那个feature分支早删除了）
             3. 在新的feature分支进行新需求的开发
        ⑥  release分支测试通过
             1. 合并到分支master
             2. 打一个tag
             3. 合并到开发分支dev
             4. 删除release分支

在此流程图中未说明如果在1.0版本发布上线之前，出现一个紧急版本0.3该怎么处理？
在feature_1X分支进行开发，开发完成后，直接从feature_1X分支打release_0.3版本，测试通过后，合并到master分支tag3.0，和dev分支。

两种核心分支


主分支(Master)：代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。这个分支只能从其它分支合并，不能在这个分支上直接修改。需要注意的是，所有在master上的提交应该标记tag。

开发主分支(Develop)：这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支。该分支应该只是进行一些优化和升级开发，如果有新的需求应该拉出一个feature分支。

三种临时分支

在这里插入图片描述
功能(feature)分支：这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release。
在这里插入图片描述
预发布(release)分支：当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支。
在这里插入图片描述
修补bug(hotfix)分支：当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release。

Git Flow工具

  • SourceTree (目前自己公司使用这个)
  • GitFlow for Visual Studio

分支命名规范

  1. feature分支：以”feature_“开头，如feature_v1.1
  2. release分支：以”release_“开头，如release_v1.1
  3. hotfix分支：以”hotfix_“开头，如hotfix_20160112
  4. tag标记：如果是release分支合并，则以"release_"开头。如果是hotfix分支合并，则以”hotfix_“开头。
  5. master分支每次提交都要打tag，release tag：如release_v1.1，hotfix tag：如hotfix_20160112
  6. 命名都统一采用小写。

总结

  1. 一定要按git flow的流程去管理分支，如feature分支开发完要合并到develop，如果要发布版本到test环境，则从develop拉出一个release分支，release完成后要合并回master和develop分支，修复生产环境问题需要从master拉出一个hotfix分支，hotfix完成后要合并回master和develop分支，并且在master打上tag。
  2. 一定要按分支命名规范来命名，便于管理和维护。
  3. 了解了git flow工作流程后，可以不使用git flow GUI工具，手动操作即可，可以是原生git命令+vs配合操作，比如给master打tag就要用git命令，这在vs里操作不了的，比如合并分支，虽然也可以使用git命令实现，但在vs里操作更方便直观。
  4. 一定要保持分支的纯净，不要随便污染分支。比如，develop分支只包含要发布到下一个release的代码，在没有拉出release分支前不要合并新的feature分支进来。release分支基于develop分支创建，拉出release分支后，我们可以在这个release分支上测试和修复bug，但是，一旦打了release分支后不要从develop分支合并新的改动过来。develop拉出release分支的同时，也意味着develop分支可以开始下一个release的准备工作了。
  5. 如果多个版本并行到test环境，怎么解决这个问题？如下图。
    在这里插入图片描述