Git简介

Git是一个版本控制软件，它独特的分支功能让我们能够很容易的进行多人协作开发。但是Git的分支管理也是一门学问。没有经过细心打理的分支将会变得杂乱而没有意义。

流行的Git分支管理策略

针对Git的分支管理，许多大神已经提出了现有的方案。最流行的方案有四种：

  • Git Flow
  • Github Flow
  • Gitlab Flow
  • TBD++ Flow

其中，Git Flow是最早诞生的，也是功能最全，应用最为广泛的。

Github Flow 是一种简化的工作流，其特点是在工作流中包含了 Pull Request。通常应用于小型项目。
Gitlab Flow 则是基于Github Flow，带发布环境的一种工作流。
TBD++ Flow 则是一种基于主干的开发流程。

Git Flow

Git Flow简介

Git Flow工作流有两个长期分支：main develop。其中，main分支是用来发布软件的，develop分支是用作开发使用的。

此外，还有三种临时分支：

  • feature 功能分支，用于在develop分支上开发时添加新功能
  • hotfix 补丁分支，用于给main分支上的版本修补bug
  • release 预发布分支，用于develop发布到main时做测试和修补bug

这三种分支是为了不影响长期分支的开发进度而出现的分支。开发完成后，它们会被merge进对应的分支，然后被删除。

一个初具规模的Git Flow流程总览应该是这样的

gitflow

main分支

main分支的原则是：除去创建项目时的init commit，其余main分支上所有的commit都应该是稳定的、可以提供给用户的稳定版本。通常，main分支上的每一个commit都需要一个tag来标明版本号。

develop分支

开发分支，存有最新的开发版本。其应该也是可以运行的，但是允许存在不稳定、有bug的情况。如果develop准备好发布下一个软件版本，就可以进入向main分支提交的流程。

feature分支

当我们需要添加一些功能时，如果直接在develop上进行开发，那么我们未完成功能的commit就会影响到其他人员的工作。这时候，我们最好应该以当前最新的develop版本为基础，另开一条分支来开发这个新的功能。
当功能开发完成的时候，feature分支就应该合并到develop分支上去，完成新功能的添加。此后应该将feature分支删除。

feature分支个人习惯命名为 feature-featureName 这样不仅能表明这是一个feature分支，还能告诉他人正在开发的feature是什么。

hotfix分支

当我们发现已发布版本存在重大bug，需要紧急修补的时候，我们就需要从main分支上分出一个hotfix分支来修补bug。

当bug修复完毕时，这个分支应该同时被合并到main、develop两个分支，这样才能保证bug被完全修复。

hotfix分支个人习惯命名为 hotfix-nextVersion 后缀应该为hotfix后发布的版本号。

release分支

当我们开发完一个阶段的功能，准备发布新版本时，大多数情况下都会进行一定的测试。此时我们就需要一个预发布分支。在这个分支上，不能够继续开发新的功能，只能测试已有的功能，并修复bug。

当测试完成后，跟hotfix分支一样，它应该被同时合并进develop与main分支，保证已经修复的bug不再出现。

release分支个人习惯命名为 release-nextVersion 如果需要的话可以在版本号前面再加上提测日期。

针对多人项目

当项目人数较多时，develop分支更新会十分频繁，且commit可能会比较杂乱。这时我们建议每个人独自建立一个私人分支，或者将工作分解为一个一个的feature。平时只需要在自己的分支上开发即可，只在必要的时候merge到develop分支。