MorJS Git Commit FAQ

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

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

提交標(biāo)題中的類(lèi)型是大寫(xiě)還是小寫(xiě)??

大小寫(xiě)都可以，但最好是一致的。

如果提交符合多種類(lèi)型我該如何操作？?

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

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

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

約定式提交會(huì)讓開(kāi)發(fā)者受限于提交的類(lèi)型嗎（因?yàn)樗麄儠?huì)想著已提供的類(lèi)型）？?

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

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

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

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

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

如果我不小心使用了錯(cuò)誤的提交類(lèi)型，該怎么辦呢？?

當(dāng)你使用了在規(guī)范中但錯(cuò)誤的類(lèi)型時(shí)，例如將 ?feat? 寫(xiě)成了 ?fix??

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

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

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

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

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

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

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

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

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

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868