大型旅行社自建网站,网站推广网络营销,云主机安装多个网站,海东高端网站建设公司目录 
引言 
Git命令行的远程Push 
EGit Push操作中的冲突问题 
同步 
工作区与本地库同步 
工作区与远程库同步 
图标 
重点 引言 
在团队开发当中#xff0c;Git Push是多人协作环节中的最重要的一环可能没有之一。同SVN一样#xff0c;push操作可以看做是对远端程序的提交…目录 
引言 
Git命令行的远程Push 
EGit Push操作中的冲突问题 
同步 
工作区与本地库同步 
工作区与远程库同步 
图标 
重点 引言 
在团队开发当中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我觉得先查看一下同步比对数据的情况然后对我们接下来的操作结果做到心中有数才是上策接下来就来讲解一下对比的操作。 
同步 
工作区与本地库同步 
选择TeamSynchronize 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 mastermaster就是当前的分支。而Svn可以直接在Synchronize视图中提交单个或多个文件这一点应该说svn要优于git。但是瑕不掩瑜Git强大的分支开发和版本管理体系是svn无法匹敌的。 
为了push我们的分支需要先回到基础Java视图中来右键项目TeamRemotePush...或者 右键项目TeamPush to Upstream前提是已经与远程库建立关联关系 push成功 
重点 
假设我又对程序进行了修改添加了一行输出语句“I wanna learn Vue.js very well!”并且已经提交到本地库中正准备push到远程仓库。 
我们如之前的建议正确的将工作区代码与远程仓库的代码进行比对 但是不幸的是有人已经对这个文件进行了修改并且冲突甚是嚣张如果我们不做任何感想直接push会有什么情况发生 我们心里很清楚push操作在冲突的情况下是不可能完成的不过貌似返回的错误信息还是很友好的。但请注意红框内的单词rejected 拒绝 而且还是过去时那啥也别说了远程库已经拒绝了我的push请求所以英语不好的小伙伴一定注意了这里的push失败对话框真的是不太鲜明有可能误以为push操作已经成功。这里千万要注意。 
我们可以检查一下远程的仓库来进一步验证我们的判断 果然没有push成功。 
那么这个时候我们应该做什么我们应该先pull然后解决冲突再进行push操作。 
右键项目TeamPull... 或者右键项目TeamPull 前提是已经有远程库关联 建议刚开始使用的小伙伴可以先使用“Pull...”进行拉取操作因为会弹出一个Pull对话框里面的信息对我们理解我们的操作会有不小的帮助后面熟练了可以使用“Pull”直接从默认的远程库中去拉取。 
执行完成后我们的冲突文件就变成了这个样子 可以看到Git会将HEAD和远程库的修改内容全部都写入冲突文件中并且使用  进行区分。 
我们手动进行修改即可修改结果如下 再次commit的时候Git会为我们自动生成一个Commit Message信息非常智能 提交完成后我们再次尝试Push操作弹出结果对话框如下 这回貌似没有rejected了进一步检查一下GitHub上的文件内容 和我们push的结果一样。 
综上就是冲突发生的时候我们的处理办法。但是这种开发者之间无沟通的冲突解决办法只是一种方案我们通过pull手动删减内容来完成冲突的解决。但是如果这个文件发生冲突的地方达到几十行甚至上百行的情况又该怎么办 
如果一个文件的冲突内容参差不齐且数量很多达到了几十行甚至上百行的级别那么我们应该与发生冲突的开发者进行线下沟通尝试以版本回退后共同merge的方式来解决冲突即先进行线下merge然后由其中一人进行push操作。 
总的来说解决冲突的办法还是比较多的如果讨厌删删改改的小伙伴可以同事之间协调沟通共同merge这样也可以相互学习交流经验。 综上就是push操作中常见的问题及解决办法。如有疑问欢迎文末留言。