GIT Flow分支与流程说明

GIT-Flow分⽀与流程说明GIT Flow 分⽀说明●主分⽀主分⽀是所有开发活动的核⼼分⽀。

所有的开发活动产⽣的输出物最终都会反映到主分⽀的代码中。

主分⽀分为master分⽀和development分⽀。

●master分⽀master分⽀上存放的应该是随时可供在⽣产环境中部署的代码（Production Ready state）。

当开发活动告⼀段落，产⽣了⼀份新的可供部署的代码时，master分⽀上的代码会被更新。

同时，每⼀次更新，最好添加对应的版本号标签（TAG）。

●develop分⽀develop分⽀是保存当前最新开发成果的分⽀。

通常这个分⽀上的代码也是可进⾏每⽇夜间发布的代码（Nightly build）。

因此这个分⽀有时也可以被称作“integration branch”。

当develop分⽀上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经⾜够稳定时，就可以将所有的开发成果合并回master分⽀了。

对于master分⽀上的新提交的代码建议都打上⼀个新的版本号标签（TAG），供后续代码跟踪使⽤。

因此，每次将develop分⽀上的代码合并回master分⽀时，我们都可以认为⼀个新的可供在⽣产环境中部署的版本就产⽣了。

通常⽽⾔，“仅在发布新的可供部署的代码时才更新master分⽀上的代码”是推荐所有⼈都遵守的⾏为准则。

基于此，理论上说，每当有代码提交到master分⽀时，我们可以使⽤Git Hook触发软件⾃动测试以及⽣产环境代码的⾃动更新⼯作。

这些⾃动化操作将有利于减少新代码发布之后的⼀些事务性⼯作。

●辅助分⽀辅助分⽀是⽤于组织解决特定问题的各种软件开发活动的分⽀。

辅助分⽀主要⽤于组织软件新功能的并⾏开发、简化新功能开发代码的跟踪、辅助完成版本发布⼯作以及对⽣产代码的缺陷进⾏紧急修复⼯作。

这些分⽀与主分⽀不同，通常只会在有限的时间范围内存在。

辅助分⽀包括：⽤于开发新功能时所使⽤的feature分⽀；⽤于辅助版本发布的release分⽀；⽤于修正⽣产代码中的缺陷的hotfix分⽀。

Git--分⽀管理策略（Gitflow）说明:场景：我们公司的开发阶段主要分为开发—>⾃测—>提测—>灰度—>上线这5个阶段，同时在开发阶段会有多个功能同时开发或⼀些简单需求的插⼊。

在其他阶段也会涉及到线上bug的修复或紧急发版。

遇到问题：以前团队⼈数较多，经历两年的积累，Git上遗留了⼤量的个⼈分⽀和版本分⽀，⾄今⼤约有300多个，作为新⼈的我着实有点慌乱（⽼员⼯：“我就问你感动不感动？”。

我：“不敢动，不敢动”）。

虽然经历了⼀番调整，⽬前在⽤分⽀数保持在3个左右，但是由于没有成体系的分⽀管理策略，还是会在⼀定场景下遇到代码遗漏，分⽀杂乱，难以定位版本和修改记录的现象。

因此特意参考了⼏篇⽂章，针对公司项⽬开发实践，对Git flow分⽀管理⽅式进⾏实践和总结。

如有更佳实践⽅案，欢迎留⾔讨论！简介：Gitflow⼯作流程围绕项⽬发布定义了严格的分⽀模型。

其特⾊在于，它为不同的分⽀分配了⾮常明确的⾓⾊，并且定义了使⽤场景和⽤法。

除了⽤于功能开发的分⽀，它还使⽤独⽴的分⽀进⾏发布前的准备、记录以及后期维护。

（此段为摘抄内容，不再赘述）参考《git flow的使⽤》Git flow分⽀结构图分⽀⾓⾊说明：Git flow中每个分⽀担任不同的⾓⾊，有着不同的功能，以下将结合使⽤场景，从功能和⽣命周期两⽅⾯进⾏说明。

master分⽀功能：master分⽀为主⼲分⽀，是所有分⽀的源头。

Gitflow中master分⽀只有⼀个作⽤，即记录已发布的版本节点。

如需追踪某个线上版本的代码，只需切换到对应标签（tag）即可。

⽣命周期：master是仓库创建时Git提供的默认分⽀，随仓库的创建⽽创建，随仓库的消亡⽽消亡。

当然，可以⾃⾏创建master分⽀取代默认分⽀，但主分⽀应贯穿仓库的整个⽣命周期。

master分⽀develop分⽀功能： develop分⽀记录了开发阶段所有的历史提交，⽤来汇总所有新功能的内容。

