MorJS Git Commit FAQ

在初始開發(fā)階段我該如何處理提交說明？?

我們建議你按照假設(shè)你已發(fā)布了產(chǎn)品那樣來處理。因為通?？?nbsp;有人 使用你的軟件，即便那是你軟件開發(fā)的同伴們。他們會希望知道諸如修復(fù)了什么、哪里不兼容等信息。

提交標(biāo)題中的類型是大寫還是小寫??

大小寫都可以，但最好是一致的。

如果提交符合多種類型我該如何操作？?

回退并盡可能創(chuàng)建多次提交。約定式提交的好處之一是能夠促使我們做出更有組織的提交和 PR。

這不會阻礙快速開發(fā)和迭代嗎？?

它阻礙的是以雜亂無章的方式快速前進(jìn)。它助你能在橫跨多個項目以及和多個貢獻(xiàn)者協(xié)作時長期地快速演進(jìn)。

約定式提交會讓開發(fā)者受限于提交的類型嗎（因為他們會想著已提供的類型）？?

約定式提交鼓勵我們更多地使用某些類型的提交，比如 ?fixes?。除此之外，約定式提交的靈活性也允許你的團(tuán)隊使用自己的類型，并隨著時間的推移更改這些類型。

這和 SemVer 有什么關(guān)聯(lián)呢？?

?fix? 類型提交應(yīng)當(dāng)對應(yīng)到 ?PATCH? 版本。?feat? 類型提交應(yīng)該對應(yīng)到 ?MINOR? 版本。帶有 ?BREAKING CHANGE? 的提交不管類型如何，都應(yīng)該對應(yīng)到 ?MAJOR? 版本。

我對約定式提交做了形如 ?@jameswomack/conventional-commit-spec? 的擴(kuò)展，該如何版本化管理這些擴(kuò)展呢？?

我們推薦使用 SemVer 來發(fā)布你對于這個規(guī)范的擴(kuò)展（并鼓勵你創(chuàng)建這些擴(kuò)展?。?/p>

如果我不小心使用了錯誤的提交類型，該怎么辦呢？?

當(dāng)你使用了在規(guī)范中但錯誤的類型時，例如將 ?feat? 寫成了 ?fix??

在合并或發(fā)布這個錯誤之前，我們建議使用 ?git rebase -i? 來編輯提交歷史。而在發(fā)布之后，根據(jù)你使用的工具和流程不同，會有不同的清理方案。

當(dāng)使用了 不在 規(guī)范中的類型時，例如將? feat? 寫成了 ?feet??

在最壞的場景下，即便提交沒有滿足約定式提交的規(guī)范，也不會是世界末日。這只意味著這個提交會被基于規(guī)范的工具錯過而已。

所有的貢獻(xiàn)者都需要使用約定式提交規(guī)范嗎？?

并不！如果你使用基于 squash 的 Git 工作流，主管維護(hù)者可以在合并時清理提交信息——這不會對普通提交者產(chǎn)生額外的負(fù)擔(dān)。 有種常見的工作流是讓 git 系統(tǒng)自動從 pull request 中 squash 出提交，并向主管維護(hù)者提供一份表單，用以在合并時輸入合適的 git 提交信息。

約定式提交規(guī)范中如何處理還原（revert）提交??

還原提交（Reverting）會比較復(fù)雜：你還原的是多個提交嗎？如果你還原了一個功能模塊，下次發(fā)布的應(yīng)該是補丁嗎？

約定式提交不能明確的定義還原行為。所以我們把這個問題留給工具開發(fā)者， 基于 類型 和 腳注 的靈活性來開發(fā)他們自己的還原處理邏輯。

一種建議是使用 ?revert ?類型，和一個指向被還原提交摘要的腳注：

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868