首页 文章 精选 留言 我的

精选列表

搜索[稳定],共10000篇文章
优秀的个人博客,低调大师

情绪稳定!别再让Git合并冲突影响你工作了

大家好,我是陈哥,今天想和大家聊聊Git合并冲突解决~ 背景 前几天,我正好收到了一位读者的留言:又又又又遇到了Git合并冲突,解决冲突比写代码还费劲,突然想起SVN的好。该怎么避免Git冲突啊? 我想,比如这样? 在我看来,Git合并冲突是不可避免的。在本文,我想和大家简单分享一下遇到Git冲突该如何解决,希望对大家有所帮助。在此之前,我们先来了解一下Git的合并冲突是什么以及合并冲突的类型有哪些。或者如果只对如何解决Git合并冲突感兴趣,也可以滑至第三部分直接阅读。 一、如何识别Git中的合并冲突? 在Git中,我们在两个不同的分支对同一个文件进行更改,特别是在同一文件的同一行尽心更改,会容易产生合并冲突。在这种情况下,Git无法自动解决这些更改之间的不一致性,它会暂停合并过程,并将冲突标记出来,等待我们手动解决。 举一个简单的合并冲突的示例: 在分支main中工作,并修改了mytext.txt文件的第1行,如Hi world。 切换到分支new-feature,然后对mytext.txt的第二行进行修改,如Hello earth。 当我们准备尝试将new-feature分支合并到main分支时,Git无法自动决定在Hi world和Hello earth之间接受哪一个。因此,Git会提醒合并冲突错误,并告诉我们手动解决冲突。 这时,Git会自动用小于号(<)、等号(=)和大于号(>)注释出冲突行,如下所示: <<<<<<< HEAD(Current Change) Hi world ======= Hello earth >>>>>>> new-feature(Incoming Change) 小于号(<)和等号(=)之间的内容是当前分支(Current Change)中的更改。等号(=)和大于号(>)之间的内容是我们要合并到另一个分支的分支变更。 我们可以自行删除这些注释,再决定如何处理冲突代码行。因此,我们不必将合并冲突看作绊脚石,而可以将其作为需要删除的一些注释以及需要接受或拒绝的内容。 二、Git中合并冲突的类型有那些? 常见的合并冲突有两种类型:内容冲突和结果冲突。 1、内容冲突 我们在两个不同分支上,对同一行代码进行修改,就会发生内容冲突。例如,我们在一个分支的第2行修改了display: flex,又在另一个分支的同一文件的第2行修改了text-align: center。这就是会产生内容冲突,Git会提示我们对代码进行调整。 2、结构合并冲突 结构冲突是指我们在两个不同分支上进行的修改会影响同一个文件。虽然彼此之间不发生逐行冲突,但这些更改会影响文件的结构或组织,如重命名变量、函数、移动代码块等。如果发生结构冲突,Git会提示我们想保留哪些更改。 三、如何解决Git中的合并冲突 既然我们已经了解了Git的合并冲突以及合并冲突的类型,那么我们具体来看看到底该如何解决Git中的合并冲突。 现在许多代码编辑器都能有在本地合并时,解决合并冲突的接口,我将以vscode为例子说明如何解决合并冲突。 1、如何在vscode中解决合并冲突 当我们切换到要合并的分支并运行git merge branch-to-merge时,如果存在冲突,系统会提示我们需要解决。vscode中的界面如下所示: 如果我们还没有准备好解决冲突,可以先通过运行git merge --abort来中止合并。如果想要继续解决冲突,我们有三种方式来解决冲突:接受新的更改、接受当前更改或同时接受两个更改。选择三种方式中的任何一种,就能够解决合并冲突。 2、vscode合并编辑器如何解决Git中的合并冲突 运行git merge <branch-to-merge>后,点击“打开合并编辑器”,会出现如下的三个视图: 左侧是新分支的更改,右侧是当前分支的更改,以及两者下方的预览。Incoming是我们想要合并到目标分支的分支中的更改,而current是我们想要合并到的分支中已有的更改。 在合并编辑器中,可使用以下任一方式开始解决冲突: 逐行查看冲突,通过选择复选框来选泽保留左侧还是右侧更改。 选择“接受传入”按钮以接受所有传入的更改,或选择“接受当前”按钮以保留所有存在冲突的更改的当前版本。 在“结果”窗口中手动编辑代码。 解决合并冲突后,单击“接受合并”按钮即可。 四、合并冲突并非全然是坏事 当然,如果团队在为大型代码库创建了PR,并出现合并冲突,那么还有另一种解决方法。我们可以通过运行git pull --rebase upstream main与main重新绑定。这时,我们会看到一个解决冲突的界面以及包含冲突的文件。完成后,运行git add .、git rebase --continue,然后强制推送到分支。 其实,合并冲突并非全然是坏事,这也是一次代码审查的机会。当我们掌握Git合并冲突的处理方法后,会发现团队协作会变得更加顺畅。如果你们还对Git有任何疑问,欢迎参加禅道·中国行(西安站),我们将采用游戏工作坊的形式带大家学习、了解Git。 最后,希望我的分享可以帮助到你,也欢迎给我留言与我讨论。

