<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          【譯】求你不要再寫(xiě)沒(méi)用的提交信息了

          共 2105字,需瀏覽 5分鐘

           ·

          2020-07-28 15:06

          開(kāi)始嘗試優(yōu)化你的 Git 提交信息吧

          我們都看到過(guò)的

          你在一個(gè)項(xiàng)目中使用 Git 作為版本控制。

          當(dāng)你做完了一次修改之后,你想要盡快更新你的分支。

          所以你打開(kāi)了終端,輸入了下面這些命令,完成了一次遠(yuǎn)端分支的更新。

          git add .
          git commit -m "added new feature"
          git push

          然后你做了一些自測(cè),發(fā)現(xiàn)了一個(gè)新鮮的 bug。問(wèn)題不大,你很輕松的就解決掉了這個(gè) bug,現(xiàn)在你需要把新的代碼再次提交到遠(yuǎn)程分支,于是你很熟練的使用起 Git 命令。

          git add .
          git commit -m "fix bug"
          git push

          你幾乎每天都在重復(fù)做著這樣的事情,當(dāng)你打開(kāi) Git log 時(shí),你會(huì)發(fā)現(xiàn)它長(zhǎng)成了這個(gè)樣子。

          git log

          到目前為止,一切看上去對(duì)你來(lái)說(shuō)都還不錯(cuò)。畢竟你很熟悉你的代碼倉(cāng)庫(kù),即使不需要提交信息的提醒,你也知道每次修改都是在進(jìn)行了哪些操作。

          存在的問(wèn)題

          過(guò)了幾個(gè)月,其他的開(kāi)發(fā)者瀏覽了你過(guò)去的修改,他們想要嘗試更深入的理解關(guān)于你所做的修改的一些細(xì)節(jié)問(wèn)題,但是你的提交信息并不具備描述性,他們也就無(wú)法從中獲取任何有用的信息。

          無(wú)奈之下,他們只能挨個(gè)查看每次提交的不同,然而即使這么做了,他們也還是不能很明確的知道你在開(kāi)發(fā)過(guò)程中一些選擇的理由和你的一些思考。

          由于軟件開(kāi)發(fā)是一個(gè)協(xié)作的過(guò)程中,所以人們總是會(huì)使用 git blame 操作來(lái)查看是誰(shuí)對(duì)代碼做了修改,并且會(huì)問(wèn)你一些關(guān)于代碼的問(wèn)題。但是距離你寫(xiě)這段代碼已經(jīng)過(guò)去很長(zhǎng)時(shí)間了,你的印象也比較模糊。當(dāng)你查看你的提交時(shí),你發(fā)現(xiàn)自己很難說(shuō)出當(dāng)時(shí)為什么要這么寫(xiě),以及其中的一些邏輯細(xì)節(jié)。

          你給同事發(fā)送了一個(gè)悲傷的表情,并且告訴他們,你沒(méi)有辦法給他們提供更多的信息。

          書(shū)寫(xiě)優(yōu)秀的提交信息

          希望通過(guò)上面的故事,你已經(jīng)知道了為什么要編寫(xiě)良好的、信息豐富的 Git 提交信息:

          在軟件工程這樣需要協(xié)作的領(lǐng)域中,它可以幫助我們快速理解上下文。理想情況下,Git 提交信息需要由三部分組成:主題、正文和結(jié)語(yǔ)。

          主題

          主題需要是一句話來(lái)概括你提交內(nèi)容所涉及的修改。它需要是祈使時(shí)態(tài),以大寫(xiě)字母開(kāi)頭,結(jié)尾沒(méi)有句號(hào),并且最好小于50個(gè)字。

          一個(gè)好的主題格式應(yīng)該是像“This commit will …”這樣的。好的提交信息也應(yīng)該是一個(gè)比較完整的句子?!癮dd new neural network model to back-end”。

          而不好的提交信息就不是一個(gè)完整描述的句子,比如最常見(jiàn)的“fix bug”。

          正文

          正文需要包含你要傳達(dá)的信息,讓其他人在其中能夠了解更多關(guān)于這次修改的細(xì)節(jié)。對(duì)于一些比較修改的修改,比如改動(dòng)了一個(gè)變量類型,你可能不需要寫(xiě)正文,主題就足夠描述這次修改的內(nèi)容了。

          在正文中,你應(yīng)該更詳細(xì)的描述這次修改中的一些細(xì)節(jié)問(wèn)題,并且解釋你所做的事情的前因后果。

          你可以解釋為什么要做出這個(gè)修改,為什么用這種特殊的方式來(lái)實(shí)現(xiàn),或者其他你覺(jué)得能夠幫助其他人理解你的修改過(guò)程的信息。

          注意不要重復(fù)描述代碼中顯而易見(jiàn)的邏輯,正文也不是讓你一行一行的解釋代碼,大家更加關(guān)注的是代碼中不容易看出來(lái)的更深層的一些細(xì)節(jié)問(wèn)題。我們的最終目標(biāo)是為這次的修改提供有效的上下文信息,即更改主要的動(dòng)機(jī)和目標(biāo)。

          結(jié)束語(yǔ)

          最后,結(jié)束語(yǔ)應(yīng)該出現(xiàn)在你的提交信息的最后一行。

          你可以在這里提供一些關(guān)于此次修改的元數(shù)據(jù),比如 JIRA 號(hào),GitHub issue 號(hào),合作者姓名,和附加信息的鏈接。

          這有助于將你的修改的相關(guān)重要信息鏈接在一起。

          原文鏈接

          https://medium.com/better-programming/stop-writing-bad-commit-messages-8df79517177d

          可點(diǎn)擊閱讀原文查看

          往期精彩回顧
          Elasticsearch源碼解析:環(huán)境搭建
          Elasticsearch從入門(mén)到放棄:再聊搜索
          Elasticsearch從入門(mén)到放棄:分詞器初印象


          瀏覽 28
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  国产一级黄片观看 | 色撸撸在线视频 | 国产对白国语对白 | 婷婷国产精品视频 | 搞逼网站 |