下划线学习频道

Appearance

快速预览

Git分支管理工作流-GitFlow

✍️ cyyspring 🕒 2023-08-11 01:54:57(9 months ago) 🔗 F.开发中杂七杂八 git

分支是Git的一项强大特性,可以有效地支持团队合作和并行开发。为了充分发挥分支 带来业务价值,有必要设计并采用合理的Git工作流和分支策略。常见的工作流 分支策略有 GitFlow、GitHubFlow 和 GitLabFlow 等

GitFlow ​

Git Flow 是一种基于 Git 的分支管理策略，旨在优化软件开发的效率和质量。该策略最初由 Vincent Driessen 在 2010 年提出,我们使用 GitFlow 的策略 可以解决以下问题

  • 管理项目历程:将不同的开发阶段对应到不同的分支上,可以有效地管理和控制项目的整个开发历程。

  • 隔离开发:每个开发者都有自己的分支进行开发,不会影响主分支或其他人的工作,有效隔离开发。

  • 加快bug修复:专门的bug修复分支(如hotfix分支)可以快速地fix bug然后合并。

  • 保持仓库清晰: 主分支(master)保持健全和稳定,只包含正式发布的版本;特性分支和开发分支包含正在开发的临时变更。

  • 管理版本:通过将发布版本对应到指定分支,方便管理和回溯每个版本的变更。

  • 协调团队:清晰的分支结构和工作流有助于团队协同工作,避免混乱

整个 GitFlow 流程管理设计思路是 将分支进行细化分为 主分支 和 辅助分支两类分支

  1. 主分支：master分支、develop分支； 主要分支和开发分支，用于组织与软件开发、部署相关的活动,使用两个分支来记录项目的历史记录，而不是单个主分支。master主分支存储官方发布历史记录，而Develop开发分支作为功能的集成分支

  • Develop 分支是主要的集成分支，用于将不同的功能集成到一个代码库中。开是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支上进行开发，实现单个功能并将其推送到Develop 分支。该分支应该只是进行一些优化和升级开发，如果有新的需求应该拉出一个feature分支。因此，Develop 分支包含了尚未发布的所有功能和代码修改。

  • Master 分支是官方发布的历史记录。当代码已经经过测试，并且已经准备好发布时，开发人员将 release 分支合并到 Master 分支中。因此，Master 分支只包含已经发布的代码。Master 分支的优点是它提供了一个稳定的基准点，可以用于构建和部署生产环境中的应用程序。此外，Master 分支的每个提交都应该被标记为版本号（标记tag），这使得查找特定版本的代码变得更加容易

  1. 辅助分支：feature分支、release分支、hotfix分支，辅助分支包含功能分支、预发分支、热修复分支以及其他自定义分支，是为了解决特定的问题而进行的各种开发活动。这些分支总是有有限的生命时间，因为它们最终将被移除

注意的是 主分支通常是必须的，而辅助分支 例如 feature分支、release分支和hotfix分支是根据项目需要和团队规模来决定是否使用。辅助分支可以使协作和版本管理更加清晰和高效。

分支名称说明场景关系
master分支主分支，代表生产环境的代码版本用于发布稳定版本，不应该直接提交代码到此分支develop分支的父分支，接受release分支合并，hotfix分支应该合并回master分支
develop分支主分支，代表开发环境的代码版本用于开发新功能和修复bug，feature分支从此分支分出，release分支合并回此分支master分支的子分支，接受feature分支和hotfix分支合并
feature分支辅助分支，代表特定功能的开发分支用于开发特定功能，从develop分支分出，完成后合并回develop分支develop分支的子分支
release分支辅助分支，代表发布前的准备分支用于进行最后的测试和准备工作，从develop分支分出，完成后合并回master分支和develop分支develop分支的子分支，master分支的父分支
hotfix分支辅助分支，代表紧急修复分支用于紧急修复生产环境的bug，从master分支分出，完成后合并回master分支和develop分支master分支的子分支，develop分支的子分支

工作流程 ​

当项目开始阶段，应该创建两个分支 Develop 和 Master，最开始两个分支 develop 是来自master 的

当进入开发阶段需求任务下发，开发拿到了自己要开发的模块的时候，划分清楚开发任务模块，针对自己模块内容，通过派生develop分支，生成自己的feature 分支 创建 功能分支（Feature） 功能分支一般命名为 Feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发

功能分支只能拉取自开发分支，开发完成后要么合并回开发分支，要么因为新功能的尝试不如人意而直接丢弃

