Browsing Category

git

git 學習資源

Posted on 2017-09-24

learningGitBranching 是我學 git 的最佳方案
年幼無知時學 git 覺得它是一個黑盒子，完全搞不懂是怎麼運作，一直撞牆學起來很沮喪。

在 learningGitBranching 裡每個指令所產生的改變都會視覺化呈現，讓你免去用腦袋或紙筆把狀態畫出來( 它直接 GUI 呈現 )，你可以透過觀察改變而瞭解指令背後的含義。

在開始使用 learningGitBranching 之前，推薦你搭配 Pro Git 這本書服用 (簡中版在這) ，瞭解每個指定的定義會讓你記得更久。

進階班

為什麼要學 git?

回過頭來想一下這個問題，為什麼我們要學 git？

與全世界的工程師合作

沒有一個人可以獨自完成超大型軟體，如果你跟我一樣想跟世界上所有工程師合作，那就必須要學會如何正確的使用版本控制工具，而現今最最流行的版本控制工具就是 git 。

與未來的自己合作

如果你曾經做一個專案一段時間(超過一年)，你會發現人腦的記憶是很不可靠的，甚至會覺得我當初是腦殘嗎？為什麼會這樣寫？這個時候你會感謝版本控制留下足跡，讓你有些脈絡想起當初的事發原因。

大多數的人會拿 git 的優點來探討，因為寫的人已經很多了，這裡就引用別的人為什麼選擇 Git

Git commit 怎麼寫？

Posted on 2017-09-20

先講結論， commit log 格式應該這樣：

[ticket_number] type: subject

git commit -m "[#3345678] refactor: for readability"

// titcket_number:
票號，讓 SCM 依據票號回報開發進度回專案管理系統 (JIRA, Track 等系統)。

// type:
1. feat: 新功能 (feature)
2. fix: 修正 bug
3. docs: 文件
4. style: 格式
5. refactor: 重構
6. test: 新增測試
7. chore: 構建過程或輔助工具的變動

// subject:
著重於為什麼 (Why) 而不是做了什麼 (How) ，因為你的程式碼已經說明這個部分。

為什麼要規範 Commit message?

在討論這個問題之前，先看一段 log。

commit 0c34264a9e93d31bc4dc6c2fa1c8817365af1baf
Author: Liyao <gliyao@gmail.com>
Date:   Sat Jun 10 00:12:32 2017 +0800

    temp

commit aad94a2c252b91566c335c4c027f7ffef41feca5
Author: Liyao <gliyao@gmail.com>
Date:   Fri Jun 9 23:46:01 2017 +0800

    temp

commit 4f1736d25f7b02136a17ccc9652c53fd298c005b
Author: Liyao <gliyao@gmail.com>
Date:   Fri Jun 9 23:45:26 2017 +0800

    temp

commit 6547eb6415811101fd9239435a64f270398e4069
Author: Liyao <gliyao@gmail.com>
Date:   Fri Jun 9 08:15:12 2017 +0800

    temp

最近的幾個 commit 出了問題，請問是哪一個改壞了程式碼？

如果你的隊友寫了個這樣的 commit message 你會怎麼想？

我想我舉的例子是有些極端，但我還很菜的時候也寫過類似這樣的 commit message 。現在已經成長了，不應該在造成別人的困擾，更不用說在未來回來看這段 log 的人很可能就是你自己。

這樣規範帶來的好處

票號是最重要的部分，一定要將票號加在裡面，才能夠讓開發進度及問題能夠在軟體專案管理系統裡追蹤，加快開發的腳步。

請注意 票號 應該寫在最前面，避免機器人自動幫你寫回專案管理系統時漏抓。

type 類型，幫助讀 log 的人可以快速分類。假如今天是要找某一個功能完成的時間點，只要過濾 log 中包含 feat: 的部分，就可以快速找到。

它還幫助你列出兩個版本之間的 log，無論是列出某段時間的修復 log，或是列出所有 feature 並自動寫成 change log 文件。

這些規範最終的目標就是幫助你更快找到回家的路。

Reference

git 軟體開發

為什麼導入 Gitlab CI

Posted on 2017-09-17

這篇文章說明我們團隊(KKTOWN iOS team) 已經有 Jenkins CI 仍然導入了 Gitlab CI 的原因。

Jenkins 算是 CI 界裡的資深前輩，它不容易出錯又有許多外掛可以使用，可以做很多細部調整，無論是整合進 Slack 或是在專案管理軟體(JIRA, Track 等等) 上依據票號更新資料都難不倒它。

在我們理想的開發流程還是有 Jenkins 不足的地方。怎麼說呢？

Jenkins 是以分枝的異動作為 Job 的驅動，簡而言之是某個分支資料改變時，Job 才會開始執行。 因此我們必須手動的為每一個分枝建立其相對應的 Job 。

在對產品有品質要求的前提下，即便只是修正一個小問題也應該建立一個 Job 來確保程式碼沒被改壞。

凡事要手動的東西就有可能忘記。

我們在開發期間確保程式碼品質的最低標準就是在把程式碼推上 repo 之前跑過一次單元測試。BUT! 無論你或你的團隊成員，總是有可能不小心沒跑測試就推 code，如果審核程式碼的人又剛好忘記檢查這次的修改是否跑過最基本的 Build 跟測試，就很可能導致壞的程式碼被合併到主要的分枝中(dev 或是 master)。

於是我思考有沒有可能強制每一個分支都自動測試？

Gitlab CI 採取的是不一樣的架構，每一個分支的任何異動都會自動執行 Job，等於腳本一寫好會強制套用到所有分支上，並且只有 Job 執行完之後，且程式碼沒有任何錯誤，才能在 gitlab 頁面上合併分枝。

這麼一來強制且自動規範了必須通過測試才能合併的規範，也不讓我們有任何可以偷懶可以忘記的機會，進一步增加程式碼穩定度，提昇對程式碼的信心。

並且讓審核程式碼的人(Code reviwer) 可以專心做一件事情，而不用在 SCM 頁面與 CI 頁面中來回切換，直接在 PR 頁面上可以獲取所需要的全部資訊。

總結

最後我們 Jenkins CI 與 Gitlab CI 兩套並行，讓兩個不同的 CI 工具各自發揮所長。

自動化保護每一個分支，不讓我們有機會偷懶
程式碼審核(Code review) 整合到一個頁面中，減輕審核的負擔。

最重要的是，確保每一個分支合併前都可以成功編譯建置與測試作為提升程式碼品質的一環。