获取git仓库时更新类型update type 的选择

最新推荐文章于 2025-06-22 20:12:15 发布

擦肩而过

最新推荐文章于 2025-06-22 20:12:15 发布

阅读量9.6k

点赞数 2

CC 4.0 BY-SA版权

分类专栏： GitHub

原文链接：https://blog.youkuaiyun.com/qq_40147863/article/details/95956109?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task

GitHub 专栏收录该内容

7 篇文章

订阅专栏

本文深入解析Git中的更新类型，包括Merge和Rebase的区别与应用场景。Merge适用于完成代码整合，保留分支历史；Rebase则用于代码同步，保持分支清洁。详细对比了两者在时间线展示、代码冲突处理及代码整洁度上的不同。

获取git仓库时更新类型update type 的选择

参考一下图解即可

注意：

Update Type 选择

Merge：结果与运行 git fetch ; git merge 或结果相同 git pull。
Rebase：结果与运行 git fetch ; git rebase 或结果相同 git pull --rebase。
Branch Default：此选项用于选择应用分支的默认命令。default 命令 branch. 在 .git/config 配置文件的部分中指定。
使用场景：

Merge：因为成员的代码开发工作已经完成了，也不需要再保留这个分支了，所以我们可以把这个成员分支 merge 到主分支上，当然冲突在所难免，手工解决的工作肯定逃不掉，但是利大于弊不是吗。merge 以后，分支就不存在了，但是在 Git 的所有分支历史中还能看到身影。

Rebase：如果修改了某个公用代码的 BUG，这个时候就应该是把所有的 OEM 版本分支 rebase 到这个修复 BUG 的分支上来，在 rebase 过程中，Git 会要你手动解决代码上的冲突，你需要做的就是把修复 BUG 的代码放到目标分支代码里面去。rebase 的结果是：所有的分支依然存在。

比如说自己在自己分支开发了一段时间，之后另外的同事开发的功能正式上线到 master 分支了，那么我可以在当前的分支下 rebase 一下 master 分支，这样我这个分支的几个 commits 相对于 master 还是处于最顶端的，也就是说 rebase 主要用来跟上游同步，同时把自己的修改顶到最上面

merge 结果能够体现出时间线，但是 rebase 会打乱时间线。
而 rebase 看起来简洁，但是 merge 看起来不太简洁。
最终结果是都把代码合起来了，所以具体怎么使用这两个命令看项目需要。
还有一点说明的是，在项目中经常使用git pull来拉取代码，git pull相当于是git fetch + git merge，如果此时运行git pull -r，也就是git pull –rebase，相当于git fetch + git rebase
————————————————
版权声明：本文为优快云博主「肖朋伟」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/qq_40147863/article/details/95956109