git日常開(kāi)發(fā)功能手冊(cè)(編輯修改稿)
2025-07-26 11:08 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 m Git進(jìn)入到git的項(xiàng)目的對(duì)話框，點(diǎn)擊“Clone URI”進(jìn)入到git的克隆對(duì)話框。 新增/修改文件(add)選中文件或者項(xiàng)目根目錄，右鍵點(diǎn)擊“Add to Index”將新增或者修改的加入到git的暫存區(qū)。 提交文件(mit)通過(guò)eclipse插件的來(lái)提交更新的文件通過(guò)“mit”可以方便的在提交之前省去“add to index”操作 更新/推送文件(pull/push)此處可以看到落后遠(yuǎn)程服務(wù)器的提交次數(shù)（圖示數(shù)據(jù)為最后一次fetch操作的數(shù)據(jù)）一般通過(guò)項(xiàng)目同步來(lái)檢查是否存在沖突，此操作實(shí)際上是執(zhí)行了一次fetch操作操作后可以看到類(lèi)似SVN的狀態(tài)的文件列表處理完成沖突后,需要通過(guò)“mit”操作將處理完沖突的文件提交到git的暫存區(qū)，然后才能把文件推送到遠(yuǎn)程git倉(cāng)庫(kù)7 GIT分支分支的處理 分支簡(jiǎn)介 簡(jiǎn)介幾乎所有的版本控制系統(tǒng)都以某種形式支持分支。 使用分支意味著你可以把你的工作從開(kāi)發(fā)主線上分離開(kāi)來(lái)，以免影響開(kāi)發(fā)主線。 在很多版本控制系統(tǒng)中，這是一個(gè)略微低效的過(guò)程——常常需要完全創(chuàng)建一個(gè)源代碼目錄的副本。對(duì)于大項(xiàng)目來(lái)說(shuō)，這樣的過(guò)程會(huì)耗費(fèi)很多時(shí)間。有人把 Git 的分支模型稱為它的“必殺技特性”，也正因?yàn)檫@一特性，使得 Git 從眾多版本控制系統(tǒng)中脫穎而出。 為何 Git 的分支模型如此出眾呢？ Git 處理分支的方式可謂是難以置信的輕量，創(chuàng)建新分支這一操作幾乎能在瞬間完成，并且在不同分支之間的切換操作也是一樣便捷。 與許多其它版本控制系統(tǒng)不同，Git 鼓勵(lì)在工作流程中頻繁地使用分支與合并，哪怕一天之內(nèi)進(jìn)行許多次。 理解和精通這一特性，你便會(huì)意識(shí)到 Git 是如此的強(qiáng)大而又獨(dú)特，并且從此真正改變你的開(kāi)發(fā)方式。為了真正理解 Git 處理分支的方式，我們需要回顧一下 Git 是如何保存數(shù)據(jù)的。或許你還記得起步的內(nèi)容，Git 保存的不是文件的變化或者差異，而是一系列不同時(shí)刻的文件快照。在進(jìn)行提交操作時(shí)，Git 會(huì)保存一個(gè)提交對(duì)象（mit object）。知道了 Git 保存數(shù)據(jù)的方式，我們可以很自然的想到——該提交對(duì)象會(huì)包含一個(gè)指向暫存內(nèi)容快照的指針。 但不僅僅是這樣，該提交對(duì)象還包含了作者的姓名和郵箱、提交時(shí)輸入的信息以及指向它的父對(duì)象的指針。首次提交產(chǎn)生的提交對(duì)象沒(méi)有父對(duì)象，普通提交操作產(chǎn)生的提交對(duì)象有一個(gè)父對(duì)象，而由多個(gè)分支合并產(chǎn)生的提交對(duì)象有多個(gè)父對(duì)象，為了說(shuō)得更加形象，我們假設(shè)現(xiàn)在有一個(gè)工作目錄，里面包含了三個(gè)將要被暫存和提交的文件。 暫存操作會(huì)為每一個(gè)文件計(jì)算校驗(yàn)和（使用我們?cè)谄鸩街刑岬降?SHA1 哈希算法），然后會(huì)把當(dāng)前版本的文件快照保存到 Git 倉(cāng)庫(kù)中（Git 使用 blob 對(duì)象來(lái)保存它們），最終將校驗(yàn)和加入到暫存區(qū)域等待提交：$ git add README LICENSE$ git mit m 39。The initial mit of my project39。當(dāng)使用git mit進(jìn)行提交操作時(shí)，Git 會(huì)先計(jì)算每一個(gè)子目錄（本例中只有項(xiàng)目根目錄）的校驗(yàn)和，然后在 Git 倉(cāng)庫(kù)中這些校驗(yàn)和保存為樹(shù)對(duì)象。 隨后，Git 便會(huì)創(chuàng)建一個(gè)提交對(duì)象，它除了包含上面提到的那些信息外，還包含指向這個(gè)樹(shù)對(duì)象（項(xiàng)目根目錄）的指針。如此一來(lái)，Git 就可以在需要的時(shí)候重現(xiàn)此次保存的快照?，F(xiàn)在，Git 倉(cāng)庫(kù)中有五個(gè)對(duì)象：三個(gè) blob 對(duì)象（保存著文件快照）、一個(gè)樹(shù)對(duì)象（記錄著目錄結(jié)構(gòu)和 blob 對(duì)象索引）以及一個(gè)提交對(duì)象（包含著指向前述樹(shù)對(duì)象的指針和所有提交信息）。做些修改后再次提交，那么這次產(chǎn)生的提交對(duì)象會(huì)包含一個(gè)指向上次提交對(duì)象（父對(duì)象）的指針。Git 的分支，其實(shí)本質(zhì)上僅僅是指向提交對(duì)象的可變指針。 Git 的默認(rèn)分支名字是master。 在多次提交操作之后，你其實(shí)已經(jīng)有一個(gè)指向最后那個(gè)提交對(duì)象的master分支。 它會(huì)在每次的提交操作中自動(dòng)向前移動(dòng)。NOTEGit 的 “master” 分支并不是一個(gè)特殊分支。它就跟其它分支完全沒(méi)有區(qū)別。 之所以幾乎每一個(gè)倉(cāng)庫(kù)都有 master 分支，是因?yàn)間it init命令默認(rèn)創(chuàng)建它，并且大多數(shù)人都懶得去改動(dòng)它。 分支創(chuàng)建Git 是怎么創(chuàng)建新分支的呢？ 很簡(jiǎn)單，它只是為你創(chuàng)建了一個(gè)可以移動(dòng)的新的指針。 比如，創(chuàng)建一個(gè) testing 分支， 你需要使用git branch命令：$ git branch testing這會(huì)在當(dāng)前所在的提交對(duì)象上創(chuàng)建一個(gè)指針。那么，Git 又是怎么知道當(dāng)前在哪一個(gè)分支上呢？ 也很簡(jiǎn)單，它有一個(gè)名為HEAD的特殊指針。 請(qǐng)注意它和許多其它版本控制系統(tǒng)（如 Subversion 或 CVS）里的HEAD概念完全不同。 在 Git 中，它是一個(gè)指針，指向當(dāng)前所在的本地分支（譯注：將HEAD想象為當(dāng)前分支的別名）。 在本例中，你仍然在master分支上。 因?yàn)間it branch命令僅僅創(chuàng)建一個(gè)新分支，并不會(huì)自動(dòng)切換到新分支中去。你可以簡(jiǎn)單地使用git log命令查看各個(gè)分支當(dāng)前所指的對(duì)象。 提供這一功能的參數(shù)是decorate。$ git log oneline decoratef30ab (HEAD, master, testing) add feature 32 ability to add new34ac2 fixed bug 1328 stack overflow under certain conditions98ca9 initial mit of
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1