commit message type 規範 about mirror-media-nuxt HOT 6 OPEN

關於 init repo 的 commit 要不要獨立一個 commit type，我覺得可以不用。
我猜測會需要獨立一個 commit type 的原因在於，我們通常都是寫到一個段落才一次全部 commit，所以該 commit 裡面會包括 README.md(docs), package.json(chore), src/*.js(feat, refactor, fix) 等等多個 commits。
我是建議大家在 init 一個 repo 時，還是依據程式碼的修正來決定 commit type，而不是用單個 commit 新增所有的檔案。
不曉得以上建議符不符合我們的情況？

from mirror-media-nuxt.

我們使用 conventional commit message 規範的動機有：

1. 讓 developer 能簡單透過 commit message 知道 commit 的改動範圍
2. 可以撰寫程式碼，透過 commit message 來自動處理 package.json 裡面 version 的升版（這應該是 conventional commit message 被設計出來的主要目標，但我們 CI/CD 的部分還沒有實作就是了）

稍微說明一下第二點在幹什麼。
我們目前的 commit 都不會包括 package.json 裡 version 的調整，就算有調整，我們也都是透過手動處理。
但在一個多人開發的 repo 中，透過 CI/CD 自動升版（版本控制）是非常重要的一件事情。

因為 developer 都根據 conventional commit message 來撰寫 commit message，所以 CI/CD 時，我們可以透過 commit type 來決定 package version 如何升版。

舉例而言，若今天 package.json 裡的 version 為 1.1.0，當我推了一個 feat: add new feature A 的 commit，CI/CD 可以透過 commit type feat 來決定 package version，因為該 commit 是一個 feature，根據 semantic versioning 的定義而言，package version 得從 1.1.0 升到 1.2.0。

若是我接著推了一個 refactor: update index.js commit ，根據 commit type refactor，CI/CD 知道這是一個 patch 的調整，所以 version 會從 1.2.0 升到 1.2.1。

回到「我們需不需要 revert commit type？」的問題，
convention commit 官方文件 是建議我們使用 revert commit type。但在 commit message 中，要寫出 revert 的 commit refs。

透過 commit refs，CI/CD 可以知道該 revert 是 revert 一個 feat？還是 revert 一個 refactor？
因為兩個 revert 會影響的升版版號不一樣。
若是 revert feat commit，則是 minor change， package version 要升中間的版號，例如 1.3.0。
若是 revert refactor commit，則是 patch change，pcakge version 要升最後的版號，例如 1.2.1。
但 CI/CD 分析 revert commit type 的邏輯，可能會需要我們實作。

若是我們不使用 revert commit type 的話，
我們可以 commit feat: revert feature A 來 revert feat: add new feature A commit，
如此一來，CI/CD 會知道這是一個 feat commit，所以需要 minor change。

from mirror-media-nuxt.

建議的小結：

1. style commit type 留給「調整 CSS」 用。
2. 更改 coding convention（例如 camelCase 或是過 eslint 等）等改動屬於 refactor commit type。
3. 使用 revert commit type，但是 commit message 中需要提供 commit refs，讓 developer 或是 CI/CD 知道該 revert 的範圍是什麼？（參考文件: convention commit 官方文件）
4. 不需要特定為 init commit 新增一個 commit type，反倒是開發的 developer 不要一次性 commit 全部的檔案，還是根據以上 conventional commit 的規範來撰寫 commit message。

不曉得大家覺得如何？

cc @hcchien @kjwen310 @v61265 @caesarWHLee @yatiti84 @dyfu95

from mirror-media-nuxt.

1. style commit type 留給「調整 CSS」 用。
2. 更改 coding convention（例如 camelCase 或是過 eslint 等）等改動屬於 refactor commit type。
3. 使用 revert commit type，但是 commit message 中需要提供 commit refs，讓 developer 或是 CI/CD 知道該 revert 的範圍是什麼？（參考文件: convention commit 官方文件）
4. 不需要特定為 init commit 新增一個 commit type，反倒是開發的 developer 不要一次性 commit 全部的檔案，還是根據以上 conventional commit 的規範來撰寫 commit message。

第 1. ~ 3. 點沒有問題！但第 4. 點感覺比較困難，因為目前多數產生新專案的方式，都是利用框架初始化專案，第一次的 commit 就會包含相當多的檔案。若要從頭建立專案的所有檔案，好像也有點費工。

因此這邊是否可以規範：

1. 在起新專案時，init commit 需要盡可能保持乾淨，不要包含 doc、style ( css related ) 等各個檔案，只包含該專案運行時所需的必備檔案就好。
2. 如果按照以上的作法，init commit 的 commit message，使用 chore 前綴應該就會是合理的。

大家覺得如何呢？ c.c. @nickhsine @v61265 @dyfu95 @caesarWHLee

from mirror-media-nuxt.

因此這邊是否可以規範：

在起新專案時，init commit 需要盡可能保持乾淨，不要包含 doc、style ( css related ) 等各個檔案，只包含該專案運行時所需的必備檔案就好。
如果按照以上的作法，init commit 的 commit message，使用 chore 前綴應該就會是合理的。

我沒有問題喔。

from mirror-media-nuxt.

1. style commit type 留給「調整 CSS」 用。
2. 更改 coding convention（例如 camelCase 或是過 eslint 等）等改動屬於 refactor commit type。
3. 使用 revert commit type，但是 commit message 中需要提供 commit refs，讓 developer 或是 CI/CD 知道該 revert 的範圍是什麼？（參考文件: convention commit 官方文件）
4. 不需要特定為 init commit 新增一個 commit type，反倒是開發的 developer 不要一次性 commit 全部的檔案，還是根據以上 conventional commit 的規範來撰寫 commit message。

1~3點我也沒有問題，4.的話我也認同凱傑的建議，init commit的commit message，使用chore即可。
有一個比較小的建議，就是style的定義可以限縮成「僅調整CSS，沒有新增功能」。就我個人的開發經驗，有時候開發新功能時，不可避免地會同時調整到既有的CSS，如果沒有限縮成上述定義，會有「我同時有新增功能，但也有調整CSS，這樣算feat還是style呢？」的困擾存在。但如果有限縮的話，就可免除這個困擾：只要有新增功能，就會算feat，如果無實作新功能，則算style。

from mirror-media-nuxt.