Git for Professionals
Last updated
Was this helpful?
Last updated
Was this helpful?
避免單次 commit 大量修改，導致不易理解修改內容，即 降低 Commit 的顆粒度。
一致的 Commit Message，搭配簡短的 Subject 和更多細節的 Body 來描述修改內容。
Git WorkFlow 主旨在於降低團隊錯誤和衝突的可能性。
PR 主要使用在需要第三者檢驗 Code，或者是想對開放專案貢獻時提出建議時。
在協同合作時，應避免使用 rebase，修改歷史紀錄，可能導致混亂。
包含大量修改的 Commit，會讓你的合作夥伴不知道在這個更動做了哪些修改，導致難以判斷。
可以透過 Git staging area(暫存區)，來選擇適合的修改，在進行 Commit 。
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 空白一行。
透過一條 Mainline development (主線)，Ex: master or main，
來完成持續整合許多的小 Commit 或不同的 branch 結果，並且可以達到高品質的測試和標準。
非主線的其他分支，能夠達到強化 WorkFlow 的功用，
可以針對 hotFix 、feature 或 develop 來做區分，來達到自行管理和發佈時間。
通過存在去完成專案的每個不同階段的 dev life cycle (開發生命週期)。
有一個特點在於，不會有直接的 commit 在這兩個分支上，通常是透過 PR 合併。
如：develop / master / main 分支。
一般用於 bug fixes(修正 Bug), refactoring(重構), experiments(實驗性) 等場景。
特點在於這些分支完成整合後，會被合併進 Long-Running ，並被刪除。
如：feature / hotfix 資料夾結構下的分支。
Q: 如何建立一個最好的分支策略? A: 依照專案大小、版本循環和 Team 大小來評估，或是直接使用常用策略。
相當簡單，當有 Feature 或 hotFix 都是從 master 直接分支出來，完成再合併回去。
較複雜的結構，相對也有較多的規則。
整體分支結構
Long-running：master + develop
Short-Lived：features, releases, hotfixes
參考文章
又可縮寫成 PR，當修改幅度大需要他人檢視 Code 給予回饋，即一般稱之為 Code Review。 當檢視的人覺得沒問題，會再將其合併至 master 或 develop 分支，就結束一個 PR 循環。
或想要對 Open Repository 做貢獻時，卻沒有權限能夠 push，可以透過發 PR 給作者群， 請他們 Review 修改建議，並決定是否能夠合併進去。
不是一個標準 Git 的核心功能，可能不同的各家平台(Github, gitlab, bitbucket)，
都會有一些些微的不同。
當整合時資源的修改不同時，程式無法判斷何處為合理的修改範圍，就必須手動解決。
幾個經常發生的時機：merge , rebase , pull, cherry-pick, stash apply。
在合併時，若有明顯的差異，Git 會 自動的 產生一個額外的 Commit 來完成。
若沒有明顯差異，一般的 git merge 會是屬於 For-Forward (自動快轉模式)，
直接將節點標籤移動到同一個點，而不會有額外的 Commit。
Q：若沒有明顯差異，是否也可以印出線圖?
A：可以，透過 git merge branch --no-ff
Q：合併沒有完成，如何回到原本的版本?
A：git merge --abort
和 Merge 類似，但是透過修改歷史紀錄的方式，來完成合併，當只想要一條乾淨的直線時，可使用。
將已 Commit 的內容，回復到某個節點(移除原本的節點)，即透過某個基準點上作為參考依據，
在下次 push 時，一起更新上去，看起來就會像一條直線。
當在協同合作時，不建議使用 rebase 覆寫在已經 Push 到 remote 的儲存庫，
可能會導致許多的混亂。
有害的 GitFlow： 實戰經驗1： 實戰經驗2： 兩者比較：