gitflow使⽤步骤Mac安装git-flow：brew install git-flow克隆新代码：git clone git@:abc/test.git切换到远程的develop分⽀（很重要）：git checkout develop （⽬的是为了和远程的分⽀关联起来）使⽤ git-flow，从初始化⼀个现有的 git 库内开始:git flow init新分⽀的开发是基于 'develop' 分⽀的（这个操作创建了⼀个基于'develop'的特性分⽀，并切换到这个分⽀之下）：git flow feature start MYFEATURE发布新分⽀到远程服务器：git flow feature publish MYFEATURE完成开发新分⽀。

这个动作执⾏下⾯的操作.合并 MYFEATURE 分⽀到 'develop'删除这个新特性分⽀切换回 'develop' 分⽀git flow feature finish MYFEATUREpull操作就⽤基本的 git pull 或者 git pull origin develop 就⾏，也可以使⽤：git flow feature pull origin MYFEATURE从 'develop' 分⽀开始创建⼀个 release 分⽀。

git flow release start RELEASE将release分⽀发布到远程：git flow release publish RELEASE完成 release 版本完成 release 版本是⼀个⼤ git 分⽀操作。

它执⾏下⾯⼏个动作：归并 release 分⽀到 'master' 分⽀⽤ release 分⽀名打 Tag归并 release 分⽀到 'develop'移除 release 分⽀git flow release finish RELEASE。

acorn software git branch一、主分支MasterGit主分支的名字，默认叫做Master。

它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

二、开发分支Develop主分支只用来分布重大版本，日常开发应该在另一条分支上完成。

我们把开发用的分支，叫做Develop。

这个分支可以用来生成代码的最新隔夜版本（nightly）。

如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。

Git创建Develop分支的命令：git checkout -b develop master将Develop分支发布到Master分支的命令：# 切换到Master分支git checkout master# 对Develop分支进行合并git merge --no-ff develop三、临时性分支除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。

临时性分支主要有三种：* 功能（feature）分支* 预发布（release）分支* 修补bug（fixbug）分支这三种分支都属于临时性需要，使用完以后，会删除，使得代码库的常设分支始终只有Master和Develop。

四、功能分支功能分支，是为了开发某种特定功能，从Develop分支上面分出来的。

开发完成后，要再并入Develop。

功能分支的名字，采用feature-*的形式命名。

创建一个功能分支：git checkout -b feature-x develop开发完成后，将功能分支合并到develop分支：git checkout developgit merge --no-ff feature-x删除feature分支：git branch -d feature-x五、预发布分支预发布分支，是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

分支管理规则master分支master作为主分支需要和生产环境保持一致并保持稳定。

在项目开始时由master分支创建dev分支。

发布版本时需要将release合并到master并打tag。

分支规则说明分支权限开发负责人、开发人员允许操作研发组长创建分支。

开发人员提交分支派生分支无来源分支master，develop创建时点任务开始创建创建方式git branch -b feaure_X master提交时点本机测试完成后提交至feature_X分支提交来源开发人员本地仓库合并方式无锁定时点无删除时点发布release后发布环境无发布时点无发布人员无命名规则命名规则为feature_任务英文描述。

示例：feature_traing4UIhotfix缺陷修复分支用于在线版本缺陷修复。

每次版本发布后，生产系统如果发现bug，由本次版本负责人从最新的release分支创建缺陷修复分支。

X代表创建当天日期。

示例：hotfix_20210308。

自测通过后，才允许合并release_X分支进行测试。

分支规则说明分支权限版本负责人、开发负责人允许操作版本负责人创建分支。

开发人员提交代码。

派生分支无来源分支release_X创建时点需要修复线上bug创建方式git branch -b hotfix_X release_X提交时点本机测试完成后提交hotfix_X提交来源开发人员仓库合并方式无锁定时点无删除时点修复内容在生产环境测试通过时发布环境开发环境或者测试环境发布时点按需提交发布发布申请，审核通过后发布发布人员版本负责人命名规则X代表创建当天日期。

示例：hoxfix_20210308develop分支develop分支用于版本开发。

项目初始化时，由项目负责人从master分支创建develop分支。

develop分支仅允许发布至开发环境。

用于功能测试。

feature_X分支在本地调试完成后发起mr到develop并触发自动构建develop分支。

Gitflow⼯作流程在⼯作场合实施的时候，有很多种⼯作流程可供选择，此时反⽽会让你⼿⾜⽆措。

本⽂罗列了企业团队最常⽤的⼀些⼯作流程，包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。

愿以此⽂抛砖引⽟。

在你开始阅读之前，请记住：这些流程应被视作为指导⽅针，⽽⾮“铁律”。

