本帖最后由 snowxwyo 于 2013-4-28 13:32 編輯 看到大家在討論github的使用,,我用的也不多,,偶爾clone一些好的源代碼而已。我用的是Eclipse的插件EGit,,全部操作直接在eclispe里就可以完成了,,哈哈,我比較懶,,官網(wǎng)上教的那些git clone 什么的高深操作我也不會,,感覺egit還是比較好用的,所以上網(wǎng)搜了一個關(guān)于egit的詳細操作的帖子,,現(xiàn)在搬過來和大家一起分享一下,。我找到的這個帖子的地址是:http://blog.csdn.net/luckarecs/article/details/7427605。雖然這篇帖子也寫的是轉(zhuǎn)載,,我沒找到最原始的出處,,(PS:有人反饋說原始出處是這:http://blog.csdn.net/laizhenhai88/article/details/7234974,我不敢確定,,不過還是把這個鏈接放上來吧,,謝謝@ter 的反饋),不過如果大家轉(zhuǎn)載的話,,還是要把這個鏈接加上,,這也算是保護知識產(chǎn)權(quán)了吧,哈哈,,好了,,費話不多說了,以下是詳細內(nèi)容: 一_安裝EGIT插件 http://download./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 創(chuàng)建倉庫后,在$workspace\demo目錄下的.git文件夾,,就是git的倉庫地址,。和CVS,、SVN不同,GIT不會在每一個目錄下建立版本控制文件夾,,僅在根目錄下建立倉庫 同時,,eclipse中的project也建立git版本控制,,此時未創(chuàng)建分支,處于NO-HEAD狀態(tài) 文件夾中的符號”?”表示此文件夾處于untracked狀態(tài),這樣就成功創(chuàng)建GIT倉庫,。 四_配置.gitignore此時我們嘗試做一次提交 l Team -> Commit… 如上圖所示,,Author和Committer會默認為Git配置的用戶信息,。下面的Files窗口中可以看到此次提交的文件,,其中有非常多帶有NC_HOME的文件,此時可以猜測出,,在我們的project中鏈接的NC_HOME也被GIT默認到版本控制中了,,如下圖: 顯然NC_HOME和out是不需要進行版本控制的,我們可以通過配置.gitignore來排除這兩個文件夾 打開Navigator窗口,,在project根目錄中添加.gitignore文件,,將需要排除控制的目錄寫入.gitignore文件中 再次嘗試commit,需要提交的文件已經(jīng)被過濾 首次提交后,,會自動生成master分支 然后在public中新建一個文件,,可以看到圖標依然是問號,處于untracked狀態(tài),,即git沒有對此文件進行監(jiān)控 通過Team -> Add to index可以將文件加入git索引,,進行版本監(jiān)控 可以看到圖標顯示也有了變化(EGIT中只要Commit就可以默認將untracked的文件添加到索引再提交更新,不需要分開操作) 也可以通過Team -> Untrack將文件從索引控制中排除,。 將此次新增的文件commit到倉庫中,,文件將處于unmodified狀態(tài),或者說,,這就是一種staged狀態(tài) 然后修改文件的內(nèi)容,,文件將處于modified狀態(tài) 五_查看歷史記錄Team -> Show in history可以查看版本歷史提交記錄 可以選擇對比模式 六_遠程GIT倉庫此小結(jié)的前提是已經(jīng)搭建GIT服務器,并通過SSH協(xié)議連接,,可參看文檔《RHEL下搭建GIT服務器》《WindowsXP下搭建GIT服務器》《GIT服務器使用基礎》,。本文使用RHEL5.5系統(tǒng)下的GIT-2012-01-11,用戶root/password,,GIT倉庫統(tǒng)一存放在/app/gitspace目錄下,。 首先通過shell工具連接到服務器,建立空倉庫gitdemo,,此時的ssh訪問地址如下,分別由協(xié)議名稱,、用戶名,、IP,、端口,、git倉庫目錄組成。 ssh://[email protected]:22/app/gitspace/gitdemo 打開GIT資源庫窗口,,選擇克隆資源庫 現(xiàn)在已經(jīng)把遠程的GIT倉庫克隆到本地,,接下來需要將倉庫檢出為NC模塊項目。 最后得到gitdemo模塊項目,,分支是mirror 七_推送遠程倉庫 克隆服務器端倉庫后,,會在本地建立一個一樣的倉庫,稱本地倉庫,。在本地進行commit操作將把更新提交到本地倉庫,,然后可以將服務器端的更新pull到本地倉庫進行合并,最后將合并好的本地倉庫push到服務器端,,這樣就進行了一次遠程提交,。 先提交一次到本地倉庫 然后push到服務器端的mirror分支,Team -> remote -> Push 完成推送后,,可以在服務器端mirror鏡像的log中查看到此次記錄 八_解決推送沖突 多人協(xié)作開發(fā)的情況下,,往服務器推送更新時難免出現(xiàn)沖突,所以推送之前需要解決服務器端的最新版本和本地倉庫的沖突,。Pull操作就是把服務器端的更新拉攏到本地倉庫進行合并,,解決好合并沖突后,就可以順利push到服務器分支了,。 假設現(xiàn)在Mairo兄弟在用GIT協(xié)作開發(fā)NewSuperMairoBro游戲,,目前服務器端的mushroom.java文件的內(nèi)容如下: MairoBro克隆出代碼后,Mairo哥哥做了如下修改 Mairo弟弟做了如下修改 然后Mairo弟弟先push代碼,,Mairo哥哥使用pull來合并本地倉庫和遠程倉庫,,將發(fā)行文件出現(xiàn)沖突,此時GIT會自動合并沖突的文件,,如下圖所示: 很明顯自動合并的沖突文件不能直接使用,,我們可以手動調(diào)整,右鍵發(fā)生沖突的文件,,選擇Team -> Merge Tool 第一項是將GIT自動合并過的文件和服務器端文件進行對比 第二項是用本地最新版本的文件和服務器端文件進行對比,,建議用此項 接下來就是熟悉的對比界面 Mairo哥哥將沖突文件修改如下 然后右鍵點擊此沖突文件,選擇Team -> Add to index再次將文件加入索引控制,,此時文件已經(jīng)不是沖突狀態(tài),,并且可以進行提交并push到服務器端 解決合并沖突后,Mairo弟弟只需要將服務器中合并后的版本pull到本地,,就完成了一次協(xié)作開發(fā)的代碼合并,。從歷史記錄中可以看到,從mushroom開始歷史進入分支,,先是mushroomA的記錄,,然后是mushroomB的記錄,,最后歷史分支合并。 九_Rebase和Merge的區(qū)別 Rebase和Merge操作最終的結(jié)果是一樣的,,但是實現(xiàn)原理不一樣,。 從上面的MairoBro例子可以知道pull大概對歷史記錄進行了怎樣的合并操作,其實默認pull的操作就是一個分支的merge操作,,如下圖重現(xiàn)一下: Mairo弟弟的提交記錄如下: Mairo哥哥的提交記錄如下: 首先是Mairo弟弟把更新push到服務器,,這樣服務器端的記錄就和Mairo弟弟本地的記錄是一樣的,接著Mairo哥哥執(zhí)行pull操作,,現(xiàn)在分析下pull是如何操作的,。 l pull默認就是先把服務器端的最新記錄更新到本地的Remote Tracking中對應的mirror分支 l 接著對Local的mirror分支和Remote Tracking的mirror分支進行merge操作 Merge操作后的結(jié)果就是會新增加一個merge記錄節(jié)點,如下所示: 從上圖可以看出,,mushroomA是在mushroomB之前的,,這個時間關(guān)系不取決于誰先執(zhí)行push,而取決于本地倉庫中誰先執(zhí)行commit,。所以merge會按照時間順序嚴格的記錄每一次commit,。 接下來看看rebase,其實rebase也是把兩個分支進行合并的操作,,當Mairo弟弟push更新后,,服務器端的mirror分支的歷史如下: Mairo哥哥本地的歷史如下: 現(xiàn)在Mairo哥哥不是執(zhí)行merge操作,而是執(zhí)行rebase操作,,最后結(jié)果如下: 很明顯的區(qū)別是沒有出現(xiàn)分支的記錄,,而且注意到mushroomA*,請注意這個記錄和mushroomA不是同一個記錄,,我們先分析下rebase操作下,,Mairo哥哥的歷史記錄都做了哪些變化: l 先將當前分支的更新部分保存到臨時區(qū)域,而當前分支重置到上一次pull的記錄 l 然后將服務器端的更新添加到當前分支,,此時當前分支和服務器端分支是一樣的 l 最后將原分支的更新部分mushroomA提交到當前分支的后面,,就是要在mushroomB的后面添加mushroomA的更新,當然此時更新記錄已經(jīng)不是之前的mushroomA了,,如果出現(xiàn)沖突則使用對比工具解決沖突,,最后記錄變成mushroomA*。 如果Mairo哥哥提交過mushroomA1,、mushroomA2,、mushroomA3,那么執(zhí)行rebase后會對mushroomA1,、mushroomA2,、mushroomA3分別順序執(zhí)行上圖所示的合并,最后記錄為mushroomA1*,、mushroomA2*,、mushroomA3*,。很顯然rebase操作更復雜,沖突的概率也更高,,并且不是按照時間順序記錄。十_Rebase和Merge如何選擇的簡單解析 此小結(jié)為什么說是簡單解析呢,,因為rebase和merge的選擇問題討論比較激烈,,筆者也沒有一個定論,而且git也處于研究發(fā)展階段,,很多理論還沒有完全的純熟,。 對于一個多人開發(fā)團隊頻繁提交更新的情況,如果使用merge會使得歷史線圖非常復雜,,并且merge一次就會新增一個記錄點,,如果使用rebase就是完全的線性開發(fā)。 上圖所示是Merge和Rebase的兩個結(jié)果,,顯然你不想要merge的混亂結(jié)果吧,,你能告訴我merge圖中那條線是master分支嗎? 所以給出如下建議,,如果同一文件反復修改或提交次數(shù)比較多,,預期會出現(xiàn)很多的conflict,那么可以使用merge合并,,僅需要解決一次沖突即可(不過,,大范圍主題式的修改,是不是應該事先就新開一個分支呢,?),;如果修改范圍小,預期conflict少,,則建議使用rebase,。 EGIT中默認的pull操作是Fetch+Merge,如果要用rebase,,可以分開操作,。先執(zhí)行Fetch更新remote tracking,再執(zhí)行rebase進行合并(下一小節(jié)將介紹rebase操作),?;蛘咝薷膒ull的默認操作,在.git/config文件中配置: 上述配置只對mirror分支有效,,也可做全局配置,,在$HOME/.gitconfig中配置,windows系統(tǒng)如果沒有配置HOME變量的話就默認在$documents and settings/ USER目錄下: 十一_Fetch和Rebase MairoBro來做fetch和rebase的測試,,首先Mairo弟弟在client中添加文件OPQ分別提交,,并push到服務器,,如圖: 此時服務器端的歷史已經(jīng)被更新,但是Mairo哥哥的remote tracking中mirror分支并沒有更新到最新的記錄,,如圖: 所以需要更新remote tracking中的分支,,使得它與服務器端的分支同步,右鍵點擊資源庫選擇Fetch 這樣就更新了本地的remote tracking中的分支,,使得它和服務器端分支同步,。 然后Mairo哥哥在本地的private中添加文件ABC,并分別提交到本地倉庫中,。 然后將本地mirror分支和remote tracking中的mirror分支進行rebase,,先checkout本地mirror分支 ,然后右鍵點擊選擇Rebase 如上圖可以看到歷史記錄的順序是OPQABC,,已經(jīng)rebase成功,,接著push到服務器即可。 十二_重置功能 GIT中有三種重置功能,,分別是soft,、mixed、hard,,區(qū)別如下: l Soft - 當前分支重置到指定commit記錄位置,,索引和工作樹不變; l Mixed - 當前分支重置到指定commit記錄位置,,索引被更新,,工作樹不變; l Hard - 當前分支重置到指定commit記錄位置,,索引和工作樹都更新,。 貌似不好理解,首先要理解GIT的三個區(qū)域(工作樹,、索引區(qū),、倉庫),可以參考文檔《GIT簡介》,。 先做soft的測試,,新建Soft.java文件,可以看到此文件未添加到索引控制 先進行一次提交,,提交后在History窗口中重置此次提交,,如圖: 重置后查看工作樹,如圖 從上圖可以看出,,soft文件還存在,,說明重置沒有改變工作樹,而且soft文件不是“問號”圖標,說明已經(jīng)添加到索引,,說明索引也沒有變,。唯一重置的是歷史記錄。 然后新建Mixed.java文件,,此時Mixed.java也沒有添加到索引控制,,然后提交。 在History窗口中重置 重置后查看工作樹結(jié)果如下: 從上圖可以看出,,Mixed.java文件還存在,,說明工作樹沒有改變,但是文件狀態(tài)是untracked,,說明索引被更新,此時文件沒有添加索引控制,。 最后來看hard重置,,新建Hard.java文件,此時文件沒有添加索引,,然后提交,。 在History界面重置此次提交,如圖: 重置后再查看工作樹,,結(jié)果如下: 可以看到Hard.java文件已經(jīng)不存在了,,說明索引和工作樹都被更新。PS:這里對第六點遠程GIT倉庫稍微做個補充,,我們一般情況下從github官網(wǎng)上clone代碼的時候,,這個遠程倉庫就是github了,首先我們在github上找到自己想要的源代碼,,這里以eoe客戶端的源代碼為例,,如圖: 在網(wǎng)頁的頂部我們可以找到地址,有https,ssh,和git only三個,,我一般都是選的ssh,然后把這個地址copy出來,,再回到eclipse中,點擊打開clone a git repository,在URI中把剛才復制的地址粘貼進去,,然后在protocol中選擇ssh就行了,,其它信息會自動補全 接著點next就行了,往后的操作就和文章中介紹的一樣了 |
|