一_安裝EGIT插件

?

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

或者使用Eclipse Marketplace，搜索EGit

?

?

二_使用EGIT前的配置

配置個(gè)人信息，最重要的是user.name和user.email

l? Preferences > Team > Git > Configuration

l? New Entry

?

?

三_新建GIT倉庫

新建NC module project

l? File > Team > Share Project 選擇GIT

創(chuàng)建倉庫后，在$workspace\demo目錄下的.git文件夾，就是git的倉庫地址。和CVS、SVN不同，GIT不會在每一個(gè)目錄下建立版本控制文件夾，僅在根目錄下建立倉庫

同時(shí)，eclipse中的project也建立git版本控制，此時(shí)未創(chuàng)建分支，處于NO-HEAD狀態(tài)

文件夾中的符號”?”表示此文件夾處于untracked狀態(tài)，這樣就成功創(chuàng)建GIT倉庫。

?

四_配置.gitignore

此時(shí)我們嘗試做一次提交

l? Team -> Commit…

如上圖所示，Author和Committer會默認(rèn)為Git配置的用戶信息。下面的Files窗口中可以看到此次提交的文件，其中有非常多帶有NC_HOME的文件，此時(shí)可以猜測出，在我們的project中鏈接的NC_HOME也被GIT默認(rèn)到版本控制中了，如下圖：

顯然NC_HOME和out是不需要進(jìn)行版本控制的，我們可以通過配置.gitignore來排除這兩個(gè)文件夾

打開Navigator窗口，在project根目錄中添加.gitignore文件，將需要排除控制的目錄寫入.gitignore文件中

再次嘗試commit，需要提交的文件已經(jīng)被過濾

首次提交后，會自動(dòng)生成master分支

然后在public中新建一個(gè)文件，可以看到圖標(biāo)依然是問號，處于untracked狀態(tài)，即git沒有對此文件進(jìn)行監(jiān)控

通過Team -> Add to index可以將文件加入git索引，進(jìn)行版本監(jiān)控

可以看到圖標(biāo)顯示也有了變化（EGIT中只要Commit就可以默認(rèn)將untracked的文件添加到索引再提交更新，不需要分開操作）

也可以通過Team -> Untrack將文件從索引控制中排除。

將此次新增的文件commit到倉庫中，文件將處于unmodified狀態(tài)，或者說，這就是一種staged狀態(tài)

然后修改文件的內(nèi)容，文件將處于modified狀態(tài)

?

?

?

五_查看歷史記錄

Team -> Show in history可以查看版本歷史提交記錄

?

可以選擇對比模式

?

?

?

?

六_遠(yuǎn)程GIT倉庫

此小結(jié)的前提是已經(jīng)搭建GIT服務(wù)器，并通過SSH協(xié)議連接，可參看文檔《RHEL下搭建GIT服務(wù)器》《WindowsXP下搭建GIT服務(wù)器》《GIT服務(wù)器使用基礎(chǔ)》。本文使用RHEL5.5系統(tǒng)下的GIT-2012-01-11，用戶root/password，GIT倉庫統(tǒng)一存放在/app/gitspace目錄下。

首先通過shell工具連接到服務(wù)器，建立空倉庫gitdemo，此時(shí)的ssh訪問地址如下,分別由協(xié)議名稱、用戶名、IP、端口、git倉庫目錄組成。

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

打開GIT資源庫窗口，選擇克隆資源庫

現(xiàn)在已經(jīng)把遠(yuǎn)程的GIT倉庫克隆到本地，接下來需要將倉庫檢出為NC模塊項(xiàng)目。

最后得到gitdemo模塊項(xiàng)目，分支是mirror

?

?

七_(dá)推送遠(yuǎn)程倉庫

克隆服務(wù)器端倉庫后，會在本地建立一個(gè)一樣的倉庫，稱本地倉庫。在本地進(jìn)行commit操作將把更新提交到本地倉庫，然后可以將服務(wù)器端的更新pull到本地倉庫進(jìn)行合并，最后將合并好的本地倉庫push到服務(wù)器端，這樣就進(jìn)行了一次遠(yuǎn)程提交。

先提交一次到本地倉庫

然后push到服務(wù)器端的mirror分支，Team -> remote -> Push

完成推送后，可以在服務(wù)器端mirror鏡像的log中查看到此次記錄

?

?

?

八_解決推送沖突

多人協(xié)作開發(fā)的情況下，往服務(wù)器推送更新時(shí)難免出現(xiàn)沖突，所以推送之前需要解決服務(wù)器端的最新版本和本地倉庫的沖突。Pull操作就是把服務(wù)器端的更新拉攏到本地倉庫進(jìn)行合并，解決好合并沖突后，就可以順利push到服務(wù)器分支了。

