Eclipse中使用git手冊

一_安裝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哥哥提交過mushroomA一、mushroomA二、mushroomA3，那麼執行rebase後會對mushroomA一、mushroomA二、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文件已經不存在了，說明索引和工做樹都被更新。