怎么優(yōu)化git代碼

我們都看到過的

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

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

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

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

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

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

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

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

存在的問題

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

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

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

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

書寫優(yōu)秀的提交信息

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

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

主題

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

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

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

正文

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

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

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

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

結(jié)束語

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

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

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