当feature开发完毕后，要合并回 develop 分支。feature分支永远不会和master分支打交道

当功能开发完毕开始交付给测试进行测试阶段，feature开发完毕后已将代码合并到了 develop ，因此此时 需要从 develop 分支创建 预发分支（Release） 该分支专为测试—发布新的版本而开辟，允许做小量级的Bug修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入

预发分支需要提交到服务器上，交由测试工程师进行测试，并由开发工程师修复Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署

release分支不是一个放正式发布产品的分支，你可以将它理解为“待发布”分支。预发分支只能拉取自开发分支，合并回开发分支和主要分支。要强调这个模式主要做的事情：

  • 把这个分支打包给测试人员测试
  • 在这个分支里修复bug
  • 编写发布文档

这个分支绝对不能做的是不会添加新的特性

当和发布相关的工作都完成后，release分支合并回develop和master分支，release分支的好处是，当一个团队在做发布相关的工作时，另一个团队则可以接着开发下一版本的东西。

当项目上线后发现紧急bug后热修复分支（Hotfix），就需要从主要分支上指定的tag版本（比如1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如1.2.1）。这样做的好处是不会打断正在进行的开发分支的开发工作，能够让团队中负责功能开发的人与负责代码修复的人并行、独立的开展工作

热修复分支只能主要分支上拉取，测试通过后合并回主要分支和开发分支。

一个项目发布后或多或少肯定会有一些bug存在，而bug的修复工作并不适合在develop上做，这是因为

  • develop分支上包含还未验证过的feature

  • 用户未必需要 develop 上的feature

  • develop还不能马上发布，而客户急需这个bug的修复。

这时就需要新建hotfix分支，hotfix分支派生自master分支，仅仅用于修复bug，当bug修复完毕后，马上回归到master分支，然后发布一个新版本，比如，v0.1.1。

同时hotfix也要合并回develop分支，这样develop分支就能享受到bug修复的好处了。

全流程 ​

  1. 开始是一个主分支maser

  2. 拉取一个开分支develop（简称dev），优化、修改等

  3. 一旦线上版本有了紧急bug，拉取一个热补丁分支（hotfix），解决bug

    • 合并到主分支master
    • 打一个tag
    • 合并到开发分支dev
    • 删除hotfix分支

  4. 一旦有了新的需求

    • 从开发分支拉取一个feature特征分支
    • 需求做完，合并到开发分支dev，然后删除feature分支
    • 从develop拉取一个发布分支release，用于修改测试测出来的bug
    • 在release修改bug的同时，每次提交要相应的合并到dev分支

  5. release分支测试通过

    • 合并到分支master
    • 打一个tag
    • 合并到开发分支dev
    • 删除release分支

在此流程图中未说明如果在1.0版本发布上线之前，出现一个紧急版本0.3该怎么处理？

在feature_1X分支进行开发，开发完成后，直接从feature_1X分支打release_0.3版本，测试通过后，合并到master分支tag3.0，和dev分支。

此时如果又有新的需求怎么办？ （正在修第一个需求的bug，还未发布，新需求又来了）

  1. 先要将release分支合并到dev分支
  2. 然后再从dev分支拉取一个feature分支（之前的那个feature分支早删除了）
  3. 在新的feature分支进行新需求的开发

GitFlow 实践 ​

上面每个分支都要进行不同的，操作过程,将这些规则步骤用 git 指令实现出来

创建 develop 分支

bash
# 创建 develop 分支 
git branch develop
# 将 develop 分支推送到远端仓库
git push -u origin develop

开始新的 Feature

bash
# 通过develop新建feaeure分支
git checkout -b Feature分支名 develop
# 可选，将分支推送到远端仓库
git push -u origin Feature分支名

编辑 Feature 分支

bash
# 查看状态
git status
# 添加提交内容
git add XXXfile
# 提交    
git commit

完成 Feature 分支

bash
# 拉取远端仓库 develop 分支合并到本地 develop 分支
git pull origin develop
# 切换到 develop 分支     
git checkout develop
# 将 Feature 分支合并到 develop 分支    
	# --no-ff：不使用 fast-forward 方式合并，保留分支的 commit 历史
	# --squash：使用 squash 方式合并，把多次分支 commit 历史压缩为一次    
git merge --no-ff Feature分支名
# 将分支推送远端仓库 
git push origin develop
# 删除 Feature分支
git branch -d Feature分支名

开始Relase