假設(shè)現(xiàn)在Mairo兄弟在用GIT協(xié)作開發(fā)NewSuperMairoBro游戲，目前服務(wù)器端的mushroom.java文件的內(nèi)容如下：

MairoBro克隆出代碼后，Mairo哥哥做了如下修改

Mairo弟弟做了如下修改

然后Mairo弟弟先push代碼，Mairo哥哥使用pull來合并本地倉庫和遠(yuǎn)程倉庫，將發(fā)行文件出現(xiàn)沖突，此時(shí)GIT會自動(dòng)合并沖突的文件，如下圖所示：

很明顯自動(dòng)合并的沖突文件不能直接使用，我們可以手動(dòng)調(diào)整，右鍵發(fā)生沖突的文件，選擇Team -> Merge Tool

第一項(xiàng)是將GIT自動(dòng)合并過的文件和服務(wù)器端文件進(jìn)行對比

第二項(xiàng)是用本地最新版本的文件和服務(wù)器端文件進(jìn)行對比，建議用此項(xiàng)

接下來就是熟悉的對比界面

Mairo哥哥將沖突文件修改如下

然后右鍵點(diǎn)擊此沖突文件，選擇Team -> Add to index再次將文件加入索引控制，此時(shí)文件已經(jīng)不是沖突狀態(tài)，并且可以進(jìn)行提交并push到服務(wù)器端

解決合并沖突后，Mairo弟弟只需要將服務(wù)器中合并后的版本pull到本地，就完成了一次協(xié)作開發(fā)的代碼合并。從歷史記錄中可以看到，從mushroom開始?xì)v史進(jìn)入分支，先是mushroomA的記錄，然后是mushroomB的記錄，最后歷史分支合并。

?

?

?

九_Rebase和Merge的區(qū)別

Rebase和Merge操作最終的結(jié)果是一樣的，但是實(shí)現(xiàn)原理不一樣。

從上面的MairoBro例子可以知道pull大概對歷史記錄進(jìn)行了怎樣的合并操作，其實(shí)默認(rèn)pull的操作就是一個(gè)分支的merge操作，如下圖重現(xiàn)一下：

Mairo弟弟的提交記錄如下：

Mairo哥哥的提交記錄如下：

首先是Mairo弟弟把更新push到服務(wù)器，這樣服務(wù)器端的記錄就和Mairo弟弟本地的記錄是一樣的，接著Mairo哥哥執(zhí)行pull操作，現(xiàn)在分析下pull是如何操作的。

l? pull默認(rèn)就是先把服務(wù)器端的最新記錄更新到本地的Remote Tracking中對應(yīng)的mirror分支

l? 接著對Local的mirror分支和Remote Tracking的mirror分支進(jìn)行merge操作

Merge操作后的結(jié)果就是會新增加一個(gè)merge記錄節(jié)點(diǎn)，如下所示：

從上圖可以看出，mushroomA是在mushroomB之前的，這個(gè)時(shí)間關(guān)系不取決于誰先執(zhí)行push，而取決于本地倉庫中誰先執(zhí)行commit。所以merge會按照時(shí)間順序嚴(yán)格的記錄每一次commit。

接下來看看rebase，其實(shí)rebase也是把兩個(gè)分支進(jìn)行合并的操作，當(dāng)Mairo弟弟push更新后，服務(wù)器端的mirror分支的歷史如下：

Mairo哥哥本地的歷史如下：

現(xiàn)在Mairo哥哥不是執(zhí)行merge操作，而是執(zhí)行rebase操作，最后結(jié)果如下：

很明顯的區(qū)別是沒有出現(xiàn)分支的記錄，而且注意到mushroomA*，請注意這個(gè)記錄和mushroomA不是同一個(gè)記錄，我們先分析下rebase操作下，Mairo哥哥的歷史記錄都做了哪些變化：

l? 先將當(dāng)前分支的更新部分保存到臨時(shí)區(qū)域，而當(dāng)前分支重置到上一次pull的記錄

l? 然后將服務(wù)器端的更新添加到當(dāng)前分支，此時(shí)當(dāng)前分支和服務(wù)器端分支是一樣的

l? 最后將原分支的更新部分mushroomA提交到當(dāng)前分支的后面，就是要在mushroomB的后面添加mushroomA的更新，當(dāng)然此時(shí)更新記錄已經(jīng)不是之前的mushroomA了，如果出現(xiàn)沖突則使用對比工具解決沖突，最后記錄變成mushroomA*。

如果Mairo哥哥提交過mushroomA1、mushroomA2、mushroomA3，那么執(zhí)行rebase后會對mushroomA1、mushroomA2、mushroomA3分別順序執(zhí)行上圖所示的合并，最后記錄為mushroomA1*、mushroomA2*、mushroomA3*。很顯然rebase操作更復(fù)雜，沖突的概率也更高，并且不是按照時(shí)間順序記錄。

