艾銻知識(shí) | 如何用 Git 回退代碼

2020-02-18 16:01 作者：admin 瀏覽量：

 
這幾天如果大家關(guān)注疫情數(shù)據(jù)的變化，可以看到新增確診病例在持續(xù)下降，這意味著疫情很快就會(huì)結(jié)束，大家再也不用在家辦公了，到不是在家工作有什么不好，但人類發(fā)明工作不簡(jiǎn)簡(jiǎn)單單只是為了實(shí)現(xiàn)結(jié)果的達(dá)成，還有一個(gè)非常重要的因素就是人與人之間的聯(lián)結(jié)，這是人類內(nèi)在價(jià)值的需求，透過(guò)工作與人接觸，共同感受彼此的能量流動(dòng)，從而達(dá)到自我價(jià)值的實(shí)現(xiàn)，這就像演員都渴望登上奧斯卡的舞臺(tái)，來(lái)實(shí)現(xiàn)自我角色的認(rèn)可一樣。
 
 
在家辦公，畢竟是家，松、散、懶以及無(wú)所謂的態(tài)度會(huì)隨時(shí)產(chǎn)生，我相信不是每個(gè)人都會(huì)這樣，但大部分人會(huì)如此，因?yàn)榧冶緛?lái)就是放松的能量場(chǎng)，接下來(lái)大家即將回到公司，回到自己的工作崗位，難免會(huì)把在家的狀態(tài)帶入工作中，如果每個(gè)人都是這樣的狀態(tài)，企業(yè)很快會(huì)陷入新的窘境，所以沒(méi)有狀態(tài)，也不會(huì)有好的結(jié)果，狀態(tài)就是一切。
 
團(tuán)隊(duì)的勢(shì)氣決定企業(yè)整體的戰(zhàn)斗力，那如何調(diào)整陸陸續(xù)續(xù)回來(lái)的團(tuán)隊(duì)成員呢？
 
   
艾銻無(wú)限對(duì)中小企業(yè)有三條建議：
 
第一，重新梳理整個(gè)企業(yè)的戰(zhàn)略，疫情的發(fā)生，是否給你企業(yè)帶來(lái)了變化？如果有那是什么？是否需要調(diào)整自己原有的戰(zhàn)略方向來(lái)應(yīng)對(duì)疫情發(fā)生后的影響？
 
第二，重新明確每個(gè)人的目標(biāo)和目的，目標(biāo)就是重回企業(yè)的人要干什么？干到什么程度？什么時(shí)間可以看到這個(gè)結(jié)果的發(fā)生？目的就是為什么要實(shí)現(xiàn)這個(gè)目標(biāo)？這個(gè)目標(biāo)與自己的意義是什么？與企業(yè)的意義又是什么？達(dá)成了會(huì)怎么樣？達(dá)不成又會(huì)怎么樣？
 
只有清晰這些問(wèn)題，才會(huì)讓回到工作崗位的人快速改變自己的狀態(tài)投入到接下來(lái)的工作中，只有積極的狀態(tài)投入工作才會(huì)有積極的成果發(fā)生，反之依然。
 
第三，企業(yè)高管與員工建立一對(duì)一的對(duì)話機(jī)制，因疫情的影響，每個(gè)人心理或多或少都會(huì)產(chǎn)生一些內(nèi)在的變化，作為企業(yè)的高層管理人員，最好與企業(yè)內(nèi)部員工一對(duì)一的進(jìn)行溝通，去了解在這個(gè)過(guò)程中員工受到的影響和產(chǎn)生的變化，以便接下來(lái)更好的調(diào)整他們的狀態(tài)，因?yàn)槿绻麄兊男臎](méi)有回來(lái)，企業(yè)的要求和制度帶來(lái)的也都是大家沒(méi)有能量的重復(fù)和機(jī)械的工作，最終也很難帶來(lái)好的結(jié)果。
 
以上三點(diǎn)是企業(yè)管理者需要重視的，當(dāng)然身為企業(yè)的一員無(wú)論是誰(shuí)也都需要重新審視自己的狀態(tài)，因?yàn)檫@關(guān)系著企業(yè)接下來(lái)的生、死、存、亡，能量是企業(yè)持續(xù)發(fā)展的源泉，以上所有的目的都是為了聚合企業(yè)人的能量，重新點(diǎn)燃大家面對(duì)工作的激情和信心，這將是企業(yè)至勝的法定。
 
