git pull和git commit的顺序问题

• 最近在合作开发项目的时候，遇到一个让人头痛的问题，我在本地clone远端仓库后，修改了部分代码，commit、push代码后，忘记了需要先pull，git revert后，再次pull代码，发现本地的修改被远端仓库覆盖掉了，欲哭无泪。
  查找了相关的git操作的文档博客等，总结如下：

1. 在本地修改与远程代码无冲突的情况下，优先使用：

pull -> commit -> push

2. 在本地修改与远程代码有冲突的情况下，优先使用：

commit -> pull -> push

保险起见还是先git add . git commit 再git pull比较好。

先 commit 再 pull 再 push 的情况就是为了应对多人合并开发的情况：

• commit 是为了告诉 git 我这次提交改了哪些东西，不然你只是改了但是 git 不知道你改了，也就无从判断比较；
• pull是为了本地 commit 和远程commit 的对比记录，git 是按照文件的行数操作进行对比的，如果同时操作了某文件的同一行那么就会产生冲突，git 也会把这个冲突给标记出来，这个时候就需要先搞清楚冲突的代码保留那个版本的，然后在 git add 、 git commit 、 git pull 三连，再次 pull 一次是为了防止在这期间另一个人给又提交了一版代码，通常没有冲突的时候就直接合并了，不会把你的代码给覆盖掉 ；
• 但是像我这样子，commit被撤销后，再次git pull，由于git pull = git fetch + git merge，会将远程仓库更新合并到本地，但是我又没有commit到本地仓库我修改过的代码，所以导致了悲剧。。。
• 让我先哭一会儿 > 3 <