Git 分支工作之一- Git Flow

2 年 ago
科, 雅
1 minute

开场白

在使用git进行源代码管理时，您采用了什么样的分支策略？

huniki.png

在不同的项目之间，规范可能存在较大差异，甚至在同一个项目中，细细观察也能发现每个人在操作上都有一些微妙的个人习惯。

前者很好。根据项目规模等因素，令人满意的分支策略可能会有所不同。
但是如果分支工作太随意，可能会在迁移项目时导致混乱。

那个选项不好。可能会导致他的开发分支缺少必要的开发功能，或者混入了多余的内容，或者标签使用出错，可能会出现奇怪的问题。

因此，我会调查市井中存在的分支工作。

这次是关于git flow的问题

    • git flow ← ココ

 

    • github flow

 

    gitlab flow

Git flow（一个成功的Git分支模型）

68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f3133313331362f38656665313062622d666663352d366161642d363533342d6635366362333061396538322e706e67.png

突然看到这个图有点复杂。
尝试集中地看每个分支。

开幕的分支

名称役割分岐元マージ先備考master(main)デプロイ可能な環境を保持する。–削除しない。develop次のリリースに向けた開発用master-削除しない。feature機能ごとの開発用developdevelopdevelop へのマージ時には git merge –no-ff が推奨される。releaseバージョン番号の準備やマイナーなバグフィックスなど、開発タスク外のリリースの準備を行う。developmaster, develop
hotfixリリース済みバージョンに対する緊急度の高い修正を行う。mastermaster, develop
(bugfix)緊急度の低いバグフィックスを行うdevelopdevelop
(support)旧バージョンの保守とリリースを行う。master-同時に複数のメジャーバージョンを管理する場合必要になってくる。

在原始图中没有bugfix和support。
一些分支有命名规则（要添加）。

概括一下

    1. 在项目开始时，从 master 创建 develop。

 

    1. 从 develop 逐个功能创建 feature，并在此处进行个人开发工作。

 

    1. 完成功能开发后，如果要立即包含在下一个发布中，则将其合并到 develop。（删除 feature）

 

    1. 下次发布时，所有功能都合并到 develop，并根据项目确定的版本号从 develop 创建 release。

 

    1. 在 release 中进行除功能开发外的该版本发布所需的准备工作。

 

    1. 整理 release 后，将其合并到 develop 和 master。（如不需要，则删除 release）

 

    1. 从 master 进行部署。

 

    在 master 上打版本标签。（如有需要，从 master 派生 support）

擅長

    • 各ブランチの役割が明確

 

    • リリース済みリソースと開発中リソースがしっかり分離している

 

    • 複数のバージョンの開発や修正を同時並行して進行しやすい

 

    将来的にリリースや開発単位での内容の確認がしやすい

弱點

    • 一見してわかる通り、他のブランチ戦略と比べて明らかに複雑

 

    • git 管理に一定の工数がかかる。デプロイ速度を重視しており、毎日デプロイを行いたいようなプロジェクトの場合無視できない。

 

    個人開発や小規模プロジェクトなど複数の機能・バージョンの開発が平行しにくい場合、享受できるメリットが減る。

原文中详细介绍了各个分支的说明和操作方法，还使用了更多的图表和文字。这里所列的内容仅仅是一小部分。但是，我认为这已经涵盖了基本的运营所需的信息。

可以参考

一个成功的Git分支模型

bannerAds