所谓多余的merge信息,指的是当自己提交代码时,发现远端代码有更新,这时虽然自己的代码成功push,但会多一条merge信息,像这样:
merge branch 'feature/login' of ssh://gitlab.aaa.net/project/main-web into feature/login
上面为示例信息,feature/login指开发分支,ssh://gitlab.aaa.net/project/main-web指代码仓库地址。(此处为随意写的,不代表真实信息)。
你可能会有一个疑问,这仅仅是多一条merge信息而已,代码同步的目的达到了,又何必在意 呢?
事实上,你的确可以忽略掉,但有几条理由支持你优化一下:
- 分支会出现分叉。
- 提交记录不再纯净,出现冗余的无用信息。
- 你需要清楚的知道这中间git发生了什么,导致这种现象产生,又该如何避免,这可以增进你对git工作方式的认识。
所以,仍然建议去掉这种多余的merge信息。
根本原因在于自己拉取代码时,使用了git pull。
这种使用git pull的行为是有意的或者无意的,当你使用诸如vscode的git工具的菜单操作时,可能是无意的。而有意是指,你推送代码之时,发现远程有更新,需要先拉取远程代码到本地,然后才能推送,这时你先使用了git pull。
你可能感到疑惑:git pull为什么会多出这种merge信息呢?
原因在于git pull事实上相当于git fetch加上git merge操作。
首先,git fetch将远端的更新获取到本地,但这也仅仅是获取,还没有合并到我们的本地的分支中。
第二个步骤——合并是必不可少的,因为只是获取到本地,而不合并,那么远端的更新事实上并没有真正更新到我们本地分支中。我们的本地分支必须接纳了远端更新,才能推送,这个接纳也就是merge的过程。
merge branch 'feature/login' of ssh://gitlab.aaa.net/project/main-web into feature/login
这表明,我们的本地分支,不但获取了远端更新,还将获取到的更新合并到本地分支。
而后,我们再将代码推送到远端,自然会有额外的这一个merge信息。
git pull并非是必然出现这种情况,出现这种情况的条件是:
本地有领先远端的commit,同时远端也有领先本地的commit。
假设本地并没有commit,那么git pull并不会产生额外的merge信息,因为本地和远端没有分叉(可以通俗理解成分歧),无需产生额外的合并节点。
假设远端没有额外的commit,自然获取不到远端的更新,也不会产生合并的问题。
首先,git pull --rebase是一个很好的方案,这种方案的原理是不产生额外的合并节点,而是将远端更新拉取到本地,而后将本地的提交附加到远端更新之后。
这不是本文的主题,不再赘述。
还有另外一种方式:妙用git stash,其基本步骤和原理如下:
最后总结一下,使用git stash解决多余merge信息的核心操作:
1.git stash。
2.git pull。
3.git stash pop。
剩余的几个步骤,事实上就是我们重新提交的过程。
至于git stash的更深的原理,不属于本文的探究目标,不再赘述。
全文完。