目录
引言
在团队开发当中，Git Push是多人协作环节中的最重要的一环可能没有之一。同SVN一样，push操作可以看做是对远端程序的提交。
在多人协作中，push往往是最容易出现问题的一个环节，因为其他开发者有可能修改了你正准备提交的文件，并且已经先你一步提交到了远程仓库中。由此，才会引出后面一系列的pull、merge等操作。
由于在之前的博客《实现个人的Git远程代码版本控制————EGIT完成Eclipse到GitHub一条龙》中已经详细介绍了通过EGit Push新项目的操作，因此本篇博客主要介绍一下Git命令行的操作，以及在Push中可能会遇到的种种问题及解决办法。
Git命令行的远程Push
不论以哪种方式push到远程仓库，都需要先在远程建立一个可以与之关联的空的仓库。为了简化演示过程，我们采用GitHub作为远程仓库的创建服务器。
首先，我们已经在远程建立了一个空仓库：
复制仓库地址，执行git命令：
如上图所示，首先我们为本地仓库add（关联）一个远程仓库，并默认命名为origin，然后通过push命令推送到远程仓库，输入git push -help，可以查看一下push命令的参数，其中-u代表设置上游（远程库）
第一次通过-u参数push项目的同时设置好远程库之后，后面就可以直接git push origin master了。
EGit Push操作中的冲突问题
正如引言中所述的情况，我们将分支push到远程仓库的时候恰巧远程仓库中已经有了改动而与我们正准备提交的代码有冲突。这种情况在过去的开发中屡见不鲜，在svn中也存在同样的问题，常常是一个工具类，大家都添加了自己的工具方法，如果不希望merge混乱，就需要有一个专门的merge人员，每天定点去服务器上对大家的修改进行merge操作。虽然近些年微服务的口号喊得响彻，但是对于不适合微服务的项目，就仍然存在多人同时修改了共有文件的情况发生。虽然我们不希望这样的情况发生，也会尽量避免这种情况的发生，但仍然要学习如何使用Git去处理冲突的情况。
最有用的建议是：
push之前请先同步对比！
EGit的全部功能都封装自git命令，应该说git命令包含了全部的EGit插件操作。但是对于某些比对性的操作，命令行的体验往往是差强人意的，尤其是在项目文件繁多的情况下，几十个文件进行比对，绝对会让你看的眼花缭乱。
假设此时，我们已经对自己修改的代码充满了信心，并且提交到了本地仓库，正准备push到远程库上去，这个时候我们应该怎么做？是直接push还是先pull？我觉得先查看一下同步比对数据的情况，然后对我们接下来的操作结果做到心中有数才是上策！接下来就来讲解一下对比的操作。
同步
工作区与本地库同步
选择Team>Synchronize Workspace
“Synchronize Workspace”翻译过来是“同步工作区”，这听起来有些“吓人”，但是实际上，它仅仅是将本地库与工作区内容进行比对。
工作区与远程库同步
同步之前，需要先将 Remote Tracking 的远程库进行Fetch...操作。
Fetch步骤如下：
切换到Git Repository视图，右键项目名 > Remote > Fetch...
Fetch 完成！
这样我们就可以任意选择远程分支与本地工作区进行比对：
注意这里EGit为了区分工作区与本地库的比对和工作区与远程库的比对，特意加了一个with，因此这里的“Synchronize with Workspace”代表的是工作区与远程库的一个分支进行比对。
比对图标
这里的一些图标信息和svn的用法是类似的，灰色箭头代表本地有修改，蓝色箭头代表远程有修改，红色双箭头代表此文件有冲突。
在EGit官网上也给出了具体图标的解释：
（但愿各位的英语和我一样好 罒ω罒 ！）
从上图可以看出，我们的项目仅仅是有一个本地的修改，因此可以确定的是push之后不会出现任何冲突问题，可以放心大胆的push。也不需要每次push之前都无脑的pull。
这里注意一下，Git的Push操作无法在Synchronize视图中进行，因为Git的push操作都是针对于分支而言的，也就是说，我们实际上只能push当前的分支，而非文件，就算是只有一个文件的修改，也必须是push分支，也就是命令行中看到的git push origin master，master就是当前的分支。而Svn可以直接在Synchronize视图中提交单个或多个文件，这一点应该说svn要优于git。但是瑕不掩瑜，Git强大的分支开发和版本管理体系是svn无法匹敌的。
为了push我们的分支，需要先回到基础Java视图中来，右键项目>Team>Remote>Push...或者 ：右键项目>Team>Push to Upstream（前提是已经与远程库建立关联关系）
push成功！
重点
假设，我又对程序进行了修改（添加了一行输出语句“I wanna learn Vue.js very well!”），并且已经提交到本地库中，正准备push到远程仓库。
我们如之前的建议，正确的将工作区代码与远程仓库的代码进行比对：
但是不幸的是，有人已经对这个文件进行了修改，并且冲突甚是嚣张！如果我们不做任何感想，直接push会有什么情况发生？
我们心里很清楚，push操作在冲突的情况下是不可能完成的，不过貌似返回的错误信息还是很友好的。但请注意红框内的单词：rejected ，拒绝 ，而且还是过去时，那啥也别说了，远程库已经拒绝了我的push请求！所以英语不好的小伙伴一定注意了，这里的push失败对话框真的是不太鲜明，有可能误以为push操作已经成功。这里千万要注意。
我们可以检查一下远程的仓库，来进一步验证我们的判断：
果然没有push成功。
那么这个时候我们应该做什么？我们应该先pull，然后解决冲突再进行push操作。
右键项目>Team>Pull... 或者：右键项目>Team>Pull （前提是已经有远程库关联）
建议刚开始使用的小伙伴可以先使用“Pull...”进行拉取操作，因为会弹出一个Pull对话框，里面的信息对我们理解我们的操作会有不小的帮助，后面熟练了可以使用“Pull”直接从默认的远程库中去拉取。
执行完成后，我们的冲突文件就变成了这个样子：
可以看到，Git会将HEAD和远程库的修改内容全部都写入冲突文件中，并且使用<<<<<<< ======= >>>>>>>进行区分。
我们手动进行修改即可，修改结果如下：
再次commit的时候，Git会为我们自动生成一个Commit Message信息，非常智能：
提交完成后，我们再次尝试Push操作，弹出结果对话框如下：
这回貌似没有rejected了，进一步检查一下GitHub上的文件内容：
和我们push的结果一样。
综上，就是冲突发生的时候我们的处理办法。但是这种开发者之间无沟通的冲突解决办法只是一种方案，我们通过pull，手动删减内容，来完成冲突的解决。但是如果这个文件发生冲突的地方达到几十行甚至上百行的情况又该怎么办？
如果一个文件的冲突内容参差不齐，且数量很多，达到了几十行甚至上百行的级别，那么我们应该与发生冲突的开发者进行线下沟通，尝试以版本回退后共同merge的方式来解决冲突，即先进行线下merge，然后由其中一人进行push操作。
总的来说，解决冲突的办法还是比较多的，如果讨厌删删改改的小伙伴，可以同事之间协调沟通，共同merge，这样也可以相互学习，交流经验。
综上，就是push操作中常见的问题及解决办法。如有疑问欢迎文末留言。