Github!現代人不能不知道的協同合作平台

合併原則：

• feature→dev

  • 將功能拆分成feature
  • 工作結束合併回dev

• 其他文章

  Day 28 - GIT 團隊協作 談 流程管理 02 GitHub Flow - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

主要流程：

1. 建立分支
2. 進行合併：
   • 本地：透過merge
   • 遠端：透過PR(pull request)
     • 自動檢視是否有合併衝突，透過code review來進行溝通，直到雙方同意才進行合併
     1. 點擊new pull request
     2. 確認合併分支
     3. 輸入標題及描述、reviewrs、assignees、label、project、milestone
     4. 點擊create pull request
     5. 進行review

協作Flow

1. Git flow
2. Fork flow

Git flow

多個分支

策略

1. main(master)：[production]主要部署分支

   • v1.0
   • v2.0

2. hotfix：main分支需要緊急修復的分支，合併回main及dev後刪除

   • hotfix-menu

3. release：部署到測試環境或是UAT，合併回main及dev後刪除

   • release-v1.1
   • release-v1.2
   • release-v2.1

4. dev：[develop]主要開發分支

5. feature：開發分支(新需求)，合併回dev後刪除

   分支名稱建議: feat/linescan feat/integrate-checkin-api feat/add-homepage-styling feat/rewrite-lightbox-styling

6. bug：不需要緊急修復的分支，合併回dev後刪除

   允許下一次部署才修復

   • bug001-browser

Github Flow | Fork flow

策略

少數主要分支-main，相較於git flow不用處理hotfix, release分支問題

1. 建立分支: 分支命名需要清楚

   分支名稱建議: feat/add-linescan feat/integrate-checkin-api style/add-homepage style/rewrite-lightbox

2. 開發與提交

3. 建立PR：編輯修改摘要或是解決的問題，並可以連結issue

   • 當PR合併後issue會自動關閉

4. 討論

5. 測試異動內容

6. 合併前部署：透過github action可部署於測試或是UAT環境

7. 合併與刪除分支

<aside> ❓ 希望所有合併到主線的操作都透過guthub介面，當主線有更新，會建議用merge還是rebase同步到功能支線呢?

chartGPT: 建議使用 merge 而不是 rebase 來同步到功能分支。

使用 merge 的好處是它保留了主線和功能分支的獨立歷史記錄。當你將主線的變更合併到功能分支時，GitHub 會在功能分支上創建一個新的合併提交，保留了主線和功能分支的獨立提交歷史。這樣做可以確保主線和功能分支的提交歷史保持清晰可見，並且可以更容易地追踪和管理變更。

另外，使用 merge 還可以避免 rebase 時可能產生的衝突問題，因為 rebase 會將功能分支的提交基地移動到主線的最新提交上，這可能導致衝突或不一致的提交歷史。

如果合併回來有衝突→處理衝突→完成後直接提交新的節點。→開啟PR

</aside>

<aside> ❓ 那rebase的使用情境?

chartGPT: Rebase 主要用於整理提交歷史，可以幫助保持提交歷史的清晰，減少不必要的合併提交，使用情境通常是在以下幾種情況下：

1. 整理提交歷史：當你的分支上有很多次的小型提交，而你希望將它們合併成更少的、更有意義的提交時，可以使用 rebase 來整理提交歷史，讓歷史記錄更清晰易讀。

2. 避免合併提交：有時候在進行合併操作時，可能會產生一個合併提交，這個提交包含了所有被合併的變更。如果你想要保持提交歷史的清晰，可以使用 rebase 來避免合併提交，將你的分支重新基於主線的最新提交，這樣就不會產生合併提交了。

3. 同步主線變更：當你的分支與主線有衝突時，你可以使用 rebase 將你的分支基地移動到主線的最新提交上，解決衝突，然後再將你的分支合併回主線。

   (這點不是很好直行，要謹慎使用)

</aside>