本文的目的是

1.在 Myeclipse10.7中 整合Github並使用。

選擇的安裝方式是：MyEclipse 中設定下文中1後，下載github與當前myeclilpse版本對應的壓縮包，然後 Install new software from archive。

2.在Myeclipse中使用github管理專案。

用慣了svn的同學們來用github剛開始確實不太習慣，專案管理無非4點：更新、提交、回覆、處理衝突。但是github里加入了克隆分支的概念就有點複雜了。

提交：

1、team >> commit (commit視窗下要勾選push，不勾選需要繼續push) ；

2、team >>  push 

更新：

team >> fetch from head  +  team >>  pull

回覆：

team >> reset >> hard

處理衝突：

fetch + rebase   或  fetch + merge

具體使用還是要詳細研究。

1.

MyEclipse 中有一個 Software and Workspace center，這東西，載入特別慢，我用10版本基本是沒有可能看到這個介面。更別說線上安裝外掛了，如果有eclipse原來的 “install new software”選單就好了。

其實，這個選單還是有的，只是就隱藏起來了。如圖：

將圖中的classic update 選中，就可以了。

如果沒有看到 Install new software，重啟一下就OK。

恩，現在是想裝什麼都可以裝了。

大綱

　　1.git客戶端安裝

　　2.ssh配置

　　3.egit安裝配置

　　4.參考資料

1.egit的安裝

　　當然也可以選擇在Eclipse Marketplace中搜索

　　Next到底就OK了。

　　二、配置EGit

　　這裡有個前提,就是首先電腦上必須安裝有git的客戶端

　　安裝之後，開啟Eclipse

　　選擇git客戶端的安裝路徑，接著在Configuration中配置user Settings的user和email

　　這個使用者名稱必須是github的使用者,還沒註冊的，點選這裡申請https://github.com/

　　到此,外掛的配置結束

　　非常激動的開始建立一個DEMO試試

　　 File > Team > Share Project 選擇GIT

　　這裡選中Git的時候，會提示設定HOME環境變數

　　HOM-->%USERPROFILE%

　　接著就建立一個倉庫

　　三、上傳工程

　　首先需要登入github

　　建立一個空的倉庫

　　點選Create a new repository

　　因為我已經建立過一個GitDemo，就不再演示

　　點選上傳

　　提示exception caught during execution of ls-remote command

　　發現是沒有私鑰。

　　這裡簡單說明下egit的工作原理

　　事實上，熟悉CVS或則SVN的朋友肯定知道，當我們點選commit的時候，版本管理器會將我們修改的內容進行同步更新

　　但是egit卻沒有那麼智慧，事實上,GIT有個本地倉庫的概念，也就是說當我們commit的時候，我們把更新的內容資訊

　　同步到本地倉庫，點選push的時候才將本地倉庫中的更新內容提交到github

　　本地倉庫路徑window-->show view-->other-->Git Repositories

　　說多了，不知大家有沒印象，最早配置EGit的User Settings的時候之後使用者的名稱，沒有密碼

　　Passwords aren't very secure, you already know this. If you use one that's easy to remember, it's easier to guess or brute-force (try many options until one works). If you use one that's random it's hard to remember, and thus you're more inclined to write the password down. Both of these are Very Bad Things?. This is why you're using ssh keys.

　　上述這段話是github給出的解釋，通俗點說，github擔心使用者使用過於簡單的密碼造成安全隱患，或則是密碼過於複雜造成使用者難以記住帶來的不必要麻煩

　　因此採用SSH keys的方式

　　四、SSH配置

　　如何生成屬於自己的SSH kyes，操作如下

　　1.開啟Git Bash

　　發現沒有RSA檔案

　　接著輸入

　　提示沒有許可權。

　　繼續輸入

　　ssh-keygen （一直enter）

　　上述路徑不是唯一的，大家自己把握之前HOME配置的路徑

　　最後測試下

　　配置SSH2

　　簡單解釋下，之前上傳的是SSH keys的公鑰，而id_rsa中存放的就是我們的私鑰，因此當我們上傳(push)的時候只需要

　　輸入公共的賬號git即可

　　參考資料:

　　2.如何刪除repository（倉庫）

　　3.開始egit的使用:http://wiki.eclipse.org/EGit/User_Guide/Getting_Started

　　4.更多參考:http://wiki.eclipse.org/EGit/User_Guide#Github_Tutorial

Eclipse上使用Github

配置個人資訊，最重要的是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檔案已經不存在了，說明索引和工作樹都被更新。

更多進階教程推薦

鑑於本文只是一篇拋磚引玉的入門教程，就不再詳述更多的細節，如果對Git感興趣的同學，可以看看下面這些，它們可以幫助你成為一名專家、至少是設計師中的Git專家 :)