當我們使用 JavaScript 開發時，常常會需要使用 npm 進行 node_modules 的安裝，相關的使用說明可以參考前一篇寫的 NPM 常用指令教學。
在時間管理大師的世界裡，記住曾經和每個對象的回憶跟說過的話是很重要的，隨著對象越多就越有可能在某天踢到鐵板?!
如果對象與對象之間的相似性和重疊性越高，就可能面臨不敢改變的風險，譬如工作譬如興趣譬如作息譬如說過的情話，隨著時光飛逝，該怎麼好好記錄和應對?!
在專案中，使用的套件與套件之間也可能產生相依性，那當版本需要升級時該怎麼評估和測試可能的影響?
在使用套件的過程中，版本號代表的意涵就相對重要，這篇文章中將提到:
Semantic 是語意化的意思，目標是讓用戶可以透過版本號看出相關資訊，所以語意化的版本控制會有三個要素
1.2.3 對應到 主版號.次版號.修訂號，三位數字為非負整數，且會遞增版號資訊會在 package.json 中 version 這個值，另外版本資訊都跟 git tag 有關，通常會寫在:
所以當我們每次進行發佈前:
CHANGELOG.md
約定提交規範是在程式碼提交的時按照一組簡單的規則來建立明確的提交歷史。
當規範出現後，相關支援 SemVer 的自動化工具就能協助進行整理。
訊息格式會像這樣 類型(範圍): 敘述，範圍通常用檔名，所以一個 commit 訊息可能會是:
BREAKING CHANGE(README.md): 第一版說明文件
常用類型:
舉例來說 Commit 就會長成
其他不會被統整，但可能有機會用到的:
約定式提交有另外一個好處，那就是在 Code Review 的時候，可以很快的知道什麼該看什麼不該看，以小編的習慣來說只會認真看 feat 以及 fix 的部分。
Angular Commit Message Conventions:
https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format
只要 commit 訊息有遵守約定式提交相關原則，commit-lint 或是 commitizen 等工具就有辦法做到強制產生提交資訊。
那按照適用的環境主要有以下兩個工具:
| semantic-release | standard-version |
|---|---|
| 有 CI/CD | 無 CI/CD |
| git tag 及 releases | git tag 及 CHANGELOG.md |
semantic-release 自動化了套件的發布流程:
在自動化過程中，不再需要靠感覺撰寫版號，嚴格遵循語義版本控制規範，並且透過版號表示更改的影響範圍，語義發布會在發布分支上每次成功建置後在 CI 環境中執行，不會有任何人介入發布的過程可以減少人為的失誤。
基於 Conventional Commits 並使用 semver 生成 CHANGELOG 的版本控制工具，standard-version 只會在本機端處理版本控制、更改日誌生成和 Git Tag。
運行後 standard-version，您可以查看發布狀態、修正正錯誤並依照公司規範進行發佈。
跟 semantic-release 一樣都都是很棒的工具，允許自動化的情況下是建議盡量使用 semantic-release 而不是 standard-version。
CHANGELOG.md
iThome鐵人賽
看影片追技術