Git的分支模型

gitlab 分支规则GitLab 分支规则是GitLab 中用于管理代码开发的一种规范。

它定义了在代码仓库中创建和管理分支的方法，以便团队成员可以在不影响主线代码的情况下进行并行开发和版本控制。

下面是一篇以人类视角写作的关于 GitLab 分支规则的文章。

标题：GitLab 分支规则：高效协作，顺畅开发一、引言在软件开发的世界中，团队合作和高效开发是至关重要的。

GitLab 分支规则为我们提供了一个强大而灵活的工具，帮助我们更好地管理代码仓库、协作开发和版本控制。

本文将介绍GitLab 分支规则的基本原则和最佳实践，以帮助团队成员更好地利用这一工具。

二、分支的创建与管理1. 主分支（master）：主分支是代码仓库的稳定版本，不应直接在该分支上进行开发。

只有在经过充分测试和验证后，才能将代码合并到主分支。

2. 开发分支（develop）：开发分支是各个开发人员进行并行开发的主要分支。

在开发新功能或修复bug 时，应从develop 分支创建新的特性分支或修复分支。

3. 特性分支（feature）：特性分支用于开发新功能。

每个新功能应在独立的特性分支上进行开发，以便更好地跟踪和管理。

4. 修复分支（bugfix）：修复分支用于解决已知bug。

每个bug 修复应在独立的修复分支上进行，以免与正在开发的其他功能产生冲突。

三、分支的命名规范1. 主分支命名为 master。

2. 开发分支命名为 develop。

3. 特性分支命名为 feature/feature-name，其中 feature-name 是具体的特性名称。

4. 修复分支命名为 bugfix/bug-name，其中 bug-name 是具体的 bug 名称。

四、分支的合并与删除1. 特性分支开发完成后，应向develop 分支发起合并请求，并经过代码审查和测试后合并到 develop 分支。

2. 修复分支修复完成后，应向develop 分支发起合并请求，并经过代码审查和测试后合并到 develop 分支。

git merge 命令原理Git merge命令是Git版本控制系统中用于将一个分支的更改合并到另一个分支中的命令。

这个命令的原理涉及到Git的三个核心概念：commit，tree和blob。

首先，了解一下Git的基本数据结构。

在Git中，所有的数据都是以文件的形式存储在对象库中。

对象库由一系列的对象组成，每个对象都有一个唯一的SHA-1哈希值来标识。

Git的数据模型是基于内容寻址，这意味着每个对象的哈希值都根据其内容计算得出。

首先，我们需要了解commit对象。

在Git中，commit对象用于存储提交信息和指向tree对象的指针。

每个commit对象都有一个SHA-1哈希值来标识。

当我们进行一个commit操作时，Git会创建一个新的commit对象，并将其加入到对象库中。

接下来，我们来了解tree对象。

在Git中，tree对象用于存储文件和目录的层次结构。

每个tree对象都有一个SHA-1哈希值来标识。

当我们进行一个commit操作时，Git会创建一个新的tree对象，该tree对象代表了提交的整个文件和目录结构。

tree对象中保存了文件和目录的名字、类型和sha1哈希值。

最后，我们需要了解blob对象。

在Git中，blob对象用于存储文件的内容。

每个blob对象都有一个SHA-1哈希值来标识。

当我们添加、修改或删除一个文件时，Git会创建一个新的blob对象，并将其加入到对象库中。

现在，我们来看一下merge命令的原理。

假设我们有一个主分支（master）和一个开发分支（dev），我们想要将dev分支的更改合并到master分支中。

1.首先，Git会查找两个分支最近的共同祖先commit对象。

这个共同祖先commit对象是两个分支的最后一个commit对象的最早公共祖先。

Git使用这个共同祖先commit对象来确定两个分支的差异。

2.接下来，Git会创建一个新的合并commit对象，该commit对象有两个父commit对象：一个是当前分支（master）的最后一个commit 对象，另一个是要合并的分支（dev）的最后一个commit对象。

