<mark id="10v55"></mark>
<small id="10v55"><video id="10v55"></video></small>

  • <tr id="10v55"></tr>
    <menuitem id="10v55"></menuitem>

    MorJS Git Commit FAQ

    2024-01-24 09:45 更新

    在初始開發階段我該如何處理提交說明??

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

    提交標題中的類型是大寫還是小寫??

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

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

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

    這不會阻礙快速開發和迭代嗎??

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

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

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

    這和 SemVer 有什么關聯呢??

    ?fix? 類型提交應當對應到 ?PATCH? 版本。?feat? 類型提交應該對應到 ?MINOR? 版本。帶有 ?BREAKING CHANGE? 的提交不管類型如何,都應該對應到 ?MAJOR? 版本。

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

    我們推薦使用 SemVer 來發布你對于這個規范的擴展(并鼓勵你創建這些擴展?。?/p>

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

    當你使用了在規范中但錯誤的類型時,例如將 ?feat? 寫成了 ?fix??

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

    當使用了 不在 規范中的類型時,例如將? feat? 寫成了 ?feet??

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

    所有的貢獻者都需要使用約定式提交規范嗎??

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

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

    還原提交(Reverting)會比較復雜:你還原的是多個提交嗎?如果你還原了一個功能模塊,下次發布的應該是補丁嗎?

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

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

    revert: let us never again speak of the noodle incident

    Refs: 676104e, a215868


    以上內容是否對您有幫助:
    在線筆記
    App下載
    App下載

    掃描二維碼

    下載編程獅App

    公眾號
    微信公眾號

    編程獅公眾號

    √天堂资源中文最新版,√天堂资源最新版在线,女人脱了内裤露P毛A片