Eclipse上GIT外掛程式EGIT使用手冊

一_安裝EGIT外掛程式

 

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

或者使用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操作更複雜，衝突的機率也更高，並且不是按照時間順序記錄。

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

此小結為什麼說是簡單解析呢，因為rebase和merge的選擇問題討論比較激烈，筆者也沒有一個定論，而且git也處於研究發展階段，很多理論還沒有完全的純熟。

對於一個多人Team Dev頻繁提交更新的情況，如果使用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目錄下：

十一_Fetch和Rebase

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檔案已經不存在了，說明索引和工作樹都被更新。