我们只是想告诉你可能的做法。

因此，如果有必要的话，你可以组合使⽤不同的流程。

（本⽂主要介绍Gitflow Workflow……）imgVincent Driessen曾经写过⼀篇博⽂，题为“”（⼀个成功的Git分⽀模型）。

Gitflow⼯作流程就是从这篇⽂章⾥来的。

Gitflow⼯作流程围绕项⽬发布定义了严格的分⽀模型。

尽管它⽐Feature Branch Workflow更复杂⼀些，但它也为管理更⼤规模的项⽬提供了坚实的框架。

与Feature Branch Workflow⽐起来，Gitflow流程并没有增加任何新的概念或命令。

其特⾊在于，它为不同的分⽀分配了⾮常明确的⾓⾊，并且定义了使⽤场景和⽤法。

除了⽤于功能开发的分⽀，它还使⽤独⽴的分⽀进⾏发布前的准备、记录以及后期维护。

当然，你还是能充分利⽤Feature Branch Workflow的好处：拉拽请求（Pull Request）、隔离的试验以及更⾼效率的合作。

它是怎么⼯作的？Gitflow流程仍然使⽤⼀个中央代码仓库，它是所有开发者的信息交流中⼼。

跟其他的⼯作流程⼀样，开发者在本地完成开发，然后再将分⽀代码推送到中央仓库。

唯⼀不同的是项⽬中分⽀的结构。

⽤于记录历史的分⽀Gitflow使⽤两个分⽀来记录项⽬开发的历史，⽽不是使⽤单⼀的master分⽀。

在Gitflow流程中，master只是⽤于保存官⽅的发布历史，⽽develop分⽀才是⽤于集成各种功能开发的分⽀。

Gitflow的使用流程和规范简介Gitflow是一种在Git版本控制系统中使用的工作流程模型，它提供了一种有条理而结构化的方式来管理代码分支，适合中大型开发团队使用。

本文将介绍Gitflow的基本使用流程和规范。

使用流程Gitflow基于两个长期分支（main和develop）以及多个短期分支进行工作。

下面是Gitflow的主要使用流程：1.创建主分支：首先，我们需要在Git仓库中创建两个主要分支，即main和develop。

通常，main主分支用于稳定版本的发布，而develop分支用于集成所有功能的开发。

2.功能开发分支：当需要开发某个新功能时，我们从develop分支创建一个新的功能分支。

命名规范建议以功能名为前缀，例如feature/login。

3.开发新功能：在功能分支上进行新功能的开发和测试。

这是一个短期分支，只用于开发特定的功能。

4.完成开发：当新功能开发完成并通过测试后，我们将其合并回develop分支。

这意味着新功能已经被集成到了整个项目中。

5.发布准备分支：当develop分支中积累了足够多的功能，我们可以创建一个发布准备分支。

此分支用于准备即将发布的版本，可以进行最后的调试、测试和版本号更新等操作。

6.发布版本：当发布准备分支已经完成并通过测试时，我们将其合并回main分支，并给该版本分配一个唯一的版本号。

这意味着该版本已经正式发布。

7.维护分支：在发布版本后，我们可能需要继续对已发布版本进行Bug修复或者发布新的小版本。

这时，我们从main分支创建一个维护分支，以提供对发布版本的长期维护支持。

规范为了使Gitflow工作流正常运行且易于管理，以下是一些Gitflow的规范建议：•分支命名规范：分支的命名应该有一定的规范，以便于说明分支所代表的功能或操作。

例如，使用feature/前缀表示功能分支，hotfix/前缀表示Bug修复分支。

•提交信息规范：每个提交都应该附带一个有意义的提交信息，描述提交所做的更改。

如何进行软件产品的版本管理与发布GitFlow工作流程实践如何进行软件产品的版本管理与发布：在软件开发过程中，版本管理和发布是非常重要的环节，能够保证软件的质量、稳定性和可维护性。

GitFlow工作流程是一种常用的版本管理和发布策略，下面将介绍如何进行软件产品的版本管理与发布，以及如何实践GitFlow工作流程。

1. 版本管理的重要性版本管理是指对软件代码和功能进行控制和管理，以便在开发过程中能够追踪、回溯和修复问题。

通过版本管理，可以方便团队成员协作、保证代码的正确性和稳定性，同时也为后续版本的发布奠定基础。

2. GitFlow工作流程介绍GitFlow是一种流行的Git分支管理策略，它定义了多个分支，并规定了各个分支的作用和流转方式。

常用的分支包括主分支（master）、开发分支（develop）、功能分支（feature）、发布分支（release）和修复分支（hotfix）等。

