Eclipse上GIT插件EGIT使用手册

2021年09月15日 阅读数:1
这篇文章主要向大家介绍Eclipse上GIT插件EGIT使用手册,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

一_安装EGIT插件

 

Eclipse上GIT插件EGIT使用手册_git

Eclipse上GIT插件EGIT使用手册_服务器_02

 

http://download.eclipse.org/egit/updates/java

或者使用Eclipse Marketplace,搜索EGitgit

Eclipse上GIT插件EGIT使用手册_git_03

Eclipse上GIT插件EGIT使用手册_git仓库_04

 

 

二_使用EGIT前的配置

 

 

 

配置我的信息,最重要的是user.name和user.emailshell

l  Preferences > Team > Git > Configurationwindows

l  New Entry服务器

Eclipse上GIT插件EGIT使用手册_git仓库_05

Eclipse上GIT插件EGIT使用手册_git_06

 

 

三_新建GIT仓库

 

 

新建NC module projectapp

Eclipse上GIT插件EGIT使用手册_服务器端_07

l  File > Team > Share Project 选择GITeclipse

Eclipse上GIT插件EGIT使用手册_git_08

Eclipse上GIT插件EGIT使用手册_git仓库_09

建立仓库后,在$workspace\demo目录下的.git文件夹,就是git的仓库地址。和CVS、SVN不一样,GIT不会在每个目录下创建版本控制文件夹,仅在根目录下创建仓库ssh

Eclipse上GIT插件EGIT使用手册_重置_10

同时,eclipse中的project也创建git版本控制,此时未建立分支,处于NO-HEAD状态ide

Eclipse上GIT插件EGIT使用手册_git仓库_11

文件夹中的符号”?”表示此文件夹处于untracked状态,这样就成功建立GIT仓库。工具

四_配置.gitignore

 

 

此时咱们尝试作一次提交

l  Team -> Commit…

Eclipse上GIT插件EGIT使用手册_服务器_12

如上图所示,Author和Committer会默认为Git配置的用户信息。下面的Files窗口中能够看到这次提交的文件,其中有很是多带有NC_HOME的文件,此时能够猜想出,在咱们的project中连接的NC_HOME也被GIT默认到版本控制中了,以下图:

Eclipse上GIT插件EGIT使用手册_git_13

显然NC_HOME和out是不须要进行版本控制的,咱们能够经过配置.gitignore来排除这两个文件夹

打开Navigator窗口,在project根目录中添加.gitignore文件,将须要排除控制的目录写入.gitignore文件中

Eclipse上GIT插件EGIT使用手册_服务器端_14

再次尝试commit,须要提交的文件已经被过滤

Eclipse上GIT插件EGIT使用手册_git仓库_15

首次提交后,会自动生成master分支

Eclipse上GIT插件EGIT使用手册_重置_16

而后在public中新建一个文件,能够看到图标依然是问号,处于untracked状态,即git没有对此文件进行监控

Eclipse上GIT插件EGIT使用手册_git仓库_17

经过Team -> Add to index能够将文件加入git索引,进行版本监控

Eclipse上GIT插件EGIT使用手册_重置_18

能够看到图标显示也有了变化(EGIT中只要Commit就能够默认将untracked的文件添加到索引再提交更新,不须要分开操做)

Eclipse上GIT插件EGIT使用手册_重置_19

也能够经过Team -> Untrack将文件从索引控制中排除。

将这次新增的文件commit到仓库中,文件将处于unmodified状态,或者说,这就是一种staged状态

Eclipse上GIT插件EGIT使用手册_服务器端_20

而后修改文件的内容,文件将处于modified状态

Eclipse上GIT插件EGIT使用手册_重置_21

 

 

 

五_查看历史记录

Team -> Show in history能够查看版本历史提交记录

 

Eclipse上GIT插件EGIT使用手册_git_22

 

Eclipse上GIT插件EGIT使用手册_git仓库_23

能够选择对比模式

Eclipse上GIT插件EGIT使用手册_重置_24

 

Eclipse上GIT插件EGIT使用手册_重置_25

 

 

 

六_远程GIT仓库