Git图形化⼯具介绍随git分发的默认的图形化⼯具git gui和版本分⽀图形化⼯具gitk。

⼀、GIT GUI主界⾯：各个按钮的意思基本与界⾯⽂字⼀致，与git的命令也差别不⼤。

在了解⾃⼰所做的操作情况下，各个功能点开看下就知道是怎么操作了。

即使不了解，只要不做push操作，所有的操作都在本地，基本也没什么影响。

⼤不了重新下载整个库好了，git下载库的时间确实⽐svn快很多，这也是git优势之⼀。

1.菜单栏：2.⼯作区变更、⽂件差异对⽐：点击⼯作区变更的⽂件，右侧窗⼝会显⽰⽂件差异对⽐。

吐槽下，对⽐的时候显⽰的差异以上下的格式显⽰，差异对⽐的体验⾮常不友好。

3.索引区：使⽤命令git add或点击”stage changed”按钮后，⼯作区变更会添加到该区域。

4.基本操作按钮：stage changed：将⼯作区的所有变更提交到添加到索引区；（其他在菜单栏中都有对应项，介绍菜单栏时⼀并介绍）mit信息输⼊框：⽤于commit时输⼊变更信息，与svn提交时填写的信息⼀样，主要⽅便后续查找或了解该次提交的⽬的。

mit⽅式：创建⼀次新的提交或者修改上⼀次提交。

对应于菜单栏中commit项中，new commit和amend last commit相同。

⼆、GIT GUI菜单栏：repository：git库相关操作，基本意思就是字⾯意思。

1）资源管理器中浏览该Git库⼯作空间⽂件，省去查找路径不断点击⿏标的操作。

2）启动Git bash⼯具（命令⾏⼯具）。

3）查看当前分⽀⽂件状态，不包括未提交的信息。

4）查看某个分⽀的⽂件（弹出框中可选择需要查看的版本、分⽀或标签），跟上⼀条差不多，⽤的⽐较少，可能是没有这⽅⾯的额需求。

5）可视化当前分⽀历史、可视化所有分⽀历史：弹出分⽀操作历史，也就是gitk⼯具，放到gitk⼯具中介绍。

edit：⽤于操作commit时操作信息输⼊，只能操作⽂字输⼊部分，你没有看错。

在Gitee中，分支是代码版本控制的重要组成部分，它允许开发者在不影响主分支的情况下进行并行开发和测试。

以下是关于Gitee分支的详细解释：1.分支的概念：在Git版本控制系统中，分支本质上是指向提交对象的可变指针。

默认情况下，会有一个名为master的分支。

当提交时，master分支会指向最新的提交。

其他分支可以基于master或其他分支创建，并在其上进行独立的开发和修改。

2.分支的创建：在Gitee中，可以通过Web界面或Git命令行工具创建分支。

例如，使用命令git branch <branch_name>可以在本地创建一个新分支，而git push origin<branch_name>可以将本地分支推送到Gitee远程仓库。

3.分支的切换：要切换到其他分支进行开发，可以使用git checkout <branch_name>命令。

切换分支时，HEAD指针会移动到该分支的最新提交上，工作目录也会更新为该提交的状态。

4.分支的合并：当某个分支上的开发完成后，可以将其合并到其他分支。

例如，将功能分支合并到主分支（通常是master或main分支）是一种常见的做法。

合并可以通过git merge <branch_name>命令完成。

如果存在冲突，需要手动解决冲突后再提交合并结果。

5.分支的删除：不再需要的分支可以被删除，以释放存储空间和保持版本控制的清晰。

在本地删除分支可以使用git branch -d <branch_name>命令，而要删除Gitee远程仓库的分支，则需要使用git push origin :<branch_name>命令（注意冒号前面的空格）。

在团队协作中，分支策略非常重要。

常见的分支策略包括：•主分支（master/main）：这是项目的主线，通常用于发布稳定版本。

只有经过测试和审核的代码才会被合并到主分支。

master develop release feature hotfix分支
这些术语通常与Git版本控制系统中的分支管理相关。

