Git合并时一些鲜为人知的坑

1.  反复解决同一个冲突

最常见的原因:

  多人团队中开启了rebase ,对commit顺序造成破坏,使得merge 其他分支时可能找不到原始commit id的关联信息,就需要重新merge  conflicts.

 

 

2. 明明合并完了,又让从头合并

当然这和用rebase有关的, 关键是已经解决了冲突,为啥还让从头再来一次。问题出在了git pull上。

就像Mark Twain Blaise Pascal笑话里说的那样:我没有时间让它更短些。

最常说的关于git使用的一个经验就是:

不要用git pull,用git fetch和git merge代替它。

git pull 不完全等于 git fetch + git merge

fetch同pull的区别在于:
git fetch:是从远程获取最新版本到本地,不会自动merge.
而git pull是从远程获取最新版本并merge到本地仓库.
从安全角度出发,git fetch比git pull更安全,因为我们可以先比较本地与远程的区别后,选择性的合并。

请看上图, pull不等于fetch+merge这么简单。 pull拉取远程文件直接和本地文件对比,从共同祖先提交开始回放remote的提交,而git merge是本地repo和本地文件的对比合并,这里得用到了repo的索引,这样已经Merge的文件会复用repo中已经解决冲突的信息,这样就不会有从头开始合并了。

git pull的问题是它把过程的细节都隐藏了起来,以至于你不用去了解git中各种类型分支的区别和使用方法。当然,多数时候这是没问题的,但一旦代码有问题,你很难找到出错的地方。看起来git pull的用法会使你吃惊,简单看一下git的使用文档应该就能说服你。

将下载(fetch)和合并(merge)放到一个命令里的另外一个弊端是,你的本地工作目录在未经确认的情况下就会被远程分支更新。当然,除非你关闭所有的安全选项,否则git pull在你本地工作目录还不至于造成不可挽回的损失,但很多时候我们宁愿做的慢一些,也不愿意返工重来。

下面是Git工作流程图。

posted @ 2023-11-17 17:46  sunsky303  阅读(83)  评论(0编辑  收藏  举报
显示搜索