記因git規範導致的提測和發布延遲

• 2019 年 10 月 26 日
• 筆記

號外

最近因為換工作的原因，我的部落格和Github沒有像之前那樣頻繁的更新了。一方面原因是投遞簡歷和準備面試，由於之前的基礎沒有很紮實，需要把平時的知識點都整理一遍。這個時間段持續了20多天的樣子，因為今年的互聯網市場遇冷，簡歷回饋率都不是很好。

​ 我一共投遞了菜鳥網路，天貓超市，有贊，大搜車和塗鴉智慧等公司，都收到了面試邀請。菜鳥網路和塗鴉智慧投遞的職位方向都是我比較感興趣的IOT，有贊投遞的是風控和大搜車的新零售職位，後兩個都是我之前的沒有接觸過的領域。最後由於各方面的考慮(沒面試成功和對工作以及生活的平衡)，我選擇了之前沒有接觸過的大搜車新零售領域的職位。

​ 但是今天我想說的並不是面試經歷，而是我標題所描述的工作中發生的有趣的事。因為新入職一個公司，需要對工作流程和項目程式碼進行熟悉，同時還需要對新零售這個領域和行業需要進行了解和認識。所以拿到產品分配給我的需求，我大部分的時間都是花在了需求整理和詢問同事上了，真正花在寫業務需求上的時間是很少的。

​ 下圖是我每天記錄的?，其他的分類由於設計到公司業務所以沒有展開，在工作和生活上都與涉及。

​ 一般我們的產品需求周期是這樣的: 產品整理需求池 -> 交互評審 -> 技術評審 -> 聯調 -> 提測 -> 預發 -> 發布。

​ 當然我作為一個開發來說，更多關注的是需求的業務邏輯和優化、實現上。每個團隊都有自己的git分支規範，我們也不例外。

Git分支規範

1. feature分支

   開發新功能時，應用從develop分支簡歷feature分支。命名規則時: feature/${ 建立分支時的日期，yyyyMMdd格式 }/${建立分支的人的姓名拼音首字母}/${分支後綴名}

   • 建立分支的人的姓名拼音首字母: 例如，開發者是"穆書偉"，這裡就是msw,要求全小寫。
   • 建立分支時的日期: 例如，20191025。
   • 分支後綴名：如果我需要開發部落格文章這個需求，可能這裡我寫的名稱是 blog_article,要求全小寫，用下劃線格式。
   • feature分支開發完畢，和前端聯調時，將此分支合併到測試分支上(deploy-test)。當聯調完畢，我們需要將分支合併到預發環境上(deploy-prepub)，此時我和前端需要寫提測單，將需求實現內容給測試工程師進行測試(下面可能有和此雷同的內容，下面的博文我會以【上文實現】來代替)。

2. bugfix分支

   不緊急的bug修復分支。命名規則是: bugfix/${建立分支時的日期，yyyyMMdd格式}/${建立分支的人的姓名拼音首字母}/{分支後綴名}

   ​ 和上文實現類似。

3. hotfix分支

   ​ 緊急的bug修復分支，命名規則是：hotfix/${建立分支時的日期，yyyyMMdd格式}/${建立分支的人的姓名拼音首字母}/{分支後綴名}

   • ​ hotfix和feature/bugfix不同是,hotfix是master出來的，而上面的分支是從develop分支建立的，因為要緊急發布。

   • 和上文實現類似。

4. release分支

   release可以比較有效的避免發布搭車的情況，這個分支目前比較少用到，因為運維是發布的master分支，使用方式為用git flow release去生產。

錯誤案例

​ 本來我作為一個有三年開發經驗的工程師，我本不應該犯以下的錯誤。但Jira(bug管理工具)不斷彈出被測試提出來的bug和當時遠沒有現在寫這篇部落格時, 對公司的規範十分熟悉的情況下，我做出了十分愚蠢的舉動。

​ 為了儘快的看到自己寫的程式碼是否修復bug,我不僅僅在自己的分支上修改了需求實現，而且也在deploy-test上做了改動但是沒有同步到自己的分支上。當我解決完Jira上所有bug時，滿心歡喜的想要把分支合併到develop上時。我一看程式碼，回想到了整個過程，此時，我是絕望而又懵逼的。此時電腦的時間已經走到了16:30,我抓耳撓腮，不知道怎麼辦了。

此時，大家可能會注意到deploy-test上有完整的我修復的程式，因為deploy-test是聯調和測試過的程式碼。此時很多小夥伴在我當時的情況下，會把deploy-test合併到develop上。但是deploy-test分支太過髒亂，有很多其他開發人員寫的測試程式碼和列印日誌程式碼。永遠不要把deploy-test分支合併到自己的分支，也不要合併到develop和master分支上。

以前我認為釘釘是一個提高工作效率的IM軟體，但是此時的它如懸在我頭頂上的倒計時的?。未讀->已讀，短時間沒有讀，就會DING。未讀->5-10分鐘沒有解決，釘釘電話☎️就會打過來。

此時我還是沉下心來，把之前在deploy-test上修改的部分而未同步到自己的分支上的程式碼移過來。以下是我的IDEA操作步驟，當然大家也可以用其他可視化工具或者命令行。

1. 切換到自己的分支上，利用IDEA上的可視化工具，進行版本對比。

1. 選擇遠程的deploy-test分支，進行版本程式碼對比。

1. 選擇相應的分支後，我們能看到兩個版本上不同的文件。此時，我們需要根據我們的記憶，對相應的文件進行修改。

2. 文件程式碼對比，我們可以點擊 >>,將deploy-test上的程式碼挪到自己的分支上去。

​ 做了上面緊急的處理後，我又在本地運行了程式，做了簡單的自測並在最後的關頭給測試寫了提測單。經測試無誤後，發不到了線上，此時，我的心在落到了肚子里。

總結

​ 開發是個技術性工作，而團隊開發是一個紀律性、團隊合作性和有一定哲學性的學問。雖然上面?的條條框框讓我的開發效率變得很不好，當然這個效率是相對個人而言。因為每開發一個新需求就需要建立分支，合併程式碼到各種環境，對於一個不細心和急躁的工程師，光這個工作都令人煩惱了。但是對於一個團隊來說，以上的條條框框對於整個團隊是高效而又不會出錯的。在這裡，筆者有個小問題，你們團隊的git工作流程又是怎麼樣的呢？麻煩告知一下。

資源推薦

• marklodato 《圖解 Git》
• 超哥 《Git 常用命令速查手冊》
• 貓尾 《Git 提交記錄和分支模型》
• 自由 [《我必須分享給大家的 Git 資源匯總》](