8月總票房已突破10億！《封神》第一：口碑已經(jīng)成了
8月5日消息，據(jù)燈塔專業(yè)版數(shù)據(jù)，截至8月5日9時(shí)35分，8月總票房（含預(yù)售）已突破10億。其中，《封神》以大比分的優(yōu)勢(shì)領(lǐng)先。根據(jù)官方消息，目前該片總票房已經(jīng)超過(guò)14.
使用 Git 作為代碼版本管理，早已是現(xiàn)在開(kāi)發(fā)工程師必備的技能。可大多數(shù)工程師還是只會(huì)最基本的保存、拉取、推送，遇到一些commit管理的問(wèn)題就束手無(wú)策，或者用一些不優(yōu)雅的方式解決。
本文分享我在開(kāi)發(fā)工作中實(shí)踐過(guò)的實(shí)用命令。這些都能夠大大提高工作效率，還能解決不少疑難場(chǎng)景。下面會(huì)介紹命令，列出應(yīng)用場(chǎng)景，手摸手教學(xué)使用，讓同學(xué)們看完即學(xué)會(huì)。
官方解釋：當(dāng)您想記錄工作目錄和索引的當(dāng)前狀態(tài)，但又想返回一個(gè)干凈的工作目錄時(shí)，請(qǐng)使用git stash。該命令將保存本地修改，并恢復(fù)工作目錄以匹配頭部提交。
stash 命令能夠?qū)⑦€未 commit 的代碼存起來(lái)，讓你的工作目錄變得干凈。
我猜你心里一定在想：為什么要變干凈？
應(yīng)用場(chǎng)景：某一天你正在 feature 分支開(kāi)發(fā)新需求，突然產(chǎn)品經(jīng)理跑過(guò)來(lái)說(shuō)線上有bug，必須馬上修復(fù)。而此時(shí)你的功能開(kāi)發(fā)到一半，于是你急忙想切到 master 分支，然后你就會(huì)看到以下報(bào)錯(cuò)：
圖片
因?yàn)楫?dāng)前有文件更改了，需要提交commit保持工作區(qū)干凈才能切分支。由于情況緊急，你只有急忙 commit 上去，commit 信息也隨便寫(xiě)了個(gè)“暫存代碼”，于是該分支提交記錄就留了一條黑歷史…(真人真事，看過(guò)這種提交)
如果你學(xué)會(huì) stash，就不用那么狼狽了。你只需要：
git stash就這么簡(jiǎn)單，代碼就被存起來(lái)了。
當(dāng)你修復(fù)完線上問(wèn)題，切回 feature 分支，想恢復(fù)代碼也只需要：
git stash apply# 保存當(dāng)前未commit的代碼git stash# 保存當(dāng)前未commit的代碼并添加備注git stash save "備注的內(nèi)容"# 列出stash的所有記錄git stash list# 刪除stash的所有記錄git stash clear# 應(yīng)用最近一次的stashgit stash apply# 應(yīng)用最近一次的stash，隨后刪除該記錄git stash pop# 刪除最近的一次stashgit stash drop當(dāng)有多條 stash，可以指定操作stash，首先使用stash list 列出所有記錄：
$ git stash liststash@{0}: WIP on ...stash@{1}: WIP on ...stash@{2}: On ...應(yīng)用第二條記錄：
$ git stash apply stash@{1}pop，drop 同理。
stash 代碼：
圖片
填寫(xiě)備注內(nèi)容，也可以不填直接Enter：
圖片
在STASHES菜單中可以看到保存的stash：
圖片
先點(diǎn)擊stash記錄旁的小箭頭，再點(diǎn)擊 apply 或者 pop 都可恢復(fù) stash：
圖片
完全不接觸索引文件或工作樹(shù)（但會(huì)像所有模式一樣，將頭部重置為）。這使您的所有更改的文件更改為“要提交的更改”。
回退你已提交的 commit，并將 commit 的修改內(nèi)容放回到暫存區(qū)。
一般我們?cè)谑褂?reset 命令時(shí)，git reset --hard會(huì)被提及的比較多，它能讓 commit 記錄強(qiáng)制回溯到某一個(gè)節(jié)點(diǎn)。而git reset --soft的作用正如其名，--soft(柔軟的) 除了回溯節(jié)點(diǎn)外，還會(huì)保留節(jié)點(diǎn)的修改內(nèi)容。
回溯節(jié)點(diǎn)，為什么要保留修改內(nèi)容？
應(yīng)用場(chǎng)景1：有時(shí)候手滑不小心把不該提交的內(nèi)容 commit 了，這時(shí)想改回來(lái)，只能再 commit 一次，又多一條“黑歷史”。
應(yīng)用場(chǎng)景2：規(guī)范些的團(tuán)隊(duì)，一般對(duì)于 commit 的內(nèi)容要求職責(zé)明確，顆粒度要細(xì)，便于后續(xù)出現(xiàn)問(wèn)題排查。本來(lái)屬于兩塊不同功能的修改，一起 commit 上去，這種就屬于不規(guī)范。這次恰好又手滑了，一次性 commit 上去。
學(xué)會(huì)reset --soft之后，你只需要：
# 恢復(fù)最近一次 commitgit reset --soft HEAD^reset --soft相當(dāng)于后悔藥，給你重新改過(guò)的機(jī)會(huì)。對(duì)于上面的場(chǎng)景，就可以再次修改重新提交，保持干凈的 commit 記錄。
以上說(shuō)的是還未 push 的commit。對(duì)于已經(jīng) push 的 commit，也可以使用該命令，不過(guò)再次 push 時(shí)，由于遠(yuǎn)程分支和本地分支有差異，需要強(qiáng)制推送git push -f來(lái)覆蓋被 reset 的 commit。
還有一點(diǎn)需要注意，在reset --soft指定 commit 號(hào)時(shí)，會(huì)將該 commit 到最近一次 commit 的所有修改內(nèi)容全部恢復(fù)，而不是只針對(duì)該 commit。
舉個(gè)例子：
commit 記錄有 c、b、a。
圖片
reset 到 a。
git reset --soft 1a900ac29eba73ce817bf959f82ffcb0bfa38f75此時(shí)的 HEAD 到了 a，而 b、c 的修改內(nèi)容都回到了暫存區(qū)。
圖片
給定一個(gè)或多個(gè)現(xiàn)有提交，應(yīng)用每個(gè)提交引入的更改，為每個(gè)提交記錄一個(gè)新的提交。這需要您的工作樹(shù)清潔（沒(méi)有從頭提交的修改）。
將已經(jīng)提交的 commit，復(fù)制出新的 commit 應(yīng)用到分支里
commit 都提交了，為什么還要復(fù)制新的出來(lái)？
應(yīng)用場(chǎng)景1：有時(shí)候版本的一些優(yōu)化需求開(kāi)發(fā)到一半，可能其中某一個(gè)開(kāi)發(fā)完的需求要臨時(shí)上，或者某些原因?qū)е麓_(kāi)發(fā)的需求卡住了已開(kāi)發(fā)完成的需求上線。這時(shí)候就需要把 commit 抽出來(lái)，單獨(dú)處理。
應(yīng)用場(chǎng)景2：有時(shí)候開(kāi)發(fā)分支中的代碼記錄被污染了，導(dǎo)致開(kāi)發(fā)分支合到線上分支有問(wèn)題，這時(shí)就需要拉一條干凈的開(kāi)發(fā)分支，再?gòu)呐f的開(kāi)發(fā)分支中，把 commit 復(fù)制到新分支。
現(xiàn)在有一條feature分支，commit 記錄如下：
圖片
需要把 b 復(fù)制到另一個(gè)分支，首先把 commitHash 復(fù)制下來(lái)，然后切到 master 分支。
圖片
當(dāng)前 master 最新的記錄是 a，使用cherry-pick把 b 應(yīng)用到當(dāng)前分支。
圖片
完成后看下最新的 log，b 已經(jīng)應(yīng)用到 master，作為最新的 commit 了。可以看到 commitHash 和之前的不一樣，但是提交時(shí)間還是保留之前的。
以上是單個(gè) commit 的復(fù)制，下面再來(lái)看看 cherry-pick 多個(gè) commit 要如何操作。
git cherry-pick commit1 commit2上面的命令將 commit1 和 commit2 兩個(gè)提交應(yīng)用到當(dāng)前分支。
git cherry-pick commit1^..commit2上面的命令將 commit1 到 commit2 這個(gè)區(qū)間的 commit 都應(yīng)用到當(dāng)前分支（包含commit1、commit2），commit1 是最早的提交。
在cherry-pick多個(gè)commit時(shí)，可能會(huì)遇到代碼沖突，這時(shí)cherry-pick會(huì)停下來(lái)，讓用戶決定如何繼續(xù)操作。下面看看怎么解決這種場(chǎng)景。
圖片
還是 feature 分支，現(xiàn)在需要把 c、d、e 都復(fù)制到 master 分支上。先把起點(diǎn)c和終點(diǎn)e的 commitHash 記下來(lái)。
圖片
切到 master 分支，使用區(qū)間的cherry-pick。可以看到 c 被成功復(fù)制，當(dāng)進(jìn)行到 d 時(shí)，發(fā)現(xiàn)代碼沖突，cherry-pick中斷了。這時(shí)需要解決代碼沖突，重新提交到暫存區(qū)。
圖片
然后使用cherry-pick --continue讓cherry-pick繼續(xù)進(jìn)行下去。最后 e 也被復(fù)制進(jìn)來(lái)，整個(gè)流程就完成了。
以上是完整的流程，但有時(shí)候可能需要在代碼沖突后，放棄或者退出流程：
git cherry-pick --abort回到操作前的樣子，就像什么都沒(méi)發(fā)生過(guò)。
git cherry-pick --quit不回到操作前的樣子。即保留已經(jīng)cherry-pick成功的 commit，并退出cherry-pick流程。
給定一個(gè)或多個(gè)現(xiàn)有提交，恢復(fù)相關(guān)提交引入的更改，并記錄一些這些更改的新提交。這就要求你的工作樹(shù)是干凈的（沒(méi)有來(lái)自頭部的修改）。
將現(xiàn)有的提交還原，恢復(fù)提交的內(nèi)容，并生成一條還原記錄。
應(yīng)用場(chǎng)景：有一天測(cè)試突然跟你說(shuō)，你開(kāi)發(fā)上線的功能有問(wèn)題，需要馬上撤回，否則會(huì)影響到系統(tǒng)使用。這時(shí)可能會(huì)想到用 reset 回退，可是你看了看分支上最新的提交還有其他同事的代碼，用 reset 會(huì)把這部分代碼也撤回了。由于情況緊急，又想不到好方法，還是任性的使用 reset，然后再讓同事把他的代碼合一遍（同事聽(tīng)到想打人），于是你的技術(shù)形象在同事眼里一落千丈。
學(xué)會(huì) revert 之后，立馬就可以拯救這種尷尬的情況。
現(xiàn)在 master 記錄如下：
圖片
git revert 21dcd937fe555f58841b17466a99118deb489212revert 掉自己提交的 commit。
圖片
因?yàn)?revert 會(huì)生成一條新的提交記錄，這時(shí)會(huì)讓你編輯提交信息，編輯完后 :wq 保存退出就好了。
圖片
再來(lái)看下最新的 log，生成了一條 revert 記錄，雖然自己之前的提交記錄還是會(huì)保留著，但你修改的代碼內(nèi)容已經(jīng)被撤回了。
在 git 的 commit 記錄里，還有一種類型是合并提交，想要 revert 合并提交，使用上會(huì)有些不一樣。
圖片
現(xiàn)在的 master 分支里多了條合并提交。
圖片
使用剛剛同樣的 revert 方法，會(huì)發(fā)現(xiàn)命令行報(bào)錯(cuò)了。為什么會(huì)這樣？在官方文檔中有解釋。
通常無(wú)法 revert 合并，因?yàn)槟恢篮喜⒌哪囊粋?cè)應(yīng)被視為主線。此選項(xiàng)指定主線的父編號(hào)（從1開(kāi)始），并允許 revert 反轉(zhuǎn)相對(duì)于指定父編號(hào)的更改
我的理解是因?yàn)楹喜⑻峤皇莾蓷l分支的交集節(jié)點(diǎn)，而 git 不知道需要撤銷(xiāo)的哪一條分支，需要添加參數(shù) -m 指定主線分支，保留主線分支的代碼，另一條則被撤銷(xiāo)。
-m 后面要跟一個(gè) parent number 標(biāo)識(shí)出"主線"，一般使用 1 保留主分支代碼。
git revert -m 1 <commitHash>還是上面的場(chǎng)景，在 master 分支 revert 合并提交后，然后切到 feature 分支修復(fù)好 bug，再合并到 master 分支時(shí)，會(huì)發(fā)現(xiàn)之前被 revert 的修改內(nèi)容沒(méi)有重新合并進(jìn)來(lái)。
因?yàn)槭褂?revert 后， feature 分支的 commit 還是會(huì)保留在 master 分支的記錄中，當(dāng)你再次合并進(jìn)去時(shí)，git 判斷有相同的 commitHash，就忽略了相關(guān) commit 修改的內(nèi)容。
這時(shí)就需要 revert 掉之前 revert 的合并提交，有點(diǎn)拗口，接下來(lái)看操作吧。
圖片
現(xiàn)在 master 的記錄是這樣的。
圖片
再次使用 revert，之前被 revert 的修改內(nèi)容就又回來(lái)了。
此命令管理重錄中記錄的信息。
如果說(shuō)reset --soft是后悔藥，那 reflog 就是強(qiáng)力后悔藥。它記錄了所有的 commit 操作記錄，便于錯(cuò)誤操作后找回記錄。
應(yīng)用場(chǎng)景：某天你眼花，發(fā)現(xiàn)自己在其他人分支提交了代碼還推到遠(yuǎn)程分支，這時(shí)因?yàn)榉种е挥心愕淖钚绿峤唬拖胫褂胷eset --hard，結(jié)果緊張不小心記錯(cuò)了 commitHash，reset 過(guò)頭，把同事的 commit 搞沒(méi)了。沒(méi)辦法，reset --hard是強(qiáng)制回退的，找不到 commitHash 了，只能讓同事從本地分支再推一次（同事瞬間拳頭就硬了，怎么又是你）。于是，你的技術(shù)形象又一落千丈。
圖片
分支記錄如上，想要 reset 到 b。
圖片
誤操作 reset 過(guò)頭，b 沒(méi)了，最新的只剩下 a。
圖片
這時(shí)用git reflog查看歷史記錄，把錯(cuò)誤提交的那次 commitHash 記下。
圖片
再次 reset 回去，就會(huì)發(fā)現(xiàn) b 回來(lái)了。
對(duì)我這種喜歡敲命令而不用圖形化工具的愛(ài)好者來(lái)說(shuō)，設(shè)置短命令可以很好的提高效率。下面介紹兩種設(shè)置短命令的方式。
git config --global alias.ps push打開(kāi)全局配置文件
vim ~/.gitconfig寫(xiě)入內(nèi)容
[alias] co = checkout ps = push pl = pull mer = merge --no-ff cp = cherry-pick# 等同于 git cherry-pick <commitHash>git cp <commitHash>本文主要分享了5個(gè)在開(kāi)發(fā)中實(shí)用的 Git 命令和設(shè)置短命令的方式。
文中列舉的應(yīng)用場(chǎng)景有部分不太恰當(dāng)，只是想便于同學(xué)們理解，最重要的是要理解命令的作用是什么，活學(xué)活用才能發(fā)揮最大功效。
本文鏈接：http://www.www897cc.com/showinfo-26-91378-0.htmlGit 不要只會(huì) Pull 和 Push，這五條提高效率的命令得掌握！
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)