當(dāng)然這只是我們一家之言，每家企業(yè)可根據(jù)自身的情況做出相應(yīng)的調(diào)整和改變。
 
以上三點(diǎn)做為每一家企業(yè)的管理者都有必要重視起來(lái)，因?yàn)檫@關(guān)系著企業(yè)接下來(lái)的生、死、存、亡，當(dāng)然這只是我們一家之言，可根據(jù)自身的情況做出相應(yīng)的調(diào)整和改變。
 
那為什么我們會(huì)有這樣的思考，因?yàn)榘R無(wú)限是一家企業(yè)互聯(lián)網(wǎng)”云”解決方案服務(wù)平臺(tái)，企業(yè)在初創(chuàng)時(shí)經(jīng)歷了2003年的非典，后來(lái)又經(jīng)歷了2008年的經(jīng)濟(jì)危機(jī)以及2016年互聯(lián)網(wǎng)創(chuàng)業(yè)大潮，生生死死，幾經(jīng)沉浮，最終發(fā)現(xiàn)上述三點(diǎn)是生死線中最重要的，所以愿意分享給大家，期望這次疫情大家不僅能渡過(guò)難關(guān)，更能看見(jiàn)大家在這個(gè)過(guò)程中強(qiáng)而有力的領(lǐng)導(dǎo)力，讓自己企業(yè)力挽狂瀾，讓自己的工作更上一層樓，讓自己的生活在2020年更精彩。
 
在這次疫情后各個(gè)企業(yè)恢復(fù)的過(guò)程中，艾銻無(wú)限還能為大家做的就是免費(fèi)為中小企業(yè)提供相應(yīng)的IT服務(wù)，以下是艾銻無(wú)限可以提供服務(wù)的內(nèi)容，如果大家有相應(yīng)的需求，可以打下面的電話與我們的企業(yè)相關(guān)人員聯(lián)系，我們一定會(huì)盡全力幫助大家渡過(guò)難關(guān)。
 
 
歷經(jīng)10幾年,艾銻無(wú)限服務(wù)了5000多家中小企業(yè)并保障了幾十萬(wàn)臺(tái)設(shè)備的正常運(yùn)轉(zhuǎn)，積累了豐富的企業(yè)IT緊急問(wèn)題和特殊故障的解決方案，我們?yōu)槟钠髽I(yè)提供的IT服務(wù)分為三大版塊:
 
第一版塊是保障性IT外包服務(wù):如電腦設(shè)備運(yùn)維，辦公設(shè)備運(yùn)維，網(wǎng)絡(luò)設(shè)備運(yùn)維，服務(wù)器運(yùn)維等綜合性企業(yè)IT設(shè)備運(yùn)維服務(wù)。
 
第二版塊是功能性互聯(lián)網(wǎng)外包服務(wù):如網(wǎng)站開(kāi)發(fā)外包，小程序開(kāi)發(fā)外包，APP開(kāi)發(fā)外包，電商平臺(tái)開(kāi)發(fā)外包，業(yè)務(wù)系統(tǒng)的開(kāi)發(fā)外包和后期的運(yùn)維外包服務(wù)。
 
第三版塊是增值性云服務(wù)外包:如企業(yè)郵箱上云，企業(yè)網(wǎng)站上云，企業(yè)存儲(chǔ)上云，企業(yè)APP小程序上云，企業(yè)業(yè)務(wù)系統(tǒng)上云，阿里云產(chǎn)品等后續(xù)的云運(yùn)維外包服務(wù)。
 
更多服務(wù)也可以登錄艾銻無(wú)限的官網(wǎng): www.bjitwx.com 查看詳細(xì)說(shuō)明。

每家企業(yè)都有著不同的人，每個(gè)人都有著不一樣的思考，所以企業(yè)不需要統(tǒng)一所有人的思維，企業(yè)只需要統(tǒng)一所有人的心，因?yàn)橹灰脑谝黄鹆耍芰烤蜁?huì)合一，能量合一企業(yè)將無(wú)所不能。
 
