或者使用Eclipse Marketplace，搜尋EGit

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

l  Preferences > Team > Git > Configuration

l  New Entry

新建NC module project

l  File > Team > Share Project 選擇GIT

建立倉庫後，在$workspace\demo目錄下的.git資料夾，就是git的倉庫地址。和CVS、SVN不同，GIT不會在每一個目錄下建立版本控制資料夾，僅在根目錄下建立倉庫

同時，eclipse中的project也建立git版本控制，此時未建立分支，處於NO-HEAD狀態

資料夾中的符號”?”表示此資料夾處於untracked狀態，這樣就成功建立GIT倉庫。

此時我們嘗試做一次提交

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伺服器，並通過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操作最終的結果是一樣的，但是實現原理不一樣。

從上面的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的選擇問題討論比較激烈，筆者也沒有一個定論，而且git也處於研究發展階段，很多理論還沒有完全的純熟。

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

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