以下是这些分支类型的简要概述：
1.Master分支：
通常被视为项目的主分支或生产分支。

用于存储经过测试和验证的稳定代码，通常是已发布的版本。

通常不允许直接在该分支上进行开发，而是通过合并其他分支的代码来更新。

2.Develop分支：
主要用于日常开发工作，开发者在这个分支上开发新的功能。

该分支可能不稳定，因为新功能正在开发中。

3.Feature分支：
从develop分支中创建，用于开发特定的功能或特性。

当功能开发完成后，通常会合并回develop分支（可能也会合并到master分支，这取决于团队的工作流程）。

4.Release分支：
当需要发布新版本时，会从develop分支创建一个release分支。

在这个分支上，团队可以进行最后的调整、修复bug和
准备发布。

当准备就绪后，release分支会合并到master和develop 分支。

5.Hotfix分支：
当在生产环境中发现紧急bug时，会从master分支创建一个hotfix分支。

在这个分支上，开发者会迅速修复bug并进行测试。

一旦修复完成并通过测试，hotfix分支会合并到master 和develop分支。

使用这些分支的目的是保持代码的清晰、有序和稳定，同时允许多个开发者或团队并行工作而不相互干扰。

不同的团队可能会根据他们的具体需求和流程稍作调整。

本地分支解析git 通过可变指针来实现对提交数据的历史版本的控制，每当我们提交新的更新，当前分支(设为master)则指向最后一个提交更新A，而最后一个提交对象则存在一个指针指向前一次的提交更新Q。

如果我们创建一个新的分支，child，它和master共同指向A，这时，如果我们向child分支提交更新B，我们会发现child 指向B，而master依然指向A。

无论我们在child分支进行了任何开发，只要回到master分支，就能恢复到更新A的数据状态了。

在图片里，我们还注意到有一个head指针，一般来说，它会指向我们目前所在的工作分支。

现在它指向了我们的master分支，意思是master是我们目前的工作分支。

一旦提交更新，就会在master分支上提交。

现在，让我们看看与git 分支有关的操作命令：1. git branch [option] [name]如果不使用任何参数，它可以用来查看所有的分支,而在分支名前有*标记的则为主分支，如果加上name为创建新分支，,如git branch child,则会创建一个名为child 的分支，此外，它有一些常用的参数：2. git checkout [name]切换到对应的分支，对于上图，如果我们是使用git checkout child，我们的head 指针就会指向child分支了。

这时候，如果我们提交新的更新D，我们会发现：我们的D指向C，而C依然指向A，也就是说，以后我们在child分支上做的任何更新，都不会对master分支所在的之路造成任何影响！一旦使用了checkout命令，我们还会发现，不仅head指针会指向新的分支，而且当前工作目录中的文件也会换成了新分支对应的文件了。

此外，我们还可以使用git checkout -b [name]命令，它会新建一个分支，并自动将当前的工作目录切换到该分支上。

3. git merge [name]合并分支，有的时候，我们创建次要分支，可能是为了修改原有程序的bug，或为了拓展新的功能，这时候如果我们想把次要分支的修改何并进主分支中，我们可以使用git merge命令来实现。

一个成功的Git分支模型本文中我会展示一种开发模型，一年前该模型就已经被我用在所有的项目中（包括工作中的项目和私有项目），结果是非常成功的。

我早就想为此写点东西，可直到现在才有时间。

本文不会讲述任何项目的细节，只会涉及到分支策略和发布管理。

本文使用Git作为所有源码的版本控制工具。

为什么是Git？要全面了解Git与其它集中式版本控制系统相比的优劣，可以参考这个页面。

这方面的争论可谓是硝烟弥漫。

作为一个开发者，所有这些工具中我最钟情于Git。

Git的的确确改变了人们考虑合并及分支的方式。

在我之前所处的经典CVS/Subversion世界中，合并/分支总是被认为是有点可怕的事情（“小心合并冲突，丫会恶心到你”），因此你只应偶尔干这种事情。

但有了Git，这类事情就变得非常简单，分支及合并甚至被认为是你日常版本控制操作的核心之一。

