何谓多余的merge信息
所谓多余的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信息有什么不好
你可能会有一个疑问，这仅仅是多一条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必然出现这种提示吗
git pull并非是必然出现这种情况，出现这种情况的条件是：
本地有领先远端的commit，同时远端也有领先本地的commit。
假设本地并没有commit，那么git pull并不会产生额外的merge信息，因为本地和远端没有分叉（可以通俗理解成分歧），无需产生额外的合并节点。
假设远端没有额外的commit，自然获取不到远端的更新，也不会产生合并的问题。
有哪些解决方案
首先，git pull --rebase是一个很好的方案，这种方案的原理是不产生额外的合并节点，而是将远端更新拉取到本地，而后将本地的提交附加到远端更新之后。
这不是本文的主题，不再赘述。
还有另外一种方式：妙用git stash，其基本步骤和原理如下：
- git stash。这条命令会使本地的修改暂存，就像是本地的修改消失了一样，可以理解成将本地的修改“藏起来”。
- git pull 。这条命令使本地获取到远端更新，由于本地相对于远端没有新的commit，不会产生额外的merge信息。
- git stash pop。这条命令使本地的修改还原，可以理解成将本地藏起来的修改重新“揪出来”。
- git add .。这条命令表明重新将修改添加到暂存区。
- git commit -m [message]。重新将暂存区的修改提交到本地仓库。
- git push 。推送到远端。
最后总结一下，使用git stash解决多余merge信息的核心操作：
1.git stash。
2.git pull。
3.git stash pop。
剩余的几个步骤，事实上就是我们重新提交的过程。
至于git stash的更深的原理，不属于本文的探究目标，不再赘述。
全文完。