此小结的前提是已经搭建GIT服务器,并经过SSH协议链接,可参看文档《RHEL下搭建GIT服务器》《WindowsXP下搭建GIT服务器》《GIT服务器使用基础》。本文使用RHEL5.5系统下的GIT-2012-01-11,用户root/password,GIT仓库统一存放在/app/gitspace目录下。

 

首先经过shell工具链接到服务器,创建空仓库gitdemo,此时的ssh访问地址以下,分别由协议名称、用户名、IP、端口、git仓库目录组成。

ssh://root@192.168.1.101:22/app/gitspace/gitdemo

打开GIT资源库窗口,选择克隆资源库

Eclipse上GIT插件EGIT使用手册_git仓库_26

Eclipse上GIT插件EGIT使用手册_重置_27

Eclipse上GIT插件EGIT使用手册_服务器端_28

Eclipse上GIT插件EGIT使用手册_服务器_29

Eclipse上GIT插件EGIT使用手册_服务器端_30

如今已经把远程的GIT仓库克隆到本地,接下来须要将仓库检出为NC模块项目。

Eclipse上GIT插件EGIT使用手册_git_31

Eclipse上GIT插件EGIT使用手册_git_32

最后获得gitdemo模块项目,分支是mirror

Eclipse上GIT插件EGIT使用手册_服务器_33

 

 

七_推送远程仓库

 

 

克隆服务器端仓库后,会在本地创建一个同样的仓库,称本地仓库。在本地进行commit操做将把更新提交到本地仓库,而后能够将服务器端的更新pull到本地仓库进行合并,最后将合并好的本地仓库push到服务器端,这样就进行了一次远程提交。

Eclipse上GIT插件EGIT使用手册_服务器_34

先提交一次到本地仓库

Eclipse上GIT插件EGIT使用手册_重置_35

而后push到服务器端的mirror分支,Team -> remote -> Push

Eclipse上GIT插件EGIT使用手册_git仓库_36

完成推送后,能够在服务器端mirror镜像的log中查看到这次记录

Eclipse上GIT插件EGIT使用手册_服务器_37

 

 

 

八_解决推送冲突

 

 

多人协做开发的状况下,往服务器推送更新时不免出现冲突,因此推送以前须要解决服务器端的最新版本和本地仓库的冲突。Pull操做就是把服务器端的更新拉拢到本地仓库进行合并,解决好合并冲突后,就能够顺利push到服务器分支了。

假设如今Mairo兄弟在用GIT协做开发NewSuperMairoBro游戏,目前服务器端的mushroom.java文件的内容以下:

Eclipse上GIT插件EGIT使用手册_服务器_38

MairoBro克隆出代码后,Mairo哥哥作了以下修改

Eclipse上GIT插件EGIT使用手册_重置_39

Mairo弟弟作了以下修改

Eclipse上GIT插件EGIT使用手册_服务器_40

而后Mairo弟弟先push代码,Mairo哥哥使用pull来合并本地仓库和远程仓库,将发行文件出现冲突,此时GIT会自动合并冲突的文件,以下图所示:

Eclipse上GIT插件EGIT使用手册_服务器端_41

Eclipse上GIT插件EGIT使用手册_服务器端_42

Eclipse上GIT插件EGIT使用手册_git_43

很明显自动合并的冲突文件不能直接使用,咱们能够手动调整,右键发生冲突的文件,选择Team -> Merge Tool

Eclipse上GIT插件EGIT使用手册_重置_44

第一项是将GIT自动合并过的文件和服务器端文件进行对比

第二项是用本地最新版本的文件和服务器端文件进行对比,建议用此项

接下来就是熟悉的对比界面

Eclipse上GIT插件EGIT使用手册_服务器端_45

Mairo哥哥将冲突文件修改以下

Eclipse上GIT插件EGIT使用手册_服务器端_46

而后右键点击此冲突文件,选择Team -> Add to index再次将文件加入索引控制,此时文件已经不是冲突状态,而且能够进行提交并push到服务器端

Eclipse上GIT插件EGIT使用手册_git_47

解决合并冲突后,Mairo弟弟只须要将服务器中合并后的版本pull到本地,就完成了一次协做开发的代码合并。从历史记录中能够看到,从mushroom开始历史进入分支,先是mushroomA的记录,而后是mushroomB的记录,最后历史分支合并。

