Git(3)----Eclipse上Git插件使用技巧
轉載：http://blog.csdn.net/qq_33066205/article/details/56675704
一_安裝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://[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的區別
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*。
十_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界面重置此次提交，如圖：
重置後再查看工作樹，結果如下：
Git(3)----Eclipse上Git插件使用技巧