bash
# 创建 Relase 分支并切换到 Relase 分支上
git checkout -b release-0.1.0 develop

完成Release

bash
# 切换到 master 分支上
git checkout master
# 合并 release-0.1.0 分支    
git merge --no-ff release-0.1.0    
# 推送到远端仓库
git push
# 切换到 develop 分支上    
git checkout develop
# 合并 release-0.1.0 分支   
git merge --no-ff release-0.1.0
# 推送到远端仓库   
git push
# 删除 release-0.1.0 分支 
git branch -d release-0.1.0

开始Hotfix

bash
# 创建 hotfix 分支并切换到 hotfix 分支上
git checkout -b hotfix-0.1.1 master

完成Hotfix

bash
# 切换到 master 分支
git checkout master
# 合并 hotfix-0.1.1 分支
git merge --no-ff hotfix-0.1.1
# 推送到远端仓库
git push
# 切换到 develop 分支
git checkout develop
# 合并 hotfix-0.1.1 分支
git merge --no-ff hotfix-0.1.1
# 推送到远端仓库
git push
# 删除 release-0.1.0 分支    
git branch -d hotfix-0.1.1
# 为主分支打上版本标签
git tag -a v0.1.1 master
# 将标签推送到远端仓库  
git push --tags

更简单的GitFlow 工具推荐 | 配套工具 ​

上面这些有规律重复性质的工作 ，也是有统一的工具可以集成管理，使用 git-flow 工具优化 一些高的 git 版本中已经默认集成了

查看电脑是否安装 git-flow 工具

bash
git flow version

git flow init 先让仓库初始化 git flow 流程

bash
已初始化空的 Git 仓库于 /Users/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master] main    //主分支名称，之前是master，现在用main多一些
Branch name for "next release" development: [develop]  //开发分支名称，默认就好，下面无特殊要求都默认
How to name your supporting branch prefixes?
Feature branches? [feature/]   
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

当创建一个新的开发模块 feature 分支时候 start 后面一般跟你的新功能名称，它会基于 develop 分支为基础创建的这个新的分支

bash
git flow feature start your-branch-name

当 feature 分支 功能开发完成后,这条命令会将你新开发的功能合并到 develop 分支并删除该 feature 分支，然后切换回 develop 分支，当然，你可以通过命令 git log 查看操作历史。

bash
git flow feature finish your-branch-name

进入测试阶段发 release 分支,创建一个release分支，派生自develop分支。

bash
git flow release start v0.0.1

新版本完成测试后就可以发布该分支了，把release分支合并回master,给本次发布打tag,同时把release分支合并回develop,干掉release分支

bash
git flow release finish v0.0.1

注：最后不要忘记把tag push到服务器git push --tags

热修复分支（Hotfix）开始一个Hotfix:

bash
git flow hotfix start

结束一个hotfix分支，和release一样，同时合并回develop和master

bash
git flow hotfix finish VERSION

总结 ​

Git Flow 代码版本管理策略，它对版本控制较为严格，主要适合开发团队规模较大、开发周期较长，可达几周至几个月的项目，整体四个阶段

  1. 并行开发：使用GitFlow可以实现并行开发，每个新功能都会建立一个新的feature分支，从而和已经完成的功能隔离开来，只有在新功能完成开发的情况下，其对应的feature分支才会合并到主开发分支（develop分支）上。
  2. 协作开发：GitFlow支持多人协同开发，因为每个feature分支上改动的代码都只是为了让某个新的feature可以独立运行。同时也很容易知道每个人都在干什么。
  3. 阶段式发布：当一个新feature开发完成的时候，它会被合并到develop分支，这个分支主要用来暂时保存那些还没有发布的内容，如果需要再开发新的feature，只需要从develop分支创建新分支即可包含所有已经完成的feature。
  4. 支持紧急修复：GitFlow包含了hotfix分支，这种类型的分支是从master上创建出来并做一个紧急的修复，这个紧急修复只影响已经发布的tag，而不会影响正在开发的新feature。

sourceTree 管理 ​

使用sourceTree ，作为一个可视化的git 流程管理，他自带Git之GitFlow工作流 可以更加可视化的进行操作，具体可以参考文章中 Git之GitFlow工作流 | Gitflow Workflow（万字整理，已是最详）

参考文章 ​

Git-flow学习

Git之GitFlow工作流 | Gitflow Workflow（万字整理，已是最详）

Released under the MIT License.

Copyright © 2023-present wcy