在eoe上看到的一篇教程,厚脸先贴上来;
看到大家在讨论github的使用,我用的也不多,偶尔clone一些好的源代码而已。我用的是Eclipse的插件EGit,全部操作直接在eclispe里就可以完成了,哈哈,我比较懒,官网上教的那些git clone 什么的高深操作我也不会,感觉egit还是比较好用的,所以上网搜了一个关于egit的详细操作的帖子,现在搬过来和大家一起分享一下。我找到的这个帖子的地址是:http://blog.csdn.net/luckarecs/article/details/7427605。虽然这篇帖子也写的是转载,我没找到最原始的出处,(PS:有人反馈说原始出处是这:http://blog.csdn.net/laizhenhai88/article/details/7234974,我不敢确定,不过还是把这个链接放上来吧,谢谢@ter 的反馈),不过如果大家转载的话,还是要把这个链接加上,这也算是保护知识产权了吧,哈哈,好了,费话不多说了,以下是详细内容:
http://download.eclipse.org/egit/updates/
或者使用Eclipse Marketplace,搜索EGit
配置个人信息,最重要的是user.name和user.email
l Preferences > Team > Git > Configuration
l New Entry
新建NC module project
l File > Team > Share Project 选择GIT
创建仓库后,在$workspace\demo目录下的.git文件夹,就是git的仓库地址。和CVS、SVN不同,GIT不会在每一个目录下建立版本控制文件夹,仅在根目录下建立仓库
同时,eclipse中的project也建立git版本控制,此时未创建分支,处于NO-HEAD状态
文件夹中的符号”?”表示此文件夹处于untracked状态,这样就成功创建GIT仓库。
四_配置.gitignore此时我们尝试做一次提交
l Team -> Commit…
如上图所示,Author和Committer会默认为Git配置的用户信息。下面的Files窗口中可以看到此次提交的文件,其中有非常多带有NC_HOME的文件,此时可以猜测出,在我们的project中链接的NC_HOME也被GIT默认到版本控制中了,如下图:
显然NC_HOME和out是不需要进行版本控制的,我们可以通过配置.gitignore来排除这两个文件夹
打开Navigator窗口,在project根目录中添加.gitignore文件,将需要排除控制的目录写入.gitignore文件中
再次尝试commit,需要提交的文件已经被过滤
首次提交后,会自动生成master分支
然后在public中新建一个文件,可以看到图标依然是问号,处于untracked状态,即git没有对此文件进行监控
通过Team -> Add to index可以将文件加入git索引,进行版本监控
可以看到图标显示也有了变化(EGIT中只要Commit就可以默认将untracked的文件添加到索引再提交更新,不需要分开操作)
也可以通过Team -> Untrack将文件从索引控制中排除。
将此次新增的文件commit到仓库中,文件将处于unmodified状态,或者说,这就是一种staged状态
然后修改文件的内容,文件将处于modified状态
可以选择对比模式
首先通过shell工具连接到服务器,建立空仓库gitdemo,此时的ssh访问地址如下,分别由协议名称、用户名、IP、端口、git仓库目录组成。
ssh://root@192.168.1.101:22/app/gitspace/gitdemo
打开GIT资源库窗口,选择克隆资源库
现在已经把远程的GIT仓库克隆到本地,接下来需要将仓库检出为NC模块项目。
最后得到gitdemo模块项目,分支是mirror
克隆服务器端仓库后,会在本地建立一个一样的仓库,称本地仓库。在本地进行commit操作将把更新提交到本地仓库,然后可以将服务器端的更新pull到本地仓库进行合并,最后将合并好的本地仓库push到服务器端,这样就进行了一次远程提交。
先提交一次到本地仓库
然后push到服务器端的mirror分支,Team -> remote -> Push
完成推送后,可以在服务器端mirror镜像的log中查看到此次记录
多人协作开发的情况下,往服务器推送更新时难免出现冲突,所以推送之前需要解决服务器端的最新版本和本地仓库的冲突。Pull操作就是把服务器端的更新拉拢到本地仓库进行合并,解决好合并冲突后,就可以顺利push到服务器分支了。
假设现在Mairo兄弟在用GIT协作开发NewSuperMairoBro游戏,目前服务器端的mushroom.java文件的内容如下:
MairoBro克隆出代码后,Mairo哥哥做了如下修改
Mairo弟弟做了如下修改
然后Mairo弟弟先push代码,Mairo哥哥使用pull来合并本地仓库和远程仓库,将发行文件出现冲突,此时GIT会自动合并冲突的文件,如下图所示:
很明显自动合并的冲突文件不能直接使用,我们可以手动调整,右键发生冲突的文件,选择Team -> Merge Tool
第一项是将GIT自动合并过的文件和服务器端文件进行对比
第二项是用本地最新版本的文件和服务器端文件进行对比,建议用此项
接下来就是熟悉的对比界面
Mairo哥哥将冲突文件修改如下
然后右键点击此冲突文件,选择Team -> Add to index再次将文件加入索引控制,此时文件已经不是冲突状态,并且可以进行提交并push到服务器端
解决合并冲突后,Mairo弟弟只需要将服务器中合并后的版本pull到本地,就完成了一次协作开发的代码合并。从历史记录中可以看到,从mushroom开始历史进入分支,先是mushroomA的记录,然后是mushroomB的记录,最后历史分支合并。
Rebase和Merge操作最终的结果是一样的,但是实现原理不一样。
从上面的MairoBro例子可以知道pull大概对历史记录进行了怎样的合并操作,其实默认pull的操作就是一个分支的merge操作,如下图重现一下:
Mairo弟弟的提交记录如下:
Mairo哥哥的提交记录如下:
首先是Mairo弟弟把更新push到服务器,这样服务器端的记录就和Mairo弟弟本地的记录是一样的,接着Mairo哥哥执行pull操作,现在分析下pull是如何操作的。
l pull默认就是先把服务器端的最新记录更新到本地的Remote Tracking中对应的mirror分支
l 接着对Local的mirror分支和Remote Tracking的mirror分支进行merge操作
Merge操作后的结果就是会新增加一个merge记录节点,如下所示:
从上图可以看出,mushroomA是在mushroomB之前的,这个时间关系不取决于谁先执行push,而取决于本地仓库中谁先执行commit。所以merge会按照时间顺序严格的记录每一次commit。
接下来看看rebase,其实rebase也是把两个分支进行合并的操作,当Mairo弟弟push更新后,服务器端的mirror分支的历史如下:
Mairo哥哥本地的历史如下:
现在Mairo哥哥不是执行merge操作,而是执行rebase操作,最后结果如下:
很明显的区别是没有出现分支的记录,而且注意到mushroomA*,请注意这个记录和mushroomA不是同一个记录,我们先分析下rebase操作下,Mairo哥哥的历史记录都做了哪些变化:
l 先将当前分支的更新部分保存到临时区域,而当前分支重置到上一次pull的记录
l 然后将服务器端的更新添加到当前分支,此时当前分支和服务器端分支是一样的
l 最后将原分支的更新部分mushroomA提交到当前分支的后面,就是要在mushroomB的后面添加mushroomA的更新,当然此时更新记录已经不是之前的mushroomA了,如果出现冲突则使用对比工具解决冲突,最后记录变成mushroomA*。
如果Mairo哥哥提交过mushroomA1、mushroomA2、mushroomA3,那么执行rebase后会对mushroomA1、mushroomA2、mushroomA3分别顺序执行上图所示的合并,最后记录为mushroomA1*、mushroomA2*、mushroomA3*。很显然rebase操作更复杂,冲突的概率也更高,并且不是按照时间顺序记录。
此小结为什么说是简单解析呢,因为rebase和merge的选择问题讨论比较激烈,笔者也没有一个定论,而且git也处于研究发展阶段,很多理论还没有完全的纯熟。
对于一个多人开发团队频繁提交更新的情况,如果使用merge会使得历史线图非常复杂,并且merge一次就会新增一个记录点,如果使用rebase就是完全的线性开发。
上图所示是Merge和Rebase的两个结果,显然你不想要merge的混乱结果吧,你能告诉我merge图中那条线是master分支吗?
所以给出如下建议,如果同一文件反复修改或提交次数比较多,预期会出现很多的conflict,那么可以使用merge合并,仅需要解决一次冲突即可(不过,大范围主题式的修改,是不是应该事先就新开一个分支呢?);如果修改范围小,预期conflict少,则建议使用rebase。
EGIT中默认的pull操作是Fetch+Merge,如果要用rebase,可以分开操作。先执行Fetch更新remote tracking,再执行rebase进行合并(下一小节将介绍rebase操作)。或者修改pull的默认操作,在.git/config文件中配置:
上述配置只对mirror分支有效,也可做全局配置,在$HOME/.gitconfig中配置,windows系统如果没有配置HOME变量的话就默认在$documents and settings/ USER目录下:
MairoBro来做fetch和rebase的测试,首先Mairo弟弟在client中添加文件OPQ分别提交,并push到服务器,如图:
此时服务器端的历史已经被更新,但是Mairo哥哥的remote tracking中mirror分支并没有更新到最新的记录,如图:
所以需要更新remote tracking中的分支,使得它与服务器端的分支同步,右键点击资源库选择Fetch
这样就更新了本地的remote tracking中的分支,使得它和服务器端分支同步。
然后Mairo哥哥在本地的private中添加文件ABC,并分别提交到本地仓库中。
然后将本地mirror分支和remote tracking中的mirror分支进行rebase,先checkout本地mirror分支 ,然后右键点击选择Rebase
如上图可以看到历史记录的顺序是OPQABC,已经rebase成功,接着push到服务器即可。
GIT中有三种重置功能,分别是soft、mixed、hard,区别如下:
l Soft - 当前分支重置到指定commit记录位置,索引和工作树不变;
l Mixed - 当前分支重置到指定commit记录位置,索引被更新,工作树不变;
l Hard - 当前分支重置到指定commit记录位置,索引和工作树都更新。
貌似不好理解,首先要理解GIT的三个区域(工作树、索引区、仓库),可以参考文档《GIT简介》。
先做soft的测试,新建Soft.java文件,可以看到此文件未添加到索引控制
先进行一次提交,提交后在History窗口中重置此次提交,如图:
重置后查看工作树,如图
从上图可以看出,soft文件还存在,说明重置没有改变工作树,而且soft文件不是“问号”图标,说明已经添加到索引,说明索引也没有变。唯一重置的是历史记录。
然后新建Mixed.java文件,此时Mixed.java也没有添加到索引控制,然后提交。
在History窗口中重置
重置后查看工作树结果如下:
从上图可以看出,Mixed.java文件还存在,说明工作树没有改变,但是文件状态是untracked,说明索引被更新,此时文件没有添加索引控制。
最后来看hard重置,新建Hard.java文件,此时文件没有添加索引,然后提交。
在History界面重置此次提交,如图:
重置后再查看工作树,结果如下:
可以看到Hard.java文件已经不存在了,说明索引和工作树都被更新。
接着点next就行了,往后的操作就和文章中介绍的一样了
上面讲的东西很全,需要慢慢消化,但上手的话很简单,可以看这个
首先,需要注册一个账号。https://github.com/
注册完成后,登录。
在主界面的右下角有这样一个区域,如图。点击 New repository,创建一个新的库。
在 Repository name 栏里写上新建库的名字,如“HelloWorld”。其它可写可不写。等你熟悉了再去深究吧。点击下方的 Create repository 按钮。
OK,网页部分完成了。看看本地需要哪些设置吧!
1、安装Eclipse插件
回到主页面,在页面的下方,会有这样一个区域,如图。点击 Clients 下的 GitHub for Eclipse 。(你也可以看到,有“GitHub for Windows”,那是Windows的桌面程序,和SVN的桌面程序差不多,也很好用的。感兴趣的可以看一下。上传一些文件还是很方便的。如果不是用Eclipse作为开发工具的话,这个就挺好用。)
在下载页面(http://eclipse.org/egit/download/),选择中间部分的这个链接,如图。其他的那些URL是给Eclipse的在线安装使用的。Eclipse在线安装插件的方式不太好用。建议将插件下载下来,手动安装。
将下载的插件解压后,复制到${MyEclipse}/MyEclipse 10/dropins目录下。(注:Eclipse不同的版本,目录可能不一样,安装插件的方式也可能不一样。)
重启MyEclipse。点击 工具栏 > Preferences > Team 下多了一个 Git 的分支。
修改一下“Default repository folder”的值。这是远程的库在本地的一个路径。笔者选择的是MyEclipse的工作目录。
接下来新建一个HelloWorld的项目吧。这个就不多说了。
项目建好后,选中项目, 右键 > Team > Share Project 。你会看到这样的提示,如图:
提示缺少环境变量 HOME 。少了咱就加呗!
右击 我的电脑 > 属性,点击选项卡 高级 > 环境变量 > 系统变量 > 新建 ,如图。在 变量名 中输入 HOME , 变量值 建议和上面的“Default repositoryfolder”一样。点击 确定 。
重启Eclipse。
重复上一步操作—— ShareProject ,这次应该不会再出现上次的提示。在出现的界面中选中 Git ,点击 Next 。在如下的界面中,在红色标注的地方打 √ ,选中项目后,点击 CreateRepository ,点击 Finish 。
选中项目,右键 > Team > Commit ,出现如下图的界面。输入提交的备注信息(Commit message),选中要提交的文件,点击 Commit 。
(注:如果你只是要上传文件,那个“.project”的文件可以不提交,那是Eclipse的一个配置文件,主要作用就是表明这个文件是一个Project。当你用另一台机器下载这些代码时,如果有这个文件,可以用Eclipse直接导入,Import Project)
如何提交到GitHub账户下呢?
选中项目,右键 > Team > Remote > Push ,出现如下界面。
回到GitHub的主页面,点击新建的库“HelloWorld”,在浏览器的右侧出现如下片段,如图。在 Code 栏的最下方提供了不同的下载方式。笔者选择 HTTPS ,复制后面的地址,粘贴到上图中的“URI”栏里。
User/Password就是你的GitHub的账户和密码。“Storein Secure Store”打 √ 。点击 Next ,出现下图界面。
a、 选择 Source ref
b、 点击 Add AllBranches Spec
c、 Force Update 一定要选中。如果不选中,下一步就会报错。这个错在GitHub的Help里可以搜索到,但我没怎么看懂。只知道选中“Force Update”可以避免这个错误。
d、 点击 Finish
OK,到你的GitHub的主页面看一下,HelloWorld库里是不是多了些文件?
再看一下如何同步吧!
在原先的代码上加上如下2行。
和上传整个项目时相似,简单说下步骤,不再赘述。
(1)Commit
(2)Push
在GitHub的主页面,在HelloWorld库里面找到“HelloWorld4GitHub.java”文件,看一下新加入的代码是不是已经更新到库里面了。
在页面上点击 Edit 按钮,加入如下代码
(1)在下方的 Commitmessage 栏里输入你的备注信息,如“Add from Web”
(2)点击 CommitChanges 按钮
页面上修改完成。
如何更新到本地呢?
选中项目,右键 > Team > Pull ,你会发现代码已经更新下来了。
最近在鼓捣github, pull git内容到本地, 发现这样的异常
2.解决步骤
window-->preferences--->Team--->git--->configuration
--->repository settings
打开这个项目的 git 配置文件, 里面增加 点git 配置内容
自己修改下 自己项目的remote.origin.url 路径地址