iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 11
0
Software Development

如何一步步實踐TDD (測試驅動開發)系列 第 11

Git 版本控制 與 Commit

今天讓我們來談談關於 版本控制 充個天數

Git 幾乎是現在軟體用來做版本控制的主流,而本篇當然還是因為跟 TDD 有關,至於 Git 的好處及如何使用,應該能輕鬆找到非常多的教學資源。

Commit

在 Git 中每一個版本被稱為一個 commit,每當我們對程式碼做了一些更新時,我們會將這次新增與修改的檔案加入新的一次 commit。

然而多少新的程式碼,應該被稱作一個「新的版本」?何時要產生一個「新的 Commit」,這是一件模糊的事情。

Commit Message

每次送出 Commit 時,Git 會要求輸入一段文字,稱為 commit message。

commit message 可以讓人快速瀏覽以前的版本紀錄,如果寫得太模糊不清,那我們要回去查看程式碼的版本,是在哪一個 commit 裡。

因此有人對於 commit message 提出了七個規範 How to Write a Git Commit Message,想要看中文翻譯的也可以參考這篇

其中第二點如下:

限制標題最多只有 50 字元。

目的是為了 git log 顯示時,可以一次看到完整的 commit message,超過50字的部分會表示成 ...,例:「Add a new fifty-word func...」。

頻率

為了讓 commit message 不會太長,因此更新的程式碼要嘛是沒有很多,要嘛就是容易描述的同一功能,這樣後續比較容易追查版本,進行版本控制才有意義。

因此要避免一次 commit 太多內容,當然太過繁瑣的 commit 同樣也會造成困擾。

回到 TDD 的使用,TDD 會漸進式的一步一步產生程式碼,每次循環都會產生出可執行的程式碼跟測試,如果一次循環就送交一次 commit 也許又太頻繁,可以經過幾個紅綠燈循環、完成一小組較緊密的功能後,再送交一次 commit。

先思考要做哪些 Commit

可以試著在開始 Coding 之前,就先構思要完成哪些部分,總共多少功能、哪些 commit,把每個 commit 預計的 commit message 寫下來,之後才開始寫 code,即使不是 TDD 同樣也能這麼做。

整理 commit 們

如果寫完一大段之後,才發現自己的 commit 太繁瑣零碎了,也可以回去整理自己的 commit,將多個 commit 合成一個,可以參考 【狀況題】把多個 Commit 合併成一個 Commit,不過如果是多人協作請記得不要修改已經 push 上去的部分。

TDD 與版本控制

TDD 時搭配使用著 Git 做版本控制,當測試或產品程式沒寫好、想要倒回去到前一些些的版本時,就相當容易,學 TDD 時順便學個 Git 絕對也是不虧的。


上一篇
如何在一個環境開始 TDD
下一篇
Mock 與 範例四 (Mockery, PHP)
系列文
如何一步步實踐TDD (測試驅動開發)30

尚未有邦友留言

立即登入留言