3. 版本管理与发布步骤（1）创建仓库和分支：首先，创建一个仓库来存放代码，并创建主分支（master）和开发分支（develop）。

主分支用于存放稳定版本的代码，开发分支用于存放最新的开发代码。

（2）功能开发：根据需求，从开发分支创建功能分支（feature），专门用于开发某个功能。

在功能分支上进行开发和测试，并定期将功能分支合并到开发分支，保证代码的稳定性和完整性。

（3）版本发布：当功能开发完成后，从开发分支创建发布分支（release）。

在发布分支上进行最后的测试、修复和准备工作，包括修改版本号、编写更新日志等。

在发布分支测试通过后，将发布分支合并到主分支和开发分支。

（4）Bug修复：在发布分支测试过程中，如果发现问题需要紧急修复，可以从主分支创建修复分支（hotfix）。

在修复分支上进行问题修复，并将修复分支合并到主分支和开发分支。

（5）版本发布：当修复分支合并到主分支后，可以发布新版本，并根据需要对代码进行打包和部署，以便用户使用。

Git flow 实践手册参与人员发布记录作者简介Elson，网名小肥鱼，花城原著居民，网络专业科班出身，英文水准估计有美国幼儿园小朋友三成功力，读书时候喜欢参加比赛，没拿过国家级奖项；毕业多年一直在IT行业打滚，曾做过Oracle ERP功能顾问，对企业管理有一定认识；也尝试过带小团队从事外包开发；擅长php，是Zend认证php工程师，另外对Java，python和ruby略有认识。

不是技术狂人，不刻意追求系统运行性能。

由于性格上喜欢偷懒，所以总希望能用最少的代码实现最多的功能；喜欢事情有条理，所以想尽办法避免一切可能导致情况失控的因素出现；喜欢电子商务，觉得在网上做买卖很cool，很有成就感。

现供职于国内某高速成长的电子商务公司，主要从事网站系统编码工作。

一，概述Git是一个分布式版本控制软件，由Linux的发明人Linus开发并维护，其开发的目的是为了方便成百上千的Linux内核开发人员协同开发。

Git flow是一套根据Vincent Driessen总结的Git最佳实践方法而编写的Git指令快捷命令。

它主旨是方便开发人员更容易地使用Git进行版本控制。

二，安装这里讲解的是如何在Windows上安装Git Flow。

所要用到的软件都在附带的附件包里面，其中包涵以下四个文件。

首先安装Git-1.7.4-preview20110204.exe，然后分别把bin.zip文件和git-core.zip文件解压到“X:\Program Files\Git\bin”目录和“X:\ProgramFiles\Git\libexec\git-core”下。

这样子就已经把git flow安装到windows上了。

假如以前有使用TortoiseSVN的开发人员刚开始不习惯Git的使用，可以安装Tortoisegit-1.6.5.0-32bit.exe。

这是一个类似TortoiseSVN的工具。

可以帮助SVN用户过渡到Git上。

git 工作流程Git工作流程是指团队协作中采用的一种代码管理和版本控制方式。

下面将介绍一种常见的Git工作流程- 分支开发工作流。

在分支开发工作流中，每个成员在本地都有自己的工作分支。

下面是具体的工作流程：1. 创建分支：每个成员从主分支（通常是master分支）创建自己的开发分支。

可以使用命令`git checkout -b branch_name`来创建并切换到新分支上。

2. 开发：成员在自己的分支上进行代码开发和修改。

可以根据需要创建更多的新分支，例如用于修复bug或开发新功能等。

3. 提交更改：当成员完成某个功能或修复了一个bug后，可以使用`git add file_name`和`git commit -m "commit message"`命令将更改提交到本地仓库。

可重复这一步骤多次，直到所有的更改都已提交。

4. 同步远程仓库：为了与团队成员共享成果，需要将本地仓库的分支推送到远程仓库。

可以使用`git push originbranch_name`命令将本地分支推送到远程仓库。

5. 提交合并请求：当某个功能或修复经过测试并通过后，使用代码托管平台（如GitHub、GitLab等）提供的功能，创建一个合并请求。

通过合并请求，其他成员或项目负责人可以查看代码并进行审核。

6. 合并分支：如果合并请求通过审核，可以选择将分支合并到主分支或其他分支。

可以使用代码托管平台提供的界面操作，也可以使用`git checkout target_branch`和`git mergesource_branch`命令手动合并。

7. 删除分支：当某个分支的工作已经完成且合并到其他分支后，可以删除该分支。

使用`git branch -d branch_name`命令来删除分支。

通过以上的工作流程，团队成员可以在自己的分支上独立开发，无需担心冲突。

同时，合并请求和代码审查的过程可以保证代码质量和稳定性。