記因git規範致使的提測和發佈延遲

號外

最近由於換工做的緣由，個人博客和Github沒有像以前那樣頻繁的更新了。一方面緣由是投遞簡歷和準備面試，因爲以前的基礎沒有很紮實，須要把平時的知識點都整理一遍。這個時間段持續了20多天的樣子，由於今年的互聯網市場遇冷，簡歷反饋率都不是很好。

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

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

​ 下圖是我天天記錄的📒，其餘的分類因爲設計到公司業務因此沒有展開，在工做和生活上都與涉及。

​ 通常咱們的產品需求週期是這樣的: 產品整理需求池 -> 交互評審 -> 技術評審 -> 聯調 -> 提測 -> 預發 -> 發佈。

​ 固然我做爲一個開發來講，更多關注的是需求的業務邏輯和優化、實現上。每一個團隊都有本身的git分支規範，咱們也不例外。

Git分支規範

1. feature分支

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

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

2. bugfix分支

   不緊急的bug修復分支。命名規則是: bugfix/{創建分支的人的姓名拼音首字母}/{分支後綴名}

   ​ 和上文實現相似。

3. hotfix分支

   ​ 緊急的bug修復分支，命名規則是：hotfix/{創建分支的人的姓名拼音首字母}/{分支後綴名}

   • ​ 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上的可視化工具，進行版本對比。

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

3. 選擇相應的分支後，咱們能看到兩個版本上不一樣的文件。此時，咱們須要根據咱們的記憶，對相應的文件進行修改。

   

4. 文件代碼對比，咱們能夠點擊 >>,將deploy-test上的代碼挪到本身的分支上去。

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

總結

​ 開發是個技術性工做，而團隊開發是一個紀律性、團隊合做性和有必定哲學性的學問。雖然上面👆的條條框框讓個人開發效率變得很很差，固然這個效率是相對我的而言。由於每開發一個新需求就須要創建分支，合併代碼到各類環境，對於一個不細心和急躁的工程師，光這個工做都使人煩惱了。可是對於一個團隊來講，以上的條條框框對於整個團隊是高效而又不會出錯的。在這裏，筆者有個小問題，大家團隊的git工做流程又是怎麼樣的呢？麻煩告知一下。

資源推薦

工具推薦

1. 咱們在每次提交代碼時，都須要編寫Commit Message，不然是不容許提交的。 git commit -m first commit with userInfo service，編寫Commit Message須要遵循必定的範式，內容應該清晰明瞭，指明本次提交的目的，便於往後追蹤問題。 commitizen 就是這麼樣一款工具,他用來規範化咱們的commit消息。

2. ​ 由於git的commit提交是支持emoji表情的，因此在非正式場合或者想趣味性的表達本身的提交信息，能夠在調教信息中添加emoji代碼，具體網址參考: gitmoji.carloscuesta.me/

實際效果以下圖所示

快速安裝

1. 安裝nodejs（nodejs.org/en/）
2. 安裝commitizen，在用戶目錄下配置

cd ~

npm install -g commitizen

commitizen init cz-conventional-changelog --save --save-exact

簡單使用

這裏推薦阮一峯的博文：www.ruanyifeng.com/blog/2016/0…

走進Git

• marklodato 《圖解 Git》
• 超哥 《Git 經常使用命令速查手冊》
• 貓尾 《Git 提交記錄和分支模型》
• 自由 《我必須分享給你們的 Git 資源彙總》