• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆-145  評(píng)論-173  文章-70  trackbacks-0
            最近在使用Git管理項(xiàng)目工程的時(shí)候,遇到了很多問題,也學(xué)習(xí)到了很多關(guān)于Git常見使用的技巧,下面就其中關(guān)于Git Stash的用法和大家分享下。
            首先,簡(jiǎn)單介紹下Git Stash命令的用法,詳細(xì)的用法在man文檔中有相關(guān)介紹,下面我來說明常見的使用。
            git stash: 備份當(dāng)前的工作區(qū)的內(nèi)容,從最近的一次提交中讀取相關(guān)內(nèi)容,讓工作區(qū)保證和上次提交的內(nèi)容一致。同時(shí),將當(dāng)前的工作區(qū)內(nèi)容保存到Git棧中。
            git stash pop: 從Git棧中讀取最近一次保存的內(nèi)容,恢復(fù)工作區(qū)的相關(guān)內(nèi)容。由于可能存在多個(gè)Stash的內(nèi)容,所以用棧來管理,pop會(huì)從最近的一個(gè)stash中讀取內(nèi)容并恢復(fù)。
            git stash list: 顯示Git棧內(nèi)的所有備份,可以利用這個(gè)列表來決定從那個(gè)地方恢復(fù)。
            git stash clear: 清空Git棧。此時(shí)使用gitg等圖形化工具會(huì)發(fā)現(xiàn),原來stash的哪些節(jié)點(diǎn)都消失了。
            關(guān)于Git Stash的詳細(xì)解釋,適用場(chǎng)合,這里做一個(gè)說明:
            使用git的時(shí)候,我們往往使用branch解決任務(wù)切換問題,例如,我們往往會(huì)建一個(gè)自己的分支去修改和調(diào)試代碼, 如果別人或者自己發(fā)現(xiàn)原有的分支上有個(gè)不得不修改的bug,我們往往會(huì)把完成一半的代碼 commit提交到本地倉(cāng)庫,然后切換分支去修改bug,改好之后再切換回來。這樣的話往往log上會(huì)有大量不必要的記錄。其實(shí)如果我們不想提交完成一半或者不完善的代碼,但是卻不得不去修改一個(gè)緊急Bug,那么使用'git stash'就可以將你當(dāng)前未提交到本地(和服務(wù)器)的代碼推入到Git的棧中,這時(shí)候你的工作區(qū)間和上一次提交的內(nèi)容是完全一樣的,所以你可以放心的修 Bug,等到修完Bug,提交到服務(wù)器上后,再使用'git stash apply'將以前一半的工作應(yīng)用回來。也許有的人會(huì)說,那我可不可以多次將未提交的代碼壓入到棧中?答案是可以的。當(dāng)你多次使用'git stash'命令后,你的棧里將充滿了未提交的代碼,這時(shí)候你會(huì)對(duì)將哪個(gè)版本應(yīng)用回來有些困惑,'git stash list'命令可以將當(dāng)前的Git棧信息打印出來,你只需要將找到對(duì)應(yīng)的版本號(hào),例如使用'git stash apply stash@{1}'就可以將你指定版本號(hào)為stash@{1}的工作取出來,當(dāng)你將所有的棧都應(yīng)用回來的時(shí)候,可以使用'git stash clear'來將棧清空。
            在這里順便提下git format
            -patch -n , n是具體某個(gè)數(shù)字, 例如 'git format-patch -1' 這時(shí)便會(huì)根據(jù)log生成一個(gè)對(duì)應(yīng)的補(bǔ)丁,如果 'git format-patch -2' 那么便會(huì)生成2個(gè)補(bǔ)丁,當(dāng)然前提是你的log上有至少有兩個(gè)記錄。

            看過上面的信息,就可以知道使用場(chǎng)合了:當(dāng)前工作區(qū)內(nèi)容已被修改,但是并未完成。這時(shí)Boss來了,說前面的分支上面有一個(gè)Bug,需要立即修復(fù)。可是我又不想提交目前的修改,因?yàn)樾薷臎]有完成。但是,不提交的話,又沒有辦法checkout到前面的分支。此時(shí)用Git Stash就相當(dāng)于備份工作區(qū)了。然后在Checkout過去修改,就能夠達(dá)到保存當(dāng)前工作區(qū),并及時(shí)恢復(fù)的作用。

            下面,將我使用過程中遇到的一個(gè)問題和大家分享:

            首先,在Git Stash之后,提交圖如下所示:

            從圖中可以看到,develop和newdevelop是在同一個(gè)分支上,因?yàn)榉种ewdevelop是在develop分支的基礎(chǔ)上開發(fā)的。想加入一個(gè)新的特性,所以就開了newdevelop分支,然后就在上面加?xùn)|西,加特性,該代碼。這個(gè)時(shí)候工作的內(nèi)容已經(jīng)變化了,但是develop和newdevelop都是指向同一個(gè)提交的,因?yàn)閚ewdevelop上面還木有提交。
            這個(gè)時(shí)候,Boss來了,說develop上面有個(gè)Bug,趕快改一下,手頭的工作先放放,穩(wěn)定版本不能有缺陷。沒辦法,當(dāng)前正在newdevelop上搞的high呢,就Git Stash一下。所以會(huì)看到上面有兩個(gè)節(jié)點(diǎn),紅色以及上面一個(gè)。就是stash之后的結(jié)果,注意是在newdevelop上面進(jìn)行的stash。

            正如前面所說,stash會(huì)暫存當(dāng)前的工作區(qū)內(nèi)容,然后將工作區(qū)內(nèi)容保持和上次提交相同,此時(shí)內(nèi)容都是上面8a32那個(gè)提交的內(nèi)容。從終端中查看相應(yīng)的信息內(nèi)容,如下:

            印證了簽名的說法,newdevelop是有修改,modified,然后stash之后,工作區(qū)是最近一次提交,此時(shí)newdevelop和develop都是相同的,所以再git status查看發(fā)現(xiàn),都一樣,nothing to commit.

            然后Stash完成之后,就要Fix Bug了。為此,回到develop分支上進(jìn)行修復(fù),然后提交,完成后的提交圖如下所示:
            從途中可以看到,newdevelop還是在下面,因?yàn)橹赶虻氖抢系哪莻€(gè)8a32的commit。新的develop由于修復(fù)了Bug,所以產(chǎn)生一個(gè)新提交。


            然后在develop上面修復(fù)了Bug之后,在回到newdevelop上面進(jìn)行一個(gè)新的特性的繼續(xù)編碼,此時(shí)checkout回去的時(shí)候,沒有神馬內(nèi)容可以提交,因?yàn)槎即嬖赟tash中了,沒有任何修改。如上圖。

            那么,恢復(fù)工作區(qū)內(nèi)容吧。于是git stash pop(注意這里由于只Stash了一次所以使用pop,具體你存放了多少,要恢復(fù)哪一個(gè)要自己清楚,否則會(huì)出錯(cuò)!)

            恢復(fù)之后,從上圖中可以看到,此時(shí)再git status就會(huì)發(fā)現(xiàn)文件有修改,說明恢復(fù)過來了。然后就繼續(xù)編碼,提交一個(gè)穩(wěn)定的新特性版本,如下圖,產(chǎn)生的新提交為0906.
            然后再查看提交圖,會(huì)發(fā)現(xiàn),stash pop之后,對(duì)應(yīng)的存放的stash被清空掉了,提交圖中,newdevelop上面對(duì)應(yīng)一個(gè)新的提交。并且在develop上面。分支的develop那個(gè)紅色,即為前面修復(fù)Bug的那個(gè)提交。


            總結(jié)起來:
            操作很簡(jiǎn)單,但是頭腦要清楚。要在哪個(gè)分支上修復(fù)Bug,要暫存哪個(gè)地方的內(nèi)容,之后修復(fù)完了在那個(gè)地方提交,然后要到哪個(gè)分支上面恢復(fù)工作區(qū),都是需要注意的,否則,很容易造成提交圖混亂。只有弄清楚了工作流程,才不容易出錯(cuò),才能保證很高的工作效率。
            最后一句:Git是神器,就要看你如何駕馭它了。
            posted on 2011-11-13 00:36 deercoder 閱讀(300729) 評(píng)論(21)  編輯 收藏 引用 所屬分類: Git

            評(píng)論:
            # re: Git Stash用法 2011-11-13 07:44 | tjhaven
            千萬別用Stash。stash多了,你自己都記不得了。為什么不用branch?以后可以cherry-pick以前的commit。

            git我用了3年了,聽我的沒錯(cuò)。  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 09:28 | 劉暢
            @tjhaven
            額,謝謝~我是開的一個(gè)新的branch,但是新特性沒有完成的話不想提交,這個(gè)時(shí)候再開一個(gè)分支沒什么意義吧?難道你的意思是要提交一下?  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 10:10 | kkpattern
            神per,如果stash中的修改的文件和修復(fù)Bug是所修改的文件有交集,會(huì)怎么樣?
            比如我在新branch中修改了a.java;b.java
            然后我將新branch stash,修復(fù)Bug,修復(fù)過程中修改了a.java;c.java
            然后stash pop的過程中a.java會(huì)怎么修改?相當(dāng)于merge嗎?如果修改的內(nèi)容有沖突呢?  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 16:29 | 劉暢
            @kkpattern
            pop出來的內(nèi)容只是你上次stash時(shí)候的內(nèi)容,那個(gè)時(shí)候你還沒有修復(fù)這個(gè)Bug。所以a.java的內(nèi)容不會(huì)包含你修復(fù)那個(gè)Bug的內(nèi)容,此時(shí)要用cherry-pick來通過增量的方法將修復(fù)的內(nèi)容合并到新版本上,如果有沖突需要手動(dòng)解決。
            一般的,我認(rèn)為應(yīng)該是兩個(gè)版本,或者是不相干的分支內(nèi)容上工作。Stash的作用應(yīng)該只是減少不必要提交的作用。有交集的情況確實(shí)有些麻煩。  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 19:39 | 陳梓瀚(vczh)
            切換分支?多enlist幾個(gè)就好了,這是最簡(jiǎn)單的解決方法。反正硬盤那么大。  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 19:46 | 陳梓瀚(vczh)
            @陳梓瀚(vczh)
            一般來說我自己的代碼,在硬盤上都用同一個(gè)branch下載了兩份,當(dāng)我在某一份上面工作的時(shí)候,反正VisualStudio會(huì)自己找到正確的client,然后更新到最新,開始干活。然后你只要記得哪一份對(duì)應(yīng)哪一個(gè)任務(wù)就行了(win7有便箋,寫屏幕上即可)。git這個(gè)功能反而是很容易讓人類犯錯(cuò),不太好。

            這樣我的硬盤就有N個(gè)文件夾都對(duì)應(yīng)同一個(gè)branch,分別修改,分別commit,獨(dú)立sync latest。多方便。為什么一定要一個(gè)文件夾對(duì)應(yīng)一個(gè)branch呢?完全沒道理的。  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 19:58 | 劉暢
            @陳梓瀚(vczh)
            這種做法有違版本管理的初衷,很容易造成混亂。如果都選擇多個(gè)備份的話,那和直接進(jìn)行復(fù)制,粘貼,打上Tag信息有何區(qū)別?我認(rèn)為SVN,Git等版本管理工具的出現(xiàn),就是為了避免你這種做法。對(duì)于大型工程,這種方式我覺得很不可取。  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 21:05 | 陳梓瀚(vczh)
            @劉暢
            多個(gè)備份并不妨礙你進(jìn)行版本管理啊,你把自己當(dāng)成兩個(gè)人不就是了——兩個(gè)人開發(fā)總不能一起用同一份物理文件進(jìn)行開發(fā)的吧。  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 21:06 | 陳梓瀚(vczh)
            @劉暢
            有些時(shí)候大型工程才這樣的,之前工程有1000個(gè)人,平均同時(shí)有5000個(gè)任務(wù)在進(jìn)行,用版本管理工具。你認(rèn)為如何可以避免同時(shí)創(chuàng)建多個(gè)client……  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2011-11-13 21:11 | 劉暢
            @陳梓瀚(vczh)
            嗯,不過我還是覺得本機(jī)開發(fā)的話,如果有必要盡量減少備份個(gè)數(shù)。而且使用Stash也不會(huì)有多麻煩,其實(shí)不就是相當(dāng)于把你的那個(gè)內(nèi)容復(fù)制一份。所以我還是任務(wù)使用這個(gè)會(huì)比較好一點(diǎn)。只是用一個(gè)Tag來記錄你拷貝的位置而已。  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法[未登錄] 2011-12-26 09:53 | Loaden
            stash是一個(gè)很有用的命令!
            不會(huì)用stash,說明不會(huì)用git!  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2013-12-04 16:34 | marco
            @劉暢
            pop出來的內(nèi)容只是你上次stash時(shí)候的內(nèi)容,那個(gè)時(shí)候你還沒有修復(fù)這個(gè)Bug。所以a.java的內(nèi)容不會(huì)包含你修復(fù)那個(gè)Bug的內(nèi)容,此時(shí)要用cherry-pick來通過增量的方法將修復(fù)的內(nèi)容合并到新版本上,如果有沖突需要手動(dòng)解決。

            會(huì)包含.如果沖突了.會(huì)提示一個(gè)merge.需要手動(dòng)解決...  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法[未登錄] 2014-02-08 10:59 | k
            @tjhaven
            好意思說自己用了三年git.毫無長(zhǎng)進(jìn)吧  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法[未登錄] 2014-03-12 14:33 | snowball
            針對(duì)你的example提個(gè)問題
            如果僅僅是在develop上進(jìn)行bug fix,那么在newdevelop上進(jìn)行g(shù)it stash的意義又何在呢?  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2014-04-02 09:47 | conquer
            非常好用,并且樓主說的很清楚,為什么有那么多人不理解呢……  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2014-07-24 14:37 | 果殼
            @snowball
            你不commit或者stash能切換分支?  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法[未登錄] 2014-08-09 02:50 | Leon
            請(qǐng)問下樓主,在Develop上的bug fix,如何體現(xiàn)在new develop上呢?
            如果是簡(jiǎn)單的還好,如果復(fù)雜的話,總不能在new develop上重做一遍吧...  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2014-08-20 15:27 | mini
            # re: Git Stash用法 2014-08-23 09:42 | caostorm
            @marco
            stash的話一定是基于某個(gè)版本的,而且將stash從棧內(nèi)拿出來,一定是需要還原到對(duì)應(yīng)的版本。通過git stash list可以清晰的看到每個(gè)stash對(duì)應(yīng)的版本,如:
            stash@{0}: WIP on master: e95dc37 Require administrator authority...
            stash@{1}: WIP on md_develop: fcaa18f Add an object to recieve md...
            比如你需要恢復(fù)stash@{1}這時(shí)候你需要做的是:
            git checkout fcaa18f
            git stash apply stash@{1}
            盡量不使用類似git stash pop的方法。如果你當(dāng)前fcaa18f所在的分支有繼續(xù)往前推進(jìn)的話,建議在fcaa18f上建立新的分支,然后繼續(xù)stash@{1}的修改,并將stash@{1}的內(nèi)容提交到新的分支上:
            git branch new_develop
            git checkout new_develop
            git add FILES
            git commit
            后續(xù)再通過cherry-pick的方式,將修改的內(nèi)容應(yīng)用到其他需要這個(gè)修改的分支之上。  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法 2016-08-15 15:56 | doubi
            @Loaden
            這個(gè)B裝的好  回復(fù)  更多評(píng)論
              
            # re: Git Stash用法[未登錄] 2016-08-22 17:25 | q
            @陳梓瀚(vczh)
            人稱輪帶逛!!!  回復(fù)  更多評(píng)論
              
            国产一久久香蕉国产线看观看| 日本精品一区二区久久久| 三级片免费观看久久| 久久国产成人| 无码任你躁久久久久久老妇App| 亚洲欧洲精品成人久久曰影片| 麻豆精品久久久久久久99蜜桃 | 久久精品中文字幕有码| 国产AV影片久久久久久| 性高朝久久久久久久久久| 久久这里只有精品18| 国产成人99久久亚洲综合精品| 一本色道久久88综合日韩精品 | 亚洲午夜精品久久久久久人妖| 久久久久一本毛久久久| 国产毛片欧美毛片久久久| 色偷偷888欧美精品久久久| 97视频久久久| 精品无码久久久久久久动漫| 亚洲AV日韩AV永久无码久久| 久久久久国产一区二区三区| 国产精品久久久久影院色 | 国产午夜久久影院| 久久久久99这里有精品10| 久久综合亚洲色一区二区三区| 国产午夜精品理论片久久影视| 伊人久久大香线蕉综合Av | 日本一区精品久久久久影院| 精品久久久久久久久免费影院| 国产成人香蕉久久久久| 国产精品久久亚洲不卡动漫| 午夜不卡久久精品无码免费| 狠狠色丁香婷婷久久综合 | 国产精品久久久久久久人人看 | 久久精品aⅴ无码中文字字幕不卡| 日日狠狠久久偷偷色综合96蜜桃| 久久精品国产一区二区三区| 久久精品国产福利国产琪琪| 久久久久亚洲av成人无码电影| 久久国产成人午夜AV影院| 综合久久精品色|