相信這次疫情帶給中國(guó)企業(yè)的不僅僅是災(zāi)難，更有可能的是歷練，這幾年經(jīng)濟(jì)發(fā)展如此快速，大部分中小企業(yè)的成長(zhǎng)都是隨著國(guó)家政策及整個(gè)社會(huì)的大勢(shì)起來(lái)的，沒(méi)有經(jīng)過(guò)太多的挑戰(zhàn)和困難，所以存活周期也會(huì)很短，從2016年大眾創(chuàng)業(yè)，萬(wàn)眾創(chuàng)新倡導(dǎo)下成立了上千萬(wàn)家企業(yè)，但真正存活下來(lái)的就只有幾萬(wàn)家，這樣的結(jié)果即不能給國(guó)家?guī)?lái)穩(wěn)定持續(xù)發(fā)展的動(dòng)力，也不能為社會(huì)創(chuàng)造更大的價(jià)值，反而讓更多的人投機(jī)取巧，心浮氣躁，沉不下來(lái)真正把一件事做好，做到極致。
 
所以這次疫情也會(huì)讓大部分企業(yè)重新思考，問(wèn)問(wèn)自己，為什么要?jiǎng)?chuàng)立這家企業(yè)，想為這個(gè)國(guó)家和社會(huì)帶來(lái)的是什么？企業(yè)真正在創(chuàng)造的是什么？如何做才能讓社會(huì)因自己的企業(yè)變得更好？.....
 
當(dāng)企業(yè)真正去思考，用心去創(chuàng)造價(jià)值的時(shí)候，也就是人們幸福快樂(lè)的時(shí)候，因?yàn)樵僖膊挥脫?dān)心假貨、次貨、買到不好的產(chǎn)品，更不用擔(dān)心環(huán)境被污染，大氣被破壞，疫情即是一場(chǎng)災(zāi)難，又是重新成就中國(guó)企業(yè)的一次機(jī)會(huì)，讓全世界人覺(jué)醒，生命只有一次，我們要如何做才能不枉此生呢？
 
 
你對(duì)世界微笑，世界絕不會(huì)對(duì)你哭，希望大家都能積極樂(lè)觀起來(lái)，讓自己、自己的家人、自己的企業(yè)、還有自己的國(guó)家都快樂(lè)起來(lái)，把焦點(diǎn)、意識(shí)、能量放在我們想要什么上，而不是不要的事情上，我相信，就在不久的將來(lái)，我們一定會(huì)看到一個(gè)富強(qiáng)、文明、健康的中國(guó)以及一個(gè)和諧友愛(ài)的世界。
 
萬(wàn)物同體，能量合一，最后無(wú)論你是中小企業(yè)，還是大型國(guó)有企業(yè)，只要你選擇艾銻無(wú)限，我們就一定全力以赴幫助大家渡過(guò)難關(guān)，服務(wù)有限，信息無(wú)限，透過(guò)全體艾銻人的努力，為您收集最有效的IT技術(shù)信息，讓您企業(yè)更快速解決遇到的IT問(wèn)題：
 

艾銻知識(shí) | 如何用 Git 回退代碼

從接觸編程就開(kāi)始使用 Git 進(jìn)行代碼管理，先是自己玩 Github，又在工作中使用 Gitlab，雖然使用時(shí)間挺長(zhǎng)，可是也只進(jìn)行一些常用操作，如推拉代碼、提交、合并等，前些天就遇到了 Git 里一種十分糟心的場(chǎng)景，并為之前沒(méi)有深入理解 Git 命令付出了一下午時(shí)間的代價(jià)。先介紹一下這種場(chǎng)景，我們一個(gè)項(xiàng)目從 N 版本升到 A 版本時(shí)引入了另一項(xiàng)目的 jar 包，又陸續(xù)發(fā)布了 B、C 版本但在 C 版本后忽然發(fā)現(xiàn)了 A 版本引入的 jar 包有極大的性能問(wèn)題，B、C 版本都是基于 A 版本發(fā)布的，要修復(fù) jar 包性能問(wèn)題，等 jar 包再發(fā)版還得幾天，可此時(shí)線上又有緊急的 Bug 要修，于是就陷入了進(jìn)退兩難的境地。最后決定先將代碼回退到 A 版本之前，再基于舊版本修復(fù) Bug，也就開(kāi)始了五個(gè)小時(shí)的受苦之路。 revert
首先肯定的是 revert，git revert commit_id 能產(chǎn)生一個(gè) 與 commit_id 完全相反的提交，即 commit_id 里是添加， revert 提交里就是刪除。但是使用 git log 查看了提交記錄后，我就打消了這種想法，因?yàn)樘峤淮螖?shù)太多了，中途還有幾次從其他分支的 merge 操作。”利益于”我們不太干凈的提交記錄，要完成從 C 版本到 N 版本的 revert，我需要倒序執(zhí)行 revert 操作幾十次，如果其中順序錯(cuò)了一次，最終結(jié)果可能就是不對(duì)的。另外我們知道我們?cè)谶M(jìn)行代碼 merge 時(shí)，也會(huì)把 merge 信息產(chǎn)生一次新的提交，而 revert 這次 merge commit 時(shí)需要指定 m 參數(shù)，以指定 mainline這個(gè) mainline 是主線，也是我們要保留代碼的主分支，從 feature 分支往 develop 分支合并，或由 develop 分支合并到 master 的提交還好確定，但 feature 分支互相合并時(shí)，我哪知道哪個(gè)是主線啊。所以 revert 的文案被廢棄了。
 