例如，在CVS/Subversion的书中，分支及合并往往在后面的章节才被介绍（针对高级用户），但在每一本Git的书中，该内容已经在前3章中介绍（基础）。

简单及易重复性带来的好处就是，分支及合并变得不再可怕。

版本控制工具本该帮助我们方便的进行和分支及合并操作。

简单介绍下工具后，让我们来看开发模型。

我讲介绍的模型本质上只是一组步骤，每个团队成员都必须遵循这些步骤以形成一个可靠管理的软件开发过程。

去中心化但仍保持中心化在这个分支模型中我们使用的，且被证实工作得很好的仓库配置，其核心是一个中心―真理‖仓库。

注意只有该仓库才被认为是中心库（由于Git是DVCS [分布式版本控制系统]，在技术层面没有中心库这一东西）。

之后我们用origin指代该仓库，因为大多数Git用户都熟悉这个名称。

每个开发者都对origin做push和pull操作。

不过除了这种中心化的push-pull关系外，每个开发者还可以从其他开发者或者小组处pull变更。

例如，可能两个或更多的开发者一起开发一个大的特性，在往origin永久性的push工作代码之前，他们之间可以执行一些去中心化的操作。

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修复分支。

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

gitlab 分支管理最佳实践
1. 主线分支（Master Branch）：用于存储稳定版本的代码，应该始终处于可部署状态。

2. 开发分支（Development Branch）：从主线分支创建，用于进行新功能开发或修复问题。

开发完成后，应将其合并回主线分支。

3. 特性分支（Feature Branch）：从开发分支创建，用于特定功能的开发。

每个功能都应在自己的特性分支中进行开发。

完成后，应将其合并回开发分支。

4. 修复分支（Fix Branch）：从主线或开发分支创建，用于修复问题。

完成后，应将其合并回相应的目标分支。

5. 合并请求（Merge Request）：在将代码合并到主线或开发分支之前，应创建合并请求。

这有助于代码审查和确保合并的代码质量。

6. 定期合并和清理：定期将开发分支合并回主线分支，以保持代码同步。

同时，删除已经完成的特性分支和修复分支，以保持分支整洁。

7. 分支命名规范：使用有意义的分支名称，以便更好地理解分支的用途。

8. 团队协作：鼓励团队成员之间的协作，通过代码审查和共同开发来提高代码质量。

遵循这些最佳实践可以帮助团队更好地管理 Gitlab 分支，提高开发效率和代码质量。

Jenkins Git 参数化构建前言：参数化，故明思义，调用参数选择分支，以下讲解两种方式，经过亲测痛苦熬制而成，其中重点部分红字标出。

一、首先使用Git Parameter使用1、在jenkins 可选插件里面，选中git parameter Plug-in安装，如果安装不了，可以点我下载文件，在“高级”页面上传安装，同样的效果。

2、3、在工程的配置页面，选中参数化构建，git parameter4、name,这个可以随便取，但是后面要用，一定要一致，（这里提出一个很重要很重要的要点：名称不能包含任何运算符号。

）然后Parameter type ,就是选择branch/tag/branch or tag 三种类型，这个顾名思义，很简单，不赘述了。

第三步，添加git授权方案，可以选择用户名密码、ssh key 等方式，然后使用刚才说的name这个变量5、红色箭头参数写刚刚上面定义的name值这样就已经成功，最终效果为以下图示：将会列出Git仓库所有分支。

优点：他将把Git仓库所有分支都列出来缺点：由于仓库太多，加载会慢，选择会麻烦。

现讲解以下第二种方法，固定其几个分支，后续也可以增加与减少，使用也方便1、选择Choice parameter(自定义参数)2、此地方选择刚刚定义参数的name值，name,这个可以随便取，但是后面要用，一定要一致，（这里提出一个很重要很重要的要点：名称不能包含任何运算符号。

）3、基界面就好像一个选择表单一样4、只显示Choice parameter下你定义的值优点：分支管理文件，安全性高，对应同事只能查看该分支内容，比Git Parameter使用方便。