Eclipse上GIT外掛EGIT使用手冊

銳湃發表於2015-08-31

或者使用Eclipse Marketplace，搜尋EGit

二_使用EGIT前的配置

配置個人資訊，最重要的是user.name和user.email

l Preferences > Team > Git > Configuration

l New Entry

三_新建GIT倉庫

新建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狀態

五_檢視歷史記錄

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

可以選擇對比模式

六_遠端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資源庫視窗，選擇克隆資源庫

現在已經把遠端的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操作更復雜，衝突的概率也更高，並且不是按照時間順序記錄。