GIT版本管理

基於GIT版本管理

• Author: HuiFer

Git是一個 “分佈式版本管理工具”，簡單的理解版本管理工具：大家在寫東西的時候都用過 “回撤” 這個功能，但是回撤只能回撤幾步，假如想要找回我三天之前的修改，光用 “回撤” 是找不回來的。而 “版本管理工具” 能記錄每次的修改，只要提交到版本倉庫，你就可以找到之前任何時刻的狀態（文本狀態）。

開卷必讀

• 如果你還沒有使用過GIT或者不知道Git是什麼可以看一下這篇文章：git 簡單使用教程

git commit 語義化提交日誌

• 每次提交都需要攜帶chore(維護)、docs(文檔)、feat(新功能)、fix(bug修復)、refactor(重構)、style(樣式)、test(測試) 其中一個,不可多個重複在一個commit中!

語義化版本號

以 v1.5.2 爲例，1.5.2 按照英文句號分割爲三部分：

• 主版本號：：是你對項目做了不兼容的 API 修改，即大版本的升級。
• 次版本號：當你做了向下兼容的功能性新增。即，新增了功能，但是不影響舊有功能的使用。
• 修訂號：你做了向下兼容的問題修正。即，bug fix 版本。沒有新增功能，只是修復了歷史遺漏 BUG。

git分支模型

Vincent Driessen 提出的git 管理流程和規範

圖解

圖中我們可以看到分支有master、hotfix、develop、release 、feature 5個分支

• master

  • 該分支不可提交代碼只能從其他分支合併(dev&hotfix&release)
  • 管理員可操作

• hotfix

  • 當我們發現master上存在bug時新建hotfix分支進行修復修復完成後合併回master和develop分支
  • 開發人員操作

• develop

  • 開發分支,主要用來合併feature分支，當代碼量或者開發進度到達一定程度可以發佈此時可以合併到master分支
  • 開發人員操作

• release

  • 發佈版本分支
  • 管理員可操作

• feature

  • 該分支用來開發新功能，新功能完成後合併到develop分支
  • 開發人員操作

• tag

  • 標籤用來標識版本號
  • 都可以操作

git flow 解決的問題

1. 新功能如何開發
2. 功能之間不會互相影響
3. 對分支的語義化描述
4. 發佈版本管理
5. 線上代碼bug修復

推薦軟件

SourceTree

代碼審計 code review

目標

• 提高代碼質量，及早發現潛在缺陷，降低修改/彌補缺陷的成本

• 促進團隊內部知識共享，提高團隊整體水平

• 評審過程對於評審人員來說，也是一種思路重構的過程，幫助更多的人理解系統

• 是一個傳遞知識的手段，可以讓其它並不熟悉代碼的人知道作者的意圖和想法，從而可以在以後輕鬆維護代碼

• 可以被用來確認自己的設計和實現是一個清楚和簡單的

• 鼓勵相互學習對方的長處和優點

• 高效迅速完成Code Review

Pull Request（PR）

• 通過PR的方式進行code review
• 一個PR中不可以存在多個任務
• PR發起後在1-2天內合併或者拒絕
  • 拒絕告知具體原因

Code Review Checklist

完整性檢查

1. 是否實現當前版本提出功能
2. 是否修改bug
3. 是否創建數據庫、表
4. 是否存在初始化數據需要創建
5. 是否存在任何沒有定義或沒有引用到的變量、常數或數據類型

一致性檢查

• 是否符合提出功能
• 使用的格式、符號、結構是否一致(如tab是2個空格還是4個或者其他)建議使用 editorconfig文件進行管理

正確性檢查

• 註釋正確性
• 參數正確性

可修性改檢查

• 代碼涉及到的常量是否易於修改(如使用配置、定義爲類常量、使用專門的常量類等)

可預測性檢查

• 死循環
• 無窮遞歸

健壯性檢查

• 資源釋放
• 異常處理

結構性檢查

• 循環只有一個入口
• 功能模塊的辨識度

可追溯檢查

• 命名唯一性
• 修訂歷史記錄

可理解性檢查

• 函數、類的註解
• 刪除不使用的代碼
• 統一縮進
• 變量的取值範圍

可重用檢查

• 同一段代碼不重複出現
• 抽象可重用函數,類

安全性檢查

• 硬編碼用於測試的刪除
• 敏感數據

性能檢查

• 選擇合適的數據類型
• 懶加載
• 異步
• 並行
• 緩存

推薦插件

• Alibaba Java Coding Guidelines
• SonarLint