Reset
然后就考慮 reset 了， reset 也能使代碼回到某次提交，但跟 revert 不同的是， reset 是將提交的 HEAD 指針指到某次提交，之后的提交記錄會(huì)消失，就像從沒(méi)有過(guò)這么一次提交。但由于我們都在 feature 分支開(kāi)發(fā)，我在 feature 分支上將代碼回退到某次提交后，將其合并到 develop 分支時(shí)卻被提示報(bào)錯(cuò)。這是因?yàn)?feature 分支回退了提交后，在 git 的 workflow 里，feature 分支是落后于 develop 分支的而合并向 develop 分支，又需要和 develop 分支保持最新的同步，需要將 develop 分支的數(shù)據(jù)合并到 feature 分支上，而合并后，原來(lái)被 reset 的代碼又回來(lái)了。
這個(gè)時(shí)候另一個(gè)可選項(xiàng)是在 master 分支上執(zhí)行 reset，使用 --hard 選項(xiàng)完全拋棄這些舊代碼，reset 后再?gòu)?qiáng)制推到遠(yuǎn)端。
master> git reset --hard commit_id
master> git push --force origin master
 
但是還是有問(wèn)題，首先，我們的 master 分支在 gitlab 里是被保護(hù)的，不能使用 force push，畢竟風(fēng)險(xiǎn)挺大了，萬(wàn)一有人 reset 到最開(kāi)始的提交再?gòu)?qiáng)制 push 的話，雖然可以使用 reflog 恢復(fù)，但也是一番折騰。
另外，reset 畢竟太野蠻，我們還是想能保留提交歷史，以后排查問(wèn)題也可以參考。
 
