
变基是把本项目的所有提交都列出来按顺序一个个提交到目标分支上去
而合并是把两个分支合并起来,但是旧的分支还是可以启动其他分支,在旧的分支上继续开发
master: A -- B -- C -- M
/
feature: D -- E
master: A -- B -- C
\
feature: D' -- E'
:::success
主动变基和被动变基的区别
:::
没有什么区别变基,只是把合并的一种策略,把两个分支的有差异的提交,单次一次一次的提交到主动要求变基的分支,比如main分支要求变基到feature,意味着把feature所有和main有差异的提交都提交到main,包括时间顺序。
假设之前有个提交出现了bug,就可以使用还原提交查看出bug的节点修改了什么然后把bug之前的节点和bug之后所有节点和bug本次提交。具体如下:

把当前分支重置到此处相当于把此处之后的所有分支都切除了,但是idea提供多个切除方案:

软重置会把提交历史提交信息都删除,但是数据还是保留。硬重置会把提交历史信息和数据都删除,就好像当时节点提交时候的数据。使用idea进行操作的时候只需要注意是否要软重置和硬重置,混合和保留模式并不是很好的体现在idea上面(因为涉及到暂存区,这个东西被Idea屏蔽了)
你在某个节点上编写了很多代码,你想把编写的代码全部去除还原到最新版本,那么就可以使用回滚

就是从某个分支中的提交中获取一个你想要的提交作为一次新提交提交上去,比如说正式版本去测试版本中找到权限控制代码的提交,把权限控制提交作为本节点的新提交,提交到本地,解决好冲突之后,正式版本就可以得到权限控制的代码了,这样做的好处就是测试版本提交了权限控制,但是之后又提交了几个测试功能,但是这几个测试功能的效果并不是很好,正式版本不打算使用只使用权限控制,那么就可以使用cherry pick。
点击收藏夹就可以得到全部分支的提交,选择一个提交到作为新提交,提交上去即可。

补丁在代码开发中的使用确实相对较少。在现代的团队协作和版本控制工具中,如Git,开发人员通常使用分支、合并和拉取请求等功能来管理并发修改和解决冲突。
然而,补丁仍然在某些特定情况下有其用武之地,尤其是在没有直接访问对方代码库或版本控制系统的情况下,或者在需要将更改应用到非版本控制的环境中时。
以下是一些可能使用补丁的场景:
尽管补丁的使用相对较少,但它仍然是一种有用的工具,可以在特定情况下帮助解决代码冲突或将更改应用到不同的环境中。在实际开发中,具体使用补丁的需求会因情况而异。