管理原則

• 所有Branch 命名改為專案名稱-平台，以利管理對應的專案/平台
  • SocialMap-Backend
  • SocailMap-Web
  • SocialMap-iOS
• 每一個Repo 在Origin上面僅保留master (main)/ test/ deveop 三支 branch。
  • master (main)做為保留 production版本用，為當前正式環境版本
  • test 作為保留 test 版本用，為當前測試版本
  • develop 作為開發用，為當前開發穩定版本
• 使用tag 標記版號

協同開發操作原則

• 一個Feature/ fix 對應一個 branch/ PR (Pull Request)

  • 每一個新的Feature 就請分岔一個 branch 出來進行，完成該Feature/ Fix後就請發PR
  • 一個Request 不接受複數個 Feature/ Fix，除非高度相關聯或互相影響

• 所有操作都不要對 Origin !!!

  • 開發人員請 fork 整個專案到自己的 repo，開發的commit 請只 push 到自己的repo，不要push 到origin。
  • 避免任何個人的 feature/ fix commit 直接上到Origin，以保持 Repo 乾淨，方變管理。
  • 從自己的 repo 發送PR (Pull Request) 到 origin/develop

  <aside> 💡 由於github 免費版private repo 的限制，沒有辦法enable fork，所以這邊還是要繼續在origin上push

  </aside>

• PR 原則：

  • 在發 PR 前，記得 reset 到最新的 develop 再發
  • 詳細rebase/ reset，請參考Reset 與 Rebase
  • 可以使用squash 將多個commit 整理合併成幾個重點commit，避免過多分散的commit。

Branch Name 命名原則

為了方便SourceTree管理，請注意以下命名規則

Dev/<SprintNumber>/<Feature/Fix/Refector>/<Ticket#>-<TicketName>

例如

Dev/S15/Feature/925-GoogleAnalytic

Dev/S15/Fix/1028-NoImagePlaceholder

Dev/S16/Refector/1253-PrintLogMessage

Commit 原則

請參考 Commit Message撰寫原則