新手入门我总是建议请老老实实从一个优秀的 GUI 开始。等你知道了 working directory / stash / stage / commit / merge / merge back / rebase 了以后，再要想比如说装个 B，再考虑纯 CLI 的情况。
比如 git pull 这样的命令只能处理最简单的拉取情况。如果你要拉取有冲突的 commit，情况会复杂得多，光一个 add 一个 commit 是远远不够的，需要首先根据场景看要做 rebase 还是 merge，然后根据具体操作去做 3-way conflict resolve 。

你现在的情况是 working directory 有更改，没进 stage 也没上 commit，更没 stash，于是产生了 local change conflict 。然后你做了 add 和 commit，这时候如果你有图形界面的话你可以看到状态是这样的。

origin/feature-init20200401 -> 7bb0b5eb --- 60 多个提交 ---> ae21cc9d
feature-init20200401 -> 7bb0b5eb -> c3c59ecc

然后你又做了 pull --merge，和一个 commit，变成了

feature-init20200401 -> 7bb0b5eb -> c3c59ecc -(merge ae21cc9d) -> 9e87e2c6

先不论结果怎么样，中途这条分支叉出来叉进来再叉回去，会让人无法看清每一个提交的用处和每一处修改的位置，万一提交后出了问题，也很难去单独隔离出某一段提交然后回滚。比如你这里，一处修改分了两次提交，一次在 merge point 之前，一次在之后，就很难去隔离测试。

比较好的做法是，先 stash，然后签出 ae21cc9d，然后 stash pop 并 resolve conflict，然后再做一个单独的「去 log 」提交。
另一种做法是，先 commit，然后做 pull rebase，在 rebase 过程中 resolve conflict，然后把 rebase 过的 commit 给 push 上去。
两种做法的结果是完全相同的。

如果你司没有针对 git 的学习过程的话，建议大家聚在一起好好学一下。瞎基尔用 git 是对 git 强大能力的一种浪费。正确使用 git 会大幅提高源代码管理效率的。

至于你说把同事代码删了是怎么回事，这个也只需要开个 GUI 工具，往上回溯一下看看每个提交的 diff 就知道怎么回事了。无非是 merge 的时候出了问题吧。