Eclipse上GIT插件EGIT使用手册_重置_48

 

 

 

九_Rebase和Merge的区别

 

Rebase和Merge操做最终的结果是同样的,可是实现原理不同。

从上面的MairoBro例子能够知道pull大概对历史记录进行了怎样的合并操做,其实默认pull的操做就是一个分支的merge操做,以下图重现一下:

Mairo弟弟的提交记录以下:

Eclipse上GIT插件EGIT使用手册_服务器端_49

Mairo哥哥的提交记录以下:

Eclipse上GIT插件EGIT使用手册_git仓库_50

首先是Mairo弟弟把更新push到服务器,这样服务器端的记录就和Mairo弟弟本地的记录是同样的,接着Mairo哥哥执行pull操做,如今分析下pull是如何操做的。

l  pull默认就是先把服务器端的最新记录更新到本地的Remote Tracking中对应的mirror分支

l  接着对Local的mirror分支和Remote Tracking的mirror分支进行merge操做

Eclipse上GIT插件EGIT使用手册_服务器_51

Merge操做后的结果就是会新增长一个merge记录节点,以下所示:

Eclipse上GIT插件EGIT使用手册_git_52

从上图能够看出,mushroomA是在mushroomB以前的,这个时间关系不取决于谁先执行push,而取决于本地仓库中谁先执行commit。因此merge会按照时间顺序严格的记录每一次commit。

接下来看看rebase,其实rebase也是把两个分支进行合并的操做,当Mairo弟弟push更新后,服务器端的mirror分支的历史以下:

Eclipse上GIT插件EGIT使用手册_服务器端_49

Mairo哥哥本地的历史以下:

Eclipse上GIT插件EGIT使用手册_git仓库_50

如今Mairo哥哥不是执行merge操做,而是执行rebase操做,最后结果以下:

Eclipse上GIT插件EGIT使用手册_git_55

很明显的区别是没有出现分支的记录,并且注意到mushroomA*,请注意这个记录和mushroomA不是同一个记录,咱们先分析下rebase操做下,Mairo哥哥的历史记录都作了哪些变化:

l  先将当前分支的更新部分保存到临时区域,而当前分支重置到上一次pull的记录

Eclipse上GIT插件EGIT使用手册_服务器_56

l  而后将服务器端的更新添加到当前分支,此时当前分支和服务器端分支是同样的

Eclipse上GIT插件EGIT使用手册_git_57

l  最后将原分支的更新部分mushroomA提交到当前分支的后面,就是要在mushroomB的后面添加mushroomA的更新,固然此时更新记录已经不是以前的mushroomA了,若是出现冲突则使用对比工具解决冲突,最后记录变成mushroomA*。

Eclipse上GIT插件EGIT使用手册_git_55

若是Mairo哥哥提交过mushroomA一、mushroomA二、mushroomA3,那么执行rebase后会对mushroomA一、mushroomA二、mushroomA3分别顺序执行上图所示的合并,最后记录为mushroomA1*、mushroomA2*、mushroomA3*。很显然rebase操做更复杂,冲突的几率也更高,而且不是按照时间顺序记录。

 

 

 

十_Rebase和Merge如何选择的简单解析

 

 

此小结为何说是简单解析呢,由于rebase和merge的选择问题讨论比较激烈,笔者也没有一个定论,并且git也处于研究发展阶段,不少理论尚未彻底的纯熟。

对于一个多人开发团队频繁提交更新的状况,若是使用merge会使得历史线图很是复杂,而且merge一次就会新增一个记录点,若是使用rebase就是彻底的线性开发。

Eclipse上GIT插件EGIT使用手册_服务器_59

上图所示是Merge和Rebase的两个结果,显然你不想要merge的混乱结果吧,你能告诉我merge图中那条线是master分支吗?

因此给出以下建议,若是同一文件反复修改或提交次数比较多,预期会出现不少的conflict,那么可使用merge合并,仅须要解决一次冲突便可(不过,大范围主题式的修改,是否是应该事先就新开一个分支呢?);若是修改范围小,预期conflict少,则建议使用rebase。

