xsteadfastx/conventionalcommits.org
1
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2024-11-15 02:45:15 +01:00
Code Issues Projects Releases Wiki Activity

fix(zh-hant): Distinguish translations of 'Release/Publish'

Browse Source
This commit is contained in:
Haowei Hsu 2023-10-19 06:49:51 -04:00 committed by GitHub
parent 551cfd47a5
commit 5b935ded2e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
content/v1.0.0-beta.4/index.zh-hant.md
View File

@ -104,7 +104,7 @@ closes issue #12
### 在初始的開發階段，我該如何處理提交說明？ ### 在初始的開發階段，我該如何處理提交說明？
我們建議你可以就像是產品已經發布的那樣去執行。因為通常都會 *有人* 使用你的軟體，即使是你的軟體開發的同事們，他們會希望知道修正了什麼以及有什麼重大變更等資訊。 我們建議你可以就像是產品已經發行的那樣去執行。因為通常都會 *有人* 使用你的軟體，即使是你的軟體開發的同事們，他們會希望知道修正了什麼以及有什麼重大變更等資訊。
### 提交標題中的類型應該要用大寫還是小寫？ ### 提交標題中的類型應該要用大寫還是小寫？
@ -124,18 +124,18 @@ closes issue #12
### 這與 SemVer 有什麼關係呢？ ### 這與 SemVer 有什麼關係呢？
`fix` 類型的提交應該對應到 `PATCH` 版本。`feat` 類型的提交應該對應到 `MINOR` 版本。含有 `BREAKING CHANGE` 的提交，無論是什麼類型，都應該要對應到 `MAJOR` 版本。 `fix` 類型的提交應該對應到 `PATCH` 發行版。`feat` 類型的提交應該對應到 `MINOR` 發行版。含有 `BREAKING CHANGE` 的提交，無論是什麼類型，都應該要對應到 `MAJOR` 發行版。
### 我對慣例式提交做了擴充 (例如：`@jameswomack/conventional-commit-spec`)，我該如何管理這些擴充的版本呢？ ### 我對慣例式提交做了擴充 (例如：`@jameswomack/conventional-commit-spec`)，我該如何管理這些擴充的版本呢？
我們推薦使用 SemVer 來發布你對這份規範的擴充 (並且也鼓勵你做些擴充！) 我們推薦使用 SemVer 來發行你對這份規範的擴充 (並且也鼓勵你做些擴充！)
### 如果我不小心用錯提交類型，該怎麼辦？ ### 如果我不小心用錯提交類型，該怎麼辦？
#### 當你使用規範中但是錯誤的類型，例如：將 `feat` 寫成 `fix` #### 當你使用規範中但是錯誤的類型，例如：將 `feat` 寫成 `fix`
在合併或是發布這個錯誤之前，我們推薦使用 `git rebase -i` 來編輯提交歷史。 在合併或是發行這個錯誤之前，我們推薦使用 `git rebase -i` 來編輯提交歷史。
而在發布之後，根據你使用的工具與流程，會有不同的清理方式。 而在發行之後，根據你使用的工具與流程，會有不同的清理方式。
#### 當你使用 *非* 規範中的類型時，例如：將 `feat` 寫成 `feet` #### 當你使用 *非* 規範中的類型時，例如：將 `feat` 寫成 `feet`

12
content/v1.0.0/index.zh-hant.md
View File

@ -136,7 +136,7 @@ Refs: #123
### 在初始的開發階段，我該如何處理提交說明？ ### 在初始的開發階段，我該如何處理提交說明？
我們建議你可以就像是產品已經發布的那樣去執行。因為通常都會 *有人* 使用你的軟體，即使是你的軟體開發的同事們，他們會希望知道修正了什麼以及有什麼重大變更等資訊。 我們建議你可以就像是產品已經發行的那樣去執行。因為通常都會 *有人* 使用你的軟體，即使是你的軟體開發的同事們，他們會希望知道修正了什麼以及有什麼重大變更等資訊。
### 提交標題中的類型應該要用大寫還是小寫？ ### 提交標題中的類型應該要用大寫還是小寫？
@ -156,18 +156,18 @@ Refs: #123
### 這與 SemVer 有什麼關係呢？ ### 這與 SemVer 有什麼關係呢？
`fix` 類型的提交應該對應到 `PATCH` 版本。`feat` 類型的提交應該對應到 `MINOR` 版本。含有 `BREAKING CHANGE` 的提交，無論是什麼類型，都應該要對應到 `MAJOR` 版本。 `fix` 類型的提交應該對應到 `PATCH` 發行版。`feat` 類型的提交應該對應到 `MINOR` 發行版。含有 `BREAKING CHANGE` 的提交，無論是什麼類型，都應該要對應到 `MAJOR` 發行版。
### 我對慣例式提交做了擴充 (例如：`@jameswomack/conventional-commit-spec`)，我該如何管理這些擴充的版本呢？ ### 我對慣例式提交做了擴充 (例如：`@jameswomack/conventional-commit-spec`)，我該如何管理這些擴充的版本呢？
我們推薦使用 SemVer 來發布你對這份規範的擴充 (並且也鼓勵你做些擴充！) 我們推薦使用 SemVer 來發行你對這份規範的擴充 (並且也鼓勵你做些擴充！)
### 如果我不小心用錯提交類型，該怎麼辦？ ### 如果我不小心用錯提交類型，該怎麼辦？
#### 當你使用規範中但是錯誤的類型，例如：將 `feat` 寫成 `fix` #### 當你使用規範中但是錯誤的類型，例如：將 `feat` 寫成 `fix`
在合併或是發布這個錯誤之前，我們推薦使用 `git rebase -i` 來編輯提交歷史。 在合併或是發行這個錯誤之前，我們推薦使用 `git rebase -i` 來編輯提交歷史。
而在發布之後，根據你使用的工具與流程，會有不同的清理方式。 而在發行之後，根據你使用的工具與流程，會有不同的清理方式。
#### 當你使用 *非* 規範中的類型時，例如：將 `feat` 寫成 `feet` #### 當你使用 *非* 規範中的類型時，例如：將 `feat` 寫成 `feet`
@ -180,7 +180,7 @@ Refs: #123
### 慣例式提交要如何處理回退提交 (revert commit)？ ### 慣例式提交要如何處理回退提交 (revert commit)？
回退程式碼可能非常複雜：你是回退了多個提交嗎？如果你回退了一個功能，那麼下一個版本釋出應該要是修正檔嗎？ 回退程式碼可能非常複雜：你是回退了多個提交嗎？如果你回退了一個功能，那麼下一個發行版應該要是修正檔嗎？
慣例式提交沒有強制定義回退的行為。反而，我們將這個問題留給工具的作者，靈活運用 _類型_ 以及 _頁腳_ 來開發處理回退的邏輯。 慣例式提交沒有強制定義回退的行為。反而，我們將這個問題留給工具的作者，靈活運用 _類型_ 以及 _頁腳_ 來開發處理回退的邏輯。