【Git】分支管理

【Git】分支管理

目录

一、 分支

每次提交,Git都把它们串成⼀条时间线,这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前,只有⼀条时间线,在Git⾥,这个分⽀叫主分⽀,即 master 分⽀。
再来理解⼀下HEAD,HEAD 严格来说不是指向提交,⽽是指向master,master才是指向提交的,所以,HEAD指向的就是当前分⽀。HEAD 也是可以指向其他分支,被 HEAD 指向的分支就是当前正在工作的分支。

二、创建分支git branch [分支名]

我们可以使用git branch 命令查看当前本地的所有分支。

创建第⼀个⾃⼰的分⽀ dev:git branch dev


三、切换分支 git checkout [分支名]

要想切换分支,使⽤ git checkout [分支名] 命令即可完成切换。

看两个分支的commit id是不一样的

切回 dev 看看,又还在。

我们再切回master分支,会发现我们在dev分支做的修改不见了

我们先在当前分支提交修改后的ReadMe文件。

我们在当前分支修改ReadMe文件

造成上面的结果,是因为两个分支执行的提交是不一样的:相当于下图

四、合并分支git merge [分支名]

为了在 master 主分⽀上能看到新的提交,就需要将 dev 分⽀合并到 master 分⽀。使用git merge [分支名]合并操作,合并后就能在master分支上看见修改后的ReadMe了。

现在就相当于:

Fast-forward 代表“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度⾮常快。当然,也不是每次合并都能 Fast-forward。

五、删除分支git branch -d [分支名]

我们在上面完成了合并分支的操作,那么dev分支的使命也就结束了。使用git branch -d [分支名]就可以删除该分支了

但是注意我们不能在该分支目录下,删除不被允许。

六、合并冲突:手动修改

情景:当我们使用本地分支dev修改文件时,master分支同时也在修改该文件。git 就没办法知道保留dev修改的文件还是保留master分支修改的
本地修改:



master分支修改:

合并造成冲突:


ReadMe文件:

此时就需要我们手动看保留哪个代码


再重新add commit 和merge 即可:git log --graph --pretty=oneline --abbrev-commit查看分支合并情况

七、合并模式 --no-ff 强制禁⽤ Fast forward 模式

我们在前面介绍分支合并的时候讲过通过merge提交,git是默认使用 fast forward 直接修改 master指向的方式。

通过fast forward 模式会有删除分支后,查看分支信息的时候没有记录的情况出现,这样就会不知道这串修改到底是合并进来还是一直都在master分支下的。

但是我们在上面面对合并冲突后,我们手动修改在merge就会显示分支信息。Git ⽀持我们使用 --no-ff 强制禁⽤ Fast forward 模式,那么就会在 merge 时⽣成⼀个新的 commit ,这样,从分⽀历史上就可以看出是合并过的。
语法:git merge --no-ff -m "描述" [分支名]

八、分⽀管理策略

master主分支要保持稳定的。

由于很多人都可以在master拉分支,实现自己的开发,所以团队合作的分⽀就像下图一样:

8.1 bug分支 stash命令

情景:假如我们现在正在 dev 分⽀上进⾏开发,开发到⼀半,突然发现 master 分⽀上⾯有 bug,需要解决。在Git中,每个 bug 都可以通过⼀个新的临时分⽀来修复,修复后,合并分⽀,然后将临时分⽀删除。此时 dev 还没开发完,无法提交 的处理场景。

Git 提供了 git stash 命令,可以将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来。

我们使用了stash 命令之后,我们就可以在master分支上创建分支修改bug,修改完成后提交即可。那我们如何继续 dev 的开发工作呢?可以看到我们直接切回去后,是没有当时还没写完的代码的。

git stash pop 命令恢复工作区代码


另外,恢复现场也可以采⽤ git stash apply 恢复,但是恢复后,stash内容并不删除,你需要⽤ git stash drop 来删除;
你可以多次stash,恢复的时候,先⽤ git stash list 查看,然后恢复指定的stash,⽤命令git stash apply stash@{0}

当我们写完dev分支代码后,跟master合并,master在前面跟修改bug的分支合并了,此时就可能导致dev和master合并冲突,那我们此时去手动修改冲突,有可能又出现bug。

解决方法:
在⾃⼰的分⽀上合并下 master ,再让 master 去合并dev ,这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试,⽽不影响 master 。