EGIT中默认的pull操做是Fetch+Merge,若是要用rebase,能够分开操做。先执行Fetch更新remote tracking,再执行rebase进行合并(下一小节将介绍rebase操做)。或者修改pull的默认操做,在.git/config文件中配置:

Eclipse上GIT插件EGIT使用手册_git仓库_60

上述配置只对mirror分支有效,也可作全局配置,在$HOME/.gitconfig中配置,windows系统若是没有配置HOME变量的话就默认在$documents and settings/ USER目录下:

Eclipse上GIT插件EGIT使用手册_git仓库_61

 

 

 

十一_Fetch和Rebase

 

 

MairoBro来作fetch和rebase的测试,首先Mairo弟弟在client中添加文件OPQ分别提交,并push到服务器,如图:

Eclipse上GIT插件EGIT使用手册_git_62Eclipse上GIT插件EGIT使用手册_服务器_63

此时服务器端的历史已经被更新,可是Mairo哥哥的remote tracking中mirror分支并无更新到最新的记录,如图:

Eclipse上GIT插件EGIT使用手册_重置_64

因此须要更新remote tracking中的分支,使得它与服务器端的分支同步,右键点击资源库选择Fetch

Eclipse上GIT插件EGIT使用手册_git仓库_65

Eclipse上GIT插件EGIT使用手册_服务器端_66

这样就更新了本地的remote tracking中的分支,使得它和服务器端分支同步。

Eclipse上GIT插件EGIT使用手册_服务器端_67

而后Mairo哥哥在本地的private中添加文件ABC,并分别提交到本地仓库中。

Eclipse上GIT插件EGIT使用手册_git_68Eclipse上GIT插件EGIT使用手册_服务器_69

而后将本地mirror分支和remote tracking中的mirror分支进行rebase,先checkout本地mirror分支 ,而后右键点击选择Rebase

Eclipse上GIT插件EGIT使用手册_git仓库_70

Eclipse上GIT插件EGIT使用手册_服务器_71

Eclipse上GIT插件EGIT使用手册_重置_72

Eclipse上GIT插件EGIT使用手册_重置_73

如上图能够看到历史记录的顺序是OPQABC,已经rebase成功,接着push到服务器便可。

 

十二_重置功能

 

 

 

GIT中有三种重置功能,分别是soft、mixed、hard,区别以下:

l  Soft - 当前分支重置到指定commit记录位置,索引和工做树不变;

l  Mixed - 当前分支重置到指定commit记录位置,索引被更新,工做树不变;

l  Hard - 当前分支重置到指定commit记录位置,索引和工做树都更新。

貌似很差理解,首先要理解GIT的三个区域(工做树、索引区、仓库),能够参考文档《GIT简介》。

先作soft的测试,新建Soft.java文件,能够看到此文件未添加到索引控制

Eclipse上GIT插件EGIT使用手册_git仓库_74

先进行一次提交,提交后在History窗口中重置这次提交,如图:

Eclipse上GIT插件EGIT使用手册_服务器_75

重置后查看工做树,如图

Eclipse上GIT插件EGIT使用手册_服务器端_76

从上图能够看出,soft文件还存在,说明重置没有改变工做树,并且soft文件不是“问号”图标,说明已经添加到索引,说明索引也没有变。惟一重置的是历史记录。

而后新建Mixed.java文件,此时Mixed.java也没有添加到索引控制,而后提交。

Eclipse上GIT插件EGIT使用手册_git仓库_77

在History窗口中重置

Eclipse上GIT插件EGIT使用手册_重置_78

重置后查看工做树结果以下:

Eclipse上GIT插件EGIT使用手册_git仓库_79

从上图能够看出,Mixed.java文件还存在,说明工做树没有改变,可是文件状态是untracked,说明索引被更新,此时文件没有添加索引控制。

最后来看hard重置,新建Hard.java文件,此时文件没有添加索引,而后提交。

Eclipse上GIT插件EGIT使用手册_重置_80

在History界面重置这次提交,如图:

Eclipse上GIT插件EGIT使用手册_重置_81

重置后再查看工做树,结果以下:

Eclipse上GIT插件EGIT使用手册_git仓库_82

能够看到Hard.java文件已经不存在了,说明索引和工做树都被更新。

 

url:http://blog.csdn.net/luckarecs/article/details/7427605