一_安裝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也處於研究發展階段，很多理論還沒有完全的純熟。
對於一個多人開發團隊頻繁提交更新的情況，如果使用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文件已經不存在了，說明索引和工作樹都被更新。
url:http://blog.csdn.net/luckarecs/article/details/7427605