优秀的个人博客,低调大师

Xmake v2.9.2 发布,各种细节和稳定性改进

新特性 #5005: 显示所有 API #5003: 添加 build.fence 策略 #5060: 支持 Verilator 静态库目标构建 #5074: 添加xrepo download命令去快速下载包源码 #5086: 添加包检测支持 #5103: 添加 qt ts 构建支持 #5104: 改进 find_program,在 windows 上调用 where 改进查找 改进 #5077: 当构建 x86 目标时,使用 x64 的 msvc 编译工具 #5109: 改进 add_rpathdirs 支持 runpath/rpath 切换 #5132: 改进 ifort/icc/icx 在 windows 上的支持 Bugs 修复 #5059: 修复加载大量 targets 时候卡住 #5029: 修复在 termux 上崩溃问题

优秀的个人博客,低调大师

Flink Hudi 0.10.0 发布,多项重要更新,稳定性大幅提升

随着云数仓技术的不断成熟,数据湖俨然已成为当下最热门的技术之一,而 Apache Hudi 是当下最具竞争力的数据湖格式之一: 拥有最活跃的开源社区之一,周活跃 PR 一直维持在 50+ 水平; 拥有最活跃的国内用户群之一,目前的 Apache Hudi 钉钉群用户已超过 2200+,国内各大厂商都已经布局 Apache Hudi 生态。 Apache Hudi 的活跃度得益于其出色的 file format 设计和丰富的事物语义支持: 类 LSM 的 file format 布局很好的适配了近实时更新场景,解决了超大数据集更新的痛点; Hudi 的事物层语义在目前的湖存储中是极其成熟和丰富的,基本所有的数据治理都可以自动化完成:compaction、rollback、cleaning、clustering。 Flink On Hudi Apache Hudi 的 table format 对流计算友好的特性使得 Flink On Hudi 成为 Apache Hudi 项目最值得探索和挖掘的方向之一,Flink 不仅为 Hudi 解锁了超大数据流的实时更新能力、更添加了流式消费和计算的能力,让端到端近实时 ETL 得以在低成本的文件存储上轻松实现。 Flink On Hudi 项目在 2020 年 11 月立项,至今已迭代了三个版本,从第一个版本开始人气和活跃度就一直高涨。5 月份组建的 Apache Hudi 钉钉群截止目前半年的时间,已经有超过 2200+ 用户,并且活跃度一直排在 Flink 用户群的前列。 Flink On Hudi 已成为部署 Apache Hudi 项目的首选方案,国内主要云厂商:阿里云、华为云、腾讯云,国外的 AWS 都已集成 Flink On Hudi;国内的大型互联网公司:头条、快手、B站 以及传统企业:顺丰、海康等均有 Flink On Hudi 的生产实践,具钉钉群的跟踪回访等不完全统计,至少超过 50+ 国内公司在生产上使用 Flink On Hudi,Uber 公司更将 Flink On Hudi 作为 2022 年的重点方向在推进 ! Flink On Hudi 的开发者生态也非常活跃,目前国内有阿里云、华为云、头条、B站的同学持续贡献,Uber 公司和 AWS 更专门投入人力来对接 Flink On Hudi。 版本 Highlights 0.10.0 版本经过社区用户的千锤百炼,贡献了多项重要的 fix,更有核心读写能力的大幅增强,解锁了多个新场景,Flink On Hudi 侧的更新重点梳理如下: Bug 修复 修复对象存储上极端 case 流读数据丢失的问题 [HUDI-2548]; 修复全量+增量同步偶发的数据重复 [HUDI-2686]; 修复 changelog 模式下无法正确处理 DELETE 消息 [HUDI-2798]; 修复在线压缩的内存泄漏问题 [HUDI-2715]。 新特性 支持增量读取; 支持 batch 更新; 新增 Append 模式写入,同时支持小文件合并; 支持 metadata table。 功能增强 写入性能大幅提升:优化写入内存、优化了小文件策略(更加均衡,无碎片文件)、优化了 write task 和 coordinator 的交互; 流读语义增强:新增参数 earliest,提升从最早消费性能、支持参数跳过压缩读取,解决读取重复问题; 在线压缩策略增强:新增 eager failover + rollback,压缩顺序改为从最早开始; 优化事件顺序语义:支持处理序,支持事件序自动推导。 下面挑一些重点内容为大家详细介绍: 小文件优化 Flink On Hudi 写入流程大致分为以下几个组件: row data to hoodie:负责将 table 的数据结构转成 HoodieRecord; bucket assigner:负责新的文件 bucket (file group) 分配; write task:负责将数据写入文件存储; coordinator:负责写 trasaction 的发起和 commit; cleaner:负责数据清理。 其中的 bucket assigner 负责了文件 file group 的分配,也是小文件分配策略的核心组件。0.10.0 版本的每个 bucket assign task 持有一个 bucket assigner,每个 bucket assigner 独立管理自己的一组 file group 分组: 在写入 INSERT 数据的时候,bucket assigner 会扫描文件视图,查看当前管理的 file group 中哪些属于小文件范畴,如果 file group 被判定为小文件,则会继续追加写入。比如上图中 task-1 会继续往 FG-1、FG-2 中追加 80MB 和 60MB 的数据。 为了避免过度的写放大,当可写入的 buffer 过小时会忽略,比如上图中 FG-3、FG-4、FG-5 虽然是小文件,但是不会往文件中追加写。task-2 会新开一个 file group 写入。 全局文件视图 0.10.0 版本将原本 write task 端的文件视图统一挪到 JobManager,JobManager 启动之后会使用 Javaline 本地启动一个 web server,提供全局文件视图的访问代理。Write task 通过发送 http 请求和 web server 交互,拿到当前写入的 file group 视图。 Web server 避免了重复的文件系统视图加载,极大的节省了内存开销。 流读能力增强 0.10.0 版本新增了从最早消费数据的参数,通过指定 read.start-commit 为 earliest 即可流读全量 + 增量数据,值得一提的是,当从 earliest 开始消费时,第一次的 file split 抓取会走直接扫描文件视图的方式,在开启 metadata table 功能后,文件的扫描效率会大幅度提升;之后的增量读取部分会扫描增量的 metadata,以便快速轻量地获取增量的文件讯息。 新增处理顺序 Apache Hudi 的消息合并大体分为两块:增量数据内部合并、历史数据和增量数据合并。消息之间合并通过write.precombine.field字段来判断版本新旧,如下图中标注蓝色方块的消息为合并后被选中的消息。 0.10.0 版本可以不指定write.precombine.field 字段,此时使用处理顺序:即后来的消息比较新,对应上图紫色部分被选中的消息。 Metadata Table Metadata table 是 0.7.0 Hudi 引入的功能,目的是在查询端减少 DFS 的访问,类似于文件 listings 和 partitions 信息直接通过 metadata table 查询获取。Metadata 在 0.10.0 版本得到大幅加强,Flink 端也支持了 该功能。 新版的 metadata table 为同步更新模型,当完成一次成功的数据写入之后,coordinator 会先同步抽取文件列表、partiiton 列表等信息写入 metadata table 然后再写 event log 到 timeline (即 metadata 文件)。 Metadata table 的基本文件格式为 avro log,avro log 中的文件编码区别于正常的 MOR data log 文件,是由高效的 HFile data block 构成,这样做的好处是自持更高效率的 kv 查找。同时 metadata table 的 avro log 支持直接压缩成 HFile 文件,进一步优化查询效率。 总结和展望 在短短的半年时间,Flink On Hudi 至今已积攒了数量庞大的用户群体。积极的用户反馈和丰富的用户场景不断打磨 Flink On Hudi 的易用性和成熟度,使得 Flink On Hudi 项目以非常高效的形式快速迭代。通过和头部公司如头条、B 站等共建的形式,Flink On Hudi 形成了非常良性的开发者用户群。 Flink On Hudi 是 Apache Hudi 社区接下来两个大版本主要的发力方向,在未来规划中,主要有三点: 完善端到端 streaming ETL 场景 支持原生的 change log、支持维表查询、支持更轻量的去重场景; Streaming 查询优化 record-level 索引,二级索引,独立的文件索引; Batch 查询优化 z-ordering、data skipping。 致谢 最后感谢 Flink Hudi 活跃的社区用户以及开发者,正是有你们一路相伴,Flink On Hudi 才能高效率地演化和迭代;也因为有你们,Flink On Hudi 在实时数据湖方向的探索和实践逐渐成为行业先驱,且越来越成熟 ~

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册