做乙個有品位的程式設計師

2021-07-15 17:34:25 字數 3616 閱讀 6859

「能夠寫出漂亮**的程式設計師就是有品味的程式設計師麼？」

「還不夠。品味來自於每乙個細節，有品位的程式設計師會把每一次提交做小、做對、做好，盡量做到整個開發的過程的無可挑剔，這樣才夠逼格，才可以稱為有品位。」

$ git log --no-merges --pretty="" --shortstat


2 files changed, 25 insertions(+), 4 deletions(-) 1 file changed, 4 insertions(+), 12 deletions(-) 2 files changed, 30 insertions(+), 1 deletion(-) 3 files changed, 15 insertions(+), 5 deletions(-) ...


...
那麼如何將提交拆分為若干個小提交呢？

$ git reset head^
通過補丁塊揀選方式選擇要提交的修改。git 會逐一顯示工作區更改，如果確認此處改動要提交，輸入「y」。

$ git add -p
此處顯示補丁塊（hunk），使用者根據提示資訊，輸入自己的選擇：輸入y，此塊兒補丁要提交； 輸入n，此塊兒補丁不提交；輸入s，嘗試將此塊兒補丁細分； 輸入e，開啟編輯器對此塊兒補丁進行再次編輯。（注：head@ 是上一步 git reset 操作前的head提交，具體含義檢視 git reflog 幫助）

$ git commit -e -c head@
對於工作區其餘的修改進行提交，完成乙個提交拆分為兩個的操作。 （注：git add -u 是將已經建立跟蹤的檔案的修改新增到提交佇列/index中。如果要把工作區中所有檔案新增到index，執行git add -a）

$ git add -u


$ git commit
如果要拆分的提交，不同的實現邏輯耦合在一起，難以通過補丁塊揀選（git add -p）的方式修改提交，怎麼辦？這時可以 直接編輯檔案，刪除要剝離出此次提交的修改，然後執行下面命令更新當前提交：

$


gitcommit--


amend
接下來執行下面的命令，還原出原有的檔案修改，然後再次提交。如下：

$ git checkout head@ 


$ git commit
同樣完成了乙個提交拆分為兩個提交的操作。 拆分歷史某個提交

如果要拆分的是歷史提交（如提交 54321），而非當前提交，則可以執行互動式變基（git rebase -i），如下： 

$ git rebase -i 54321^
git 會自動將參與變基的提交寫在乙個動作檔案中，還會自動開啟編輯器（比如 vi 編輯器）。

將要拆分的提交 54321 前面的關鍵字 pick 修改為 edit，儲存並退出。變基操作隨即開始執行。 首先會在提交 54321 處停下來，這時要拆分的提交成為了當前提交，參照前面「拆分當前提交」的方法對提交 54321 進行拆分。拆分結束再執行 :

$ git rebase --continue
完成整個變基操作。 提交做對 「好的文章不是寫出來的，而是改出來的。」 **提交也是如此。 程式設計師寫完**，往往迫不及待地敲下：git commit，然後發現提交中少了乙個檔案，或者提交了多餘的檔案，或者發現提交中包含錯誤無法編譯，或者提交說明中出現了錯別字等等。 git 提供了乙個修改當前提交的快捷命令：git commit –amend，相信很多人都用過，不再贅述。

如果你發現錯誤出現在上乙個提交或其他歷史提交中怎麼辦呢？我有乙個小竅門，在《git權威指南》裡我沒有寫到哦。 比如發現歷史提交 54321 中包含錯誤，直接在當前工作區中針對這個錯誤進行修改，然後執行下面命令:

$


gitcommit--


fixup


54321
你會發現使用了 –fixup 引數的提交命令，不再詢問你提交說明怎麼寫，而是直接把錯誤提交 54321 的提交說明的第一行拿來，在前面增加乙個字首「fixup!」，如下： 

fixup


! 原提交說明
如果一次沒有改對，還可以再接著改，甚至你還可以針對這個修正提交進行 fixup，產生如下格式的提交說明： 

fixup


!fixup


