git merge fast-forward squash no-ff

本文探讨了在Android Studio上合并分支后,GitHub Desktop中分支提交信息丢失的问题,并介绍了三种Git合并方式的区别及如何在GitHub设计下优化工作流程。详细解释了fast-forward、no-fast-forward和squash合并策略,以及如何使用这些策略避免在master分支上丢失测试分支的提交记录。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

看了下 git merge 的相关知识 
发现还是不能很好的解决 在Android studio 上 git合并分支 后,
在github desktop 的被合并的分支的提交信息丢失的问题



为了描述方便, 命名一下两个分支 
master ,  test
merge  是 master 去 merge test 分支
不管以何种 megre 策略  最后 在test 的提交记录 依然在 test分支上,
在master 上会有一条 merge 产生那个的新的提交记录

但是一般我们在Android Studio 看master 提交记录的时候, 还是能够看到 合并来的 test 上的提交记录

但是在github desktop 上就看不到 合并来的 test的提交记录  
最后一个条 合并产生的提交记录:

我想这大概是  github 的问题
顺便还看了 git rebase 相关的动向, 发现那玩意根本不适用, 不能解决核心问题.


其实 github这样设计 也是有它的道理的,
如果我们只看master 分支的提交记录的话, 可以很清晰的看到 其他分支的合并时 提交的记录

我想 github 是想我们不要手动在master 分支上写代码提交,
而是单独开一个分支,  写代码, 然后在把 这个分支合并到master 上去,

这样master 分支 只需要关注 这个分支实现了什么功能

具体在这个分支 里面的多次提交 不需要太在乎, 需要的话 自己前往分支查看

ok 以后代码 就这样写了

做一些  总结 git 一班有以下 三种 merge 方式:
fast-forward
no fast forward
squash

git merge 默认使用的 fast-forward 的合并方式:
下面三种合并法师的区别:


fast-forward方式就是当条件允许的时候,git直接把HEAD指针指向合并分支的头,完成合并。属于“快进方式”,不过这种情况如果删除分支,则会丢失分支信息。因为在这个过程中没有创建commit

squash 是用来把一些不必要commit进行压缩,比如说,你的feature在开发的时候写的commit很乱,那么我们合并的时候不希望把这些历史commit带过来,于是使用--squash进行合并,此时文件已经同合并后一样了,但不移动HEAD,不提交。需要进行一次额外的commit来“总结”一下,然后完成最终的合并。

--no-ff指的是强行关闭fast-forward方式。


一些产考连接:
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值