git--eclipse教程

图片见：http://www.cnblogs.com/lufeel/p/4883631.html

1.下载egit插件

打开Eclipse，git需要eclipse授权，通过网页是无法下载egit的安装包的。在菜单栏依次打开eclipse→help→install new software→add，Name栏中输入egit，location栏中输入 http://download.eclipse.org/egit/updates/ ，点击ok进行下载。下载完成后会提示重启eclipse；如果已经有了就不需要了。

2、在Eclipse中生public key, 并添加到GitHub Repository中。

在菜单栏依次打开window → preference → general → network connection → SSH2 → Key Management → generate RSA Key... → apply → save private key...

生成 SSH 的 public key在GitHub中通过：edit your profile -> ssh key -> Add SSH Key 添加SSH Key, 把上面生成的 public key 拷贝到这里，保存。

3、导入现有工程（看下后续的设置）preference--team里面也可以设置
打开一个工程，在工程名上右键，点击team→share project，将你的工程另外导入到一个git文件夹。

4、提交
在项目上点右键–>team–>commit。commit是commit到本机的git库，而push才是同步到github。

在弹出窗口输入你的GitHub 用户名和邮箱

提交文件到本地，并推送到服务器

然后需要输入你GitHub上项目的仓库地址，没有的话需要新建项目，步骤如下：

输入上面的URL地址，以及你的用户名和密码

然后等待Eclipse帮你把项目提交就行了

5、提交时可能会出现不能连接的错误，请参考

dust项目托管github过程

使用命令行生成一个本地的ssh，建立连接后再用eclipse提交代码。

详细的egit使用手册（图文）

转自：http://www.cnblogs.com/yc-755909659/p/3753626.html

来源：在android的eclipse开发环境中配置git环境

转自csdn博客：结合比较完美了http://blog.csdn.net/laiwenqiang/article/details/40790967

二_使用EGIT前的配置

配置个人信息，最重要的是user.name和user.email

l Preferences > Team > Git > Configuration

l New Entry

三_新建GIT仓库

新建NC module project 在eclipse里面创建

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状态

五_查看历史记录

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

可以选择对比模式

1.通过【Window -> Show View -> Git Repositories】打开Git Repositories视图
2.在视图里选自【Clone a Git Repository】
3.把Github上工程的SSH访问的URL拷贝到URI里面。输入口令，Next>
4.选择要Clone的branch名，一般是master。Next>
5.选择要Clone到本的的哪个位置，注意最好不要选择Eclipse的workspace目录。Check上【Import all existing projects after clone finishes】就能够在clone完成后自动把工程导入到Eclipse里。Finish。

剩下的就交给Eclipse自动完成了。
成功以后Eclipse Repositories视图里会出现Clone后的本地git库，Project视图里面会出现导入的工程。

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

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

ssh://[email protected]: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的区别

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操作更复杂，冲突的概率也更高，并且不是按照时间顺序记录。