Git for Professionals

概念總結

  • 避免單次 commit 大量修改，導致不易理解修改內容，即 降低 Commit 的顆粒度。

  • 一致的 Commit Message，搭配簡短的 Subject 和更多細節的 Body 來描述修改內容。

  • Git WorkFlow 主旨在於降低團隊錯誤和衝突的可能性。

  • PR 主要使用在需要第三者檢驗 Code，或者是想對開放專案貢獻時提出建議時。

  • 在協同合作時，應避免使用 rebase，修改歷史紀錄，可能導致混亂。

完美的 Commit

🌟 Add the right changes! (只新增合理的 Commit)

🌟 Compose a good Commit Message! (搭配一段好的 Commit 訊息)

包含大量修改的 Commit，會讓你的合作夥伴不知道在這個更動做了哪些修改，導致難以判斷。

可以透過 Git staging area(暫存區)，來選擇適合的修改，在進行 Commit 。

一致性的 Commit Message

主要內容

Subject：concise summary of what happened(簡短描述修改內容)

Body：more detailed explanation(若需要更多的細節)

  • What is new different than before? (和之前有什麼分別)

  • What the reason for the change? (修改的理由是什麼)

  • Is there anything to watch out for? (有什麼需要注意的) / anything particularly remarkable? (任何特別需要標注的東西)

Body 一般與 Subject 空白一行。

https://github.com/angular/angular/blob/master/CONTRIBUTING.md

分支建立策略

高度依賴 Team 和 其大小 ，討論出合理的 Branching WorkFlow，

來避免 mistakes(錯誤) 和 collisions(衝突)。

整合改變(Integrating Changes)

透過一條 Mainline development (主線)，Ex: master or main，

來完成持續整合許多的小 Commit 或不同的 branch 結果，並且可以達到高品質的測試和標準。

結構化發佈(Structuring Releases)

非主線的其他分支，能夠達到強化 WorkFlow 的功用，

可以針對 hotFix 、feature 或 develop 來做區分，來達到自行管理和發佈時間。

兩種類型的分支

Long-Running

  • 通過存在去完成專案的每個不同階段的 dev life cycle (開發生命週期)。

  • 有一個特點在於，不會有直接的 commit 在這兩個分支上，通常是透過 PR 合併。

如：develop / master / main 分支。

Short-Lived

  • 一般用於 bug fixes(修正 Bug), refactoring(重構), experiments(實驗性) 等場景。

  • 特點在於這些分支完成整合後，會被合併進 Long-Running ，並被刪除。

如：feature / hotfix 資料夾結構下的分支。

Q: 如何建立一個最好的分支策略? A: 依照專案大小、版本循環和 Team 大小來評估，或是直接使用常用策略。

常用策略

GitHub Flow: https://guides.github.com/introduction/flow/

  • 相當簡單，當有 Feature 或 hotFix 都是從 master 直接分支出來，完成再合併回去。

GitFlow

  • 較複雜的結構，相對也有較多的規則。

  • 整體分支結構

    • Long-running：master + develop

    • Short-Lived：features, releases, hotfixes

參考文章

有害的 GitFlow：https://www.endoflineblog.com/gitflow-considered-harmful 實戰經驗1：https://blog.hellojcc.tw/the-flaw-of-git-flow/ 實戰經驗2：https://blog.hellojcc.tw/a-better-git-flow/ 兩者比較：https://blog.wu-boy.com/2017/12/github-flow-vs-git-flow/

Pull Requests 拉取請求

基本單位為 branch(分支)，不會是一個獨立的 Commit。

又可縮寫成 PR，當修改幅度大需要他人檢視 Code 給予回饋，即一般稱之為 Code Review。 當檢視的人覺得沒問題，會再將其合併至 master 或 develop 分支，就結束一個 PR 循環。

或想要對 Open Repository 做貢獻時，卻沒有權限能夠 push，可以透過發 PR 給作者群， 請他們 Review 修改建議，並決定是否能夠合併進去。

不是一個標準 Git 的核心功能，可能不同的各家平台(Github, gitlab, bitbucket)，

都會有一些些微的不同。

Merge Conflicts 合併衝突

當整合時資源的修改不同時，程式無法判斷何處為合理的修改範圍，就必須手動解決。

幾個經常發生的時機：merge , rebase , pull, cherry-pick, stash apply。

Merge

在合併時，若有明顯的差異，Git 會 自動的 產生一個額外的 Commit 來完成。

若沒有明顯差異，一般的 git merge 會是屬於 For-Forward (自動快轉模式)，

直接將節點標籤移動到同一個點，而不會有額外的 Commit。

Q：若沒有明顯差異，是否也可以印出線圖?

A：可以，透過 git merge branch --no-ff

https://gitbook.tw/chapters/branch/merge-commit.html

Q：合併沒有完成，如何回到原本的版本?

A：git merge --abort

Rebase

和 Merge 類似，但是透過修改歷史紀錄的方式，來完成合併，當只想要一條乾淨的直線時，可使用。

將已 Commit 的內容，回復到某個節點(移除原本的節點)，即透過某個基準點上作為參考依據，

在下次 push 時，一起更新上去，看起來就會像一條直線。

當在協同合作時，不建議使用 rebase 覆寫在已經 Push 到 remote 的儲存庫，

可能會導致許多的混亂。

參考資料

Previous目錄NextStack / Heap

Last updated

Was this helpful?