! 原提交說明
當開發工作完成後，待推送/評審的提交中出現大量的包含「fixup!」字首的提交該如何處理呢？ 如果你執行過一次下面的命令，即針對錯誤提交 54321 及其後面所有提交執行互動式變基（注意其中的 –autosquash 引數），你就會驚嘆 git 設計的是這麼巧妙： 

$


gitrebase-i


--autosquash


54321^
互動式變基彈出的編輯器內自動對提交進行排序，將提交 54321 連同它的所有修正提交壓縮為乙個提交。 對於「提交做對」，很多開源專案還通過單元測試用例提供保障。對於這樣的專案，在提交**時往往要求提供相應的測試用例。

git 專案本身就對測試用例有著很高的要求，其測試框架也非常有意思。我曾經針對git的單元測試框架寫過部落格，參見： 復用 git.git 測試框架。 提交做好 僅僅做到提交做小、提交做對，往往還不夠，還要通過撰寫詳細的提交說明讓專案維護者（maintainer）信服，這樣才能夠讓提交盡快通過評審合入專案倉庫中。

git 對於提交說明的格式有著如下約定俗成的規定，不遵守這個約定的提交說明都不合格：

提交說明第一行是提交主題，是整個提交的概要性描述。 提交主題要用英文，不能出現中文，因為某些命令（如 git format-patch）會出現問題。

提交主題中可以新增字首（例如本例中的 receive-pack 是此次修改的模組名稱）。

提交主題（即提交說明的第一行）盡量保持在50位元組以內（gerrit 的commit_log檢查外掛程式似乎有著稍微寬泛一些的要求）。 這是因為對於像 linux、git 這樣的開源專案，是以郵件列表作為**評審的平台，提交主題要作為郵件的標題，而郵件標題本身有長度上的限制。 既然提到提交主題作為郵件標題，還要提及一點，你見過在郵件標題的結尾寫句號麼？所以提說明的第一句結尾不要加標點符號。

提交主題後的空行 必須要在提交說明的第一行和後續的提交說明中間留乙個空行！如果沒有這個空行，很多 git 客戶端會將連續幾行的提交說明合在一起作為提交描述。這樣顯然太糟了。

要讓評審者對提交信服，要為將來的**維護者留下線索，提交說明要回答如下問題：what——要解決什麼問題？什麼情況下會發生？ how——怎麼樣解決這個問題。why——為什麼這樣解決是合理的，比其他解決方法更好。

前面說過提交主題50個字元為限，提交說明的主體的每一行則以72字元為限，超過則斷行。 因為 github 在顯示提交說明時支援 markdown 語法， 所以作為乙個有品位的程式設計師學些 markdown 的語法，讓你的提交說明的可讀性變得更強吧。我總結過乙個 markdown 和其他文字標記語言的語法說明，可供參考：輕量級標記語言語法參考。

在提交說明最後是簽名區。簽名區可以看出這個提交的參與者、評審記錄等等。

做乙個有想法的程式設計師

許多程式設計師認為其工作任務只是負責後台邏輯的程式開發，對介面的布局莫不關心。實際上評價乙個程式設計師的優秀與否，是要從介面和業務邏輯兩方面來衡量的。雜亂無章的介面布局，許多程式設計師認為其工作任務只是負責後台邏輯的程式開發，對介面的布局莫不關心。實際上評價乙個程式設計師的優秀與否，是要從介面和業務...

做乙個有想法的程式設計師

許多程式設計師認為其工作任務只是負責後台邏輯的程式開發，對介面的布局莫不關心。實際上評價乙個程式設計師的優秀與否，是要從介面和業務邏輯兩方面來衡量的。雜亂無章的介面布局，只會給人留下 三流程式設計師 的印象。塗雅 在下文中通過乙個小專案為我們講解怎樣才算乙個優秀 有想法的程式設計師，才能坐上產品經理...

做乙個有想法的程式設計師

許多程式設計師認為其工作任務只是負責後台邏輯的程式開發，對介面的布局莫不關心。實際上評價乙個程式設計師的優秀與否，是要從介面和業務邏輯兩方面來衡量的。雜亂無章的介面布局，只會給人留下 三流程式設計師 的印象。塗雅在下文中通過乙個小專案為我們講解怎樣才算乙個優秀 有想法的程式設計師，才能坐上產品經理或...