rebase
只好用搜索引擎繼續(xù)搜索，看到有人提出可以先使用 rebase 把多個(gè)提交合并成一個(gè)提交，再使用 revert 產(chǎn)生一次反提交，這種方法的思路非常清晰，把 revert 和 rebase 兩個(gè)命令搭配得很好，相當(dāng)于使用 revert 回退的升級(jí)版。
先說(shuō)一下 rebase，rebase 是”變基”的意思，這里的”基”，在我理解是指[多次] commit 形成的 git workflow，使用 rebase，我們可以改變這些歷史提交，修改 commit 信息，將多個(gè) commit 進(jìn)行組合。
介紹 rebase 的文檔有很多，我們直接來(lái)說(shuō)用它來(lái)進(jìn)行代碼回退的步驟。
1、首先，切出一個(gè)新分支 F，使用 git log 查詢一下要回退到的 commit 版本 N。
2、使用命令 git rebase -i N， -i 指定交互模式后，會(huì)打開(kāi) git rebase 編輯界面，形如：
pick 6fa5869 commit1
pick 0b84ee7 commit2
pick 986c6c8 commit3
pick 91a0dcc commit4
3、這些 commit 自舊到新由上而下排列，我們只需要在 commit_id 前添加操作命令即可。在合并 commit 這個(gè)需求里，我們可以選擇 pick(p) 最舊的 commit1，然后在后續(xù)的 commit_id 前添加 squash(s) 命令，將這些 commits 都合并到最舊的 commit1 上。4、保存 rebase 結(jié)果后，再編輯 commit 信息，使這次 rebase 失效，git 會(huì)將之前的這些 commit 都刪除，并將其更改合并為一個(gè)新的 commit5。如果出錯(cuò)了，也可以使用 git rebase --abort/--continue/--edit-todo 對(duì)之前的編輯進(jìn)行撤銷、繼續(xù)編輯。5、這個(gè)時(shí)候，主分支上的提交記錄是 older, commit1, commit2, commit3, commit4，而 F 分支上的提交記錄是 older, commit5，由于 F 分支的祖先節(jié)點(diǎn)是 older，明顯落后于主分支的 commit4，將 F 分支向主分支合并是不允許的。所以我們需要執(zhí)行 git merge master 將主分支向 F 分支合并，合并后 git 會(huì)發(fā)現(xiàn) commit1 到 commit4 提交的內(nèi)容和 F 分支上 commit5 的修改內(nèi)容是完全相同的，會(huì)自動(dòng)進(jìn)行合并，內(nèi)容不變，但多了一個(gè) commit5。6、再在 F 分支上對(duì) commit5 進(jìn)行一次 revert 反提交，就實(shí)現(xiàn)了把 commit1 到 commit4 的提交全部回退。這種方法的取巧之處在于巧妙地利用了 rebase 操作歷史提交的功能和 git 識(shí)別修改相同自動(dòng)合并的特性，操作雖然復(fù)雜，但歷史提交保留得還算完整。rebase 這種修改歷史提交的功能非常實(shí)用，能夠很好地解決我們遇到的一個(gè)小功能提交了好多次才好使，而把 git 歷史弄得亂七八糟的問(wèn)題，只需要注意避免在多人同時(shí)開(kāi)發(fā)的分支使用就行了。遺憾的是，當(dāng)天我并沒(méi)有理解到 rebase 的這種思想，又由于試了幾個(gè)方法都不行太過(guò)于慌亂，在 rebase 完成后，向主分支合并被拒之后對(duì)這些方式的可行性產(chǎn)生了懷疑，又加上有同事提出聽(tīng)起來(lái)更可行的方式，就中斷了操作。


文件操作
這種更可行的方式就是對(duì)文件操作，然后讓 git 來(lái)識(shí)別變更，具體是：

1. 從主分支上切出一個(gè)跟主分支完全相同的分支 F。
2. 從文件管理系統(tǒng)復(fù)制項(xiàng)目文件夾為 bak，在 bak 內(nèi)使用 git checkout N 將代碼切到想要的歷史提交，這時(shí)候 git 會(huì)將 bak 內(nèi)的文件恢復(fù)到 N 狀態(tài)。
3. 在從文件管理系統(tǒng)內(nèi)，將 bak 文件夾下 除了 .git 文件夾下的所有內(nèi)容復(fù)制粘貼到原項(xiàng)目目錄下。git 會(huì)純從文件級(jí)別識(shí)別到變更，然后更新工作區(qū)。
4. 在原項(xiàng)目目錄下執(zhí)行 add 和 commit，完成反提交。

這種方式的巧妙之處在于利用 git 本身對(duì)文件的識(shí)別，不牽涉到對(duì) workflow 操作。


總結(jié)
最后終于靠著文件操作方式成功完成了代碼回退，事后想來(lái)真是一把心酸淚。為了讓我的五個(gè)小時(shí)不白費(fèi)，復(fù)盤(pán)一下當(dāng)時(shí)的場(chǎng)景，學(xué)習(xí)并總結(jié)一下四種代碼回退的方式：

• revert 適合需要回退的歷史提交不多，且無(wú)合并沖突的情景。
• 如果你可以向 master 強(qiáng)推代碼，且想讓 git log 里不再出現(xiàn)被回退代碼的痕跡，可以使用 git reset --hard + git push --force 的方式。
• 如果你有些 geek，追求用”正規(guī)而正統(tǒng)”的方式來(lái)回退代碼，rebase + revert 滿足你的需求。
• 如果你不在乎是否優(yōu)雅，想用最簡(jiǎn)單，最直接的方式，文件操作正合適。

git 真的是非常牛逼的代碼管理工具，入手簡(jiǎn)單，三五個(gè)命令組合起來(lái)就足夠完成工作需求，又對(duì) geeker 們非常友好，你想要的騷操作它都支持，學(xué)無(wú)止境啊。