WadeHuang的學習迷航記

這種已經推(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 ） 一般在團隊開發的時候，為了避免工程師直接對主要 Repo 進行修改，會要求工程師從 專案的主要 Repo 複製一份這個專案的副本（Fork）回來工程師的電腦進行開發/除錯。 工程師開發完成後，如果要把電腦上最新版本的程式碼上傳回 專案的主要 Repo ，就必須對 專案的主要 Repo 發送一個 合併請求 ，請 專案的主要 Repo 管理員進行程式合併。 當合併請求發送出去後， 專案的主要 Repo 管理員可以在管理頁面上看見你的合併請求，這時管理員會進行一次 Code Review，管理員覺得程式沒問題，就會將工程師的程式合併回主線。 若管理員覺得這段程式碼有問題，也可以 Close 這次的 Merge Request 。 另外 Merge Request 等同於 Github 的 Pull Request   - 可參考:  與其它開發者的互動 - 使用 Pull Request（PR） 上述流程如下圖： ​

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 的提交。 ​

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, sty