?

?

?

十_Rebase和Merge如何選擇的簡單解析

此小結(jié)為什么說是簡單解析呢，因?yàn)閞ebase和merge的選擇問題討論比較激烈，筆者也沒有一個(gè)定論，而且git也處于研究發(fā)展階段，很多理論還沒有完全的純熟。

對于一個(gè)多人開發(fā)團(tuán)隊(duì)頻繁提交更新的情況，如果使用merge會使得歷史線圖非常復(fù)雜，并且merge一次就會新增一個(gè)記錄點(diǎn)，如果使用rebase就是完全的線性開發(fā)。

上圖所示是Merge和Rebase的兩個(gè)結(jié)果，顯然你不想要merge的混亂結(jié)果吧，你能告訴我merge圖中那條線是master分支嗎？

所以給出如下建議，如果同一文件反復(fù)修改或提交次數(shù)比較多，預(yù)期會出現(xiàn)很多的conflict，那么可以使用merge合并，僅需要解決一次沖突即可（不過，大范圍主題式的修改，是不是應(yīng)該事先就新開一個(gè)分支呢？）；如果修改范圍小，預(yù)期conflict少，則建議使用rebase。

EGIT中默認(rèn)的pull操作是Fetch+Merge，如果要用rebase，可以分開操作。先執(zhí)行Fetch更新remote tracking，再執(zhí)行rebase進(jìn)行合并（下一小節(jié)將介紹rebase操作）。或者修改pull的默認(rèn)操作，在.git/config文件中配置：

上述配置只對mirror分支有效，也可做全局配置，在$HOME/.gitconfig中配置，windows系統(tǒng)如果沒有配置HOME變量的話就默認(rèn)在$documents and settings/ USER目錄下：

?

?

?

十一_Fetch和Rebase

MairoBro來做fetch和rebase的測試，首先Mairo弟弟在client中添加文件OPQ分別提交，并push到服務(wù)器，如圖：

此時(shí)服務(wù)器端的歷史已經(jīng)被更新，但是Mairo哥哥的remote tracking中mirror分支并沒有更新到最新的記錄，如圖：

所以需要更新remote tracking中的分支，使得它與服務(wù)器端的分支同步，右鍵點(diǎn)擊資源庫選擇Fetch

這樣就更新了本地的remote tracking中的分支，使得它和服務(wù)器端分支同步。

然后Mairo哥哥在本地的private中添加文件ABC，并分別提交到本地倉庫中。

然后將本地mirror分支和remote tracking中的mirror分支進(jìn)行rebase，先checkout本地mirror分支 ，然后右鍵點(diǎn)擊選擇Rebase

如上圖可以看到歷史記錄的順序是OPQABC，已經(jīng)rebase成功，接著push到服務(wù)器即可。

?

十二_重置功能

GIT中有三種重置功能，分別是soft、mixed、hard，區(qū)別如下：

l??Soft -?當(dāng)前分支重置到指定commit記錄位置，索引和工作樹不變；

l??Mixed -?當(dāng)前分支重置到指定commit記錄位置，索引被更新，工作樹不變；

l??Hard -?當(dāng)前分支重置到指定commit記錄位置，索引和工作樹都更新。

貌似不好理解，首先要理解GIT的三個(gè)區(qū)域（工作樹、索引區(qū)、倉庫），可以參考文檔《GIT簡介》。

先做soft的測試，新建Soft.java文件，可以看到此文件未添加到索引控制

先進(jìn)行一次提交，提交后在History窗口中重置此次提交，如圖：

重置后查看工作樹，如圖

從上圖可以看出，soft文件還存在，說明重置沒有改變工作樹，而且soft文件不是“問號”圖標(biāo)，說明已經(jīng)添加到索引，說明索引也沒有變。唯一重置的是歷史記錄。

然后新建Mixed.java文件，此時(shí)Mixed.java也沒有添加到索引控制，然后提交。

在History窗口中重置

重置后查看工作樹結(jié)果如下：

從上圖可以看出，Mixed.java文件還存在，說明工作樹沒有改變，但是文件狀態(tài)是untracked，說明索引被更新，此時(shí)文件沒有添加索引控制。

最后來看hard重置，新建Hard.java文件，此時(shí)文件沒有添加索引，然后提交。

在History界面重置此次提交，如圖：

重置后再查看工作樹，結(jié)果如下：

可以看到Hard.java文件已經(jīng)不存在了，說明索引和工作樹都被更新。

轉(zhuǎn)載于:https://www.cnblogs.com/allenguo/archive/2013/05/23/3095121.html

總結(jié)

以上是生活随笔為你收集整理的eclipse中git的使用----EGIT插件的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。