8.2 强制删除分支 git branch -D [分支名]

情景:当我们开发的这个分支代码突然不需要了。我们要删除已经 commit 的分支,就要使用 git branch -D [分支名]删除。

Read more

API网关设计模式实战 Spring Cloud Gateway路由过滤限流深度解析

API网关设计模式实战 Spring Cloud Gateway路由过滤限流深度解析

目录 ✨ 摘要 1. API网关:微服务架构的"交通枢纽" 1.1 为什么需要API网关? 1.2 Spring Cloud Gateway vs 传统方案 2. Spring Cloud Gateway架构深度解析 2.1 核心架构设计 2.2 响应式编程模型 3. 路由机制:流量指挥的艺术 3.1 静态路由配置 3.2 动态路由实现 3.3 服务发现集成 4. 过滤器链:请求处理的灵魂 4.1 过滤器类型与执行顺序 4.2 常用内置过滤器详解 4.

By Ne0inhk
SkyWalking - Kafka _ RabbitMQ 消息链路追踪支持

SkyWalking - Kafka _ RabbitMQ 消息链路追踪支持

👋 大家好,欢迎来到我的技术博客! 📚 在这里,我会分享学习笔记、实战经验与技术思考,力求用简单的方式讲清楚复杂的问题。 🎯 本文将围绕SkyWalking这个话题展开,希望能为你带来一些启发或实用的参考。 🌱 无论你是刚入门的新手,还是正在进阶的开发者,希望你都能有所收获! 文章目录 * SkyWalking - Kafka / RabbitMQ 消息链路追踪支持 🚀 * 为什么需要消息链路追踪?🤔 * SkyWalking 核心概念回顾 🔍 * Kafka 链路追踪支持 🐘 * 1. 自动探针(推荐)✅ * 前提条件 * 工作原理 * Java 代码示例(无需修改业务代码!) * 验证追踪效果 * 2. 手动埋点(高级场景)🛠️ * 添加依赖 * 手动注入上下文(Producer) * 手动提取上下文(Consumer) * RabbitMQ 链路追踪支持 🐇 * 工作原理 * Java 代码

By Ne0inhk
Flutter for OpenHarmony:Flutter 三方库 auto_mappr 自动化对象映射神器(架构瘦身引擎)

Flutter for OpenHarmony:Flutter 三方库 auto_mappr 自动化对象映射神器(架构瘦身引擎)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net。 前言 在构建大型鸿蒙(OpenHarmony)商业应用时,我们经常需要处理三种对象模型: 1. Entity/Model:直接对应后端 API 或数据库底层。 2. DTO (Data Transfer Object):用于数据传输。 3. ViewModel/Domain Object:供鸿蒙 UI 页面直接渲染。 手动编写这些对象之间的转换函数(如 toDomain())不仅极其乏味,还容易漏掉字段。auto_mappr 是一个基于代码生成的映射框架,它能帮你自动化生成这些零碎的转换代码,让你的鸿蒙工程架构瞬间“瘦身”。 一、原理解析 / 概念介绍 1.1 基础概念 auto_mappr 就像是一个智能的“搬运工”

By Ne0inhk
Flutter 三方库 m_list 的鸿蒙化适配指南 - 实现具备高阶谓词过滤与异步分片的增强列表处理、支持端侧集合数据的高效变换与分布式序列化实战

Flutter 三方库 m_list 的鸿蒙化适配指南 - 实现具备高阶谓词过滤与异步分片的增强列表处理、支持端侧集合数据的高效变换与分布式序列化实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 m_list 的鸿蒙化适配指南 - 实现具备高阶谓词过滤与异步分片的增强列表处理、支持端侧集合数据的高效变换与分布式序列化实战 前言 在进行 Flutter for OpenHarmony 的大规模数据处理、商品列表分析或复杂的日志检索应用开发时,原生 Dart 的 List 虽然提供了基础的集合操作,但在处理分页加载、深度克隆、频率统计以及复杂的并集/交集运算时,代码往往会变得碎片化。m_list 是一款专为高效列表操作设计的增强库。本文将探讨如何在鸿蒙端构建极致、清爽的集合处理模型。 一、原直观解析 / 概念介绍 1.1 基础原理 m_list 建立在一套强大的“谓词逻辑(Predicate Logic)”和“链式变换”之上。

By Ne0inhk