文章

目前顯示的是有「Git」標籤的文章

如何處理已經 Push 的 Commit Message!

圖片
這種已經推(push)上來的沒辦法更改 Commit Message 跟內容 怎麼辦! 這種情況我會直接重切一條新的分支,重寫 Commit,底下是主要步驟: 把這幾次 Commit 的異動暫存(stash)起來從開發前的 Commit 切新分支(for 重寫 commit 用)把暫存(stash)的檔案套用到新分支開始重寫 Commit 做完 Commit 就把新切出來這條分支上傳回自己的 Repo,重發 Merge Request。 第一次做可能不熟,所以底下是每個步驟截圖: 步驟看起來很多,但做熟的話其實就只有幾個主要步驟而已,會越做越快! 1. 把這幾次 Commit 的異動暫存(stash)起來




2. 從在開發前的 Commit 切新分支(for 重寫 commit 用)

3. 把暫存(stash)的檔案套用到新分支
4. 開始重寫 Commit

Gitlab 合併請求 Merge Request 是什麼?

圖片
Gitlab 合併請求(Merge Request ) 一般在團隊開發的時候,為了避免工程師直接對主要 Repo 進行修改,會要求工程師從 專案的主要 Repo 複製一份這個專案的副本(Fork)回來工程師的電腦進行開發/除錯。 工程師開發完成後,如果要把電腦上最新版本的程式碼上傳回 專案的主要 Repo,就必須對 專案的主要 Repo 發送一個 合併請求,請 專案的主要 Repo 管理員進行程式合併。 當合併請求發送出去後,專案的主要 Repo 管理員可以在管理頁面上看見你的合併請求,這時管理員會進行一次 Code Review,管理員覺得程式沒問題,就會將工程師的程式合併回主線。

若管理員覺得這段程式碼有問題,也可以 Close 這次的 Merge Request

另外 Merge Request 等同於 Github 的 Pull Request
  - 可參考: 與其它開發者的互動 - 使用 Pull Request(PR) 上述流程如下圖:

Git 開發流程

圖片
Git 實際開發流程 真實開發的時候,除了有 Gitlab 上面的 主要 repo、自己的 repo 以外,還會有一份在本機開發的 本地 repo,
這份 本地 repo 是從 自己的 repo Clone 回來的。 注意:底下步驟 1 除了從主線 pull 最新版本的程式回來,也可以直接從主線切一條分支出來做開發(推薦後者)

推薦後者(直切從主線切出一條分支出來做 issue)的原因是:
實務上開發的過程中,一個工程師可能會同時掛多個 issue。假設突然出現一個緊急的 issue 時,你可以從主線再切一條新分支,用來處理緊急的 issue。把緊急的 issue 處理完成後,在切回原本開發的 issue 分支繼續原來的工作!這是前者辦不到的。


以下是 Git 實際開發的流程: 一般要開始做 issue 前,就會先從主線拉(pull)一份最新版本的程式(code base)回來做開發,開發的過程可能會有多個檔案被異動,也可能經歷多次 commit。開發完成後,為了避免與別人 push 回主線的程式碼發生衝突,一定會先做一次 Pull,
注意:做 Pull 時 Git 會自動幫你 Merge,這時會有以下幾種情況發生:Git 自動 Merge 成功,不發生衝突。Git 自動 Merge 失敗,發生衝突,需要你手動處理衝突。不管有沒有發生衝突,Merge 完後都會有一次合併程式的 Commit((合併程式也算異動))。做完 Pull & Merge 後,就可以把最新的 commit 推(push)回主線,完成本次 issue 的提交。


Git Commit Message 這樣寫會更好,替專案引入規範與範例

圖片
Commit Message 跟寫程式註解還蠻像的,
最好可以寫下「為什麼」你要作這樣的異動,
而不是單單只記錄下你做了「什麼」異動。 Commit Message 最好兼俱 Why 及 What,讓日後進行維護人員更快進入狀況。 Commit Message 這樣寫會更好:做 issue 的時候,不應該一次 Commit 所有異動!應該獨立 Commit 每個不同意義的異動,這樣 commit 訊息才會跟異動的程式碼有關聯。每次 Commit 都是針對異動的檔案做說明:Why & What。這樣的 Commit Message 能讓日後的維護人員更快進入狀況每次 Commit 都加上 issue 編號,方便追蹤相關的程式異動原因。 若 Commit Message 寫得妥當,在閱讀追蹤程式碼的意圖會相當容易。如果只把 Git 當作版本控制,隨意撰寫 Commit Message 就太可惜了! 不能只把 Git 當作程式碼的 FTP,要把 Git 當作歷史查閱的工具才拿發揮 Git 的功能。 好與不好的真實案例用一個小插曲證實 Commit 訊息的重要性
上面 PPT 是我在工作中遇到的兩個案例,範例中包含「好的 Commit Message」與「不良的 Commit Message」。
在範例中可見: 良好的 Commit Message: 如何在「一年後」讓維護人員進入狀況不良的 Commit Message: 如何在「一個月內」讓維護人員找不出程式異動的原因。 Commit Message 之規範 在撰寫 Git 與 SVN 等版本控制軟體 Commit Message 時,可以參照國外 AngularJS 團隊的規範: AngularJS Git Commit Message Conventions 以下為這套訊息規範的展示與說明:
Commit Message 規範範例:

Commit Message 規範範例解析:
Commit Message 規範組成:Header: <type>(<scope>): <subject> - type: 代表 commit 的類別:feat, fix, docs, style, refactor, test, chore,必要欄位。 - scope 代表 commit 影響的範圍,例…