一、多人協作場景一,同一分支多人協作

在 windows 環境下,再 clone 同⼀個項⽬倉庫,來模擬⼀起協作開發的另⼀名⼩夥伴

先在開發者1環境下創建與遠程倉庫的dev分支相聯繫的本地dev分支:

  • 修改文件並提交,推送遠程:
  • 添加成功:

在開發者2環境下創建本地dev分支:

與遠程倉庫的dev分支建立聯繫git branch --set-upstream-to=[遠程分支名] [本地分支名]

修改文件並提交,推送遠程:

  • 遇到問題了,提交失敗,我們遠程文件與本地文件有衝突了,也提供了方法,先pull遠程,自己本地修改,再提交。就跟前面的合併衝突解決方式一樣。
  • 添加成功:

將內容合併進master分支兩種方式:

  1. 先在本地合併進master,再推送master
  2. 在遠程倉庫,先提交Pull Request 申請單,管理員看沒問題就合併了。(推薦方式)

二、多人協作場景一,不同分支多人協作

多需求需要多⼈同時進⾏開發,是不會在⼀個分⽀上進⾏多⼈開發,⽽是⼀個需求或⼀個功能點就要創建⼀個 feature 分⽀。

開發者一,創建本地分支feature-1,直接推送到origin,遠程倉庫會自動創建對應分支。

  • 開發者二,創建本地分支feature-2,直接推送到origin,遠程倉庫會自動創建對應分支。

將內容合併進master合併feature2為例:當有衝突的時候,在本地先合併merge,解決後再合併dev。

遠程倉庫刪除了的分支,git branch -a本地依然可以看見:

git remote prune origin解決:

三、企業級開發模型

3.1 系統開發環境

⾔歸正傳,對於開發⼈員來説,在系統開發過程中最常⽤的⼏個環境必須要了解⼀下:

  1. 開發環境:開發環境是程序猿們專⻔⽤於⽇常開發的服務器。為了開發調試⽅便,⼀般打開全部錯誤報告和測試⼯具,是最基礎的環境。
  2. 測試環境:⼀個程序在測試環境⼯作不正常,那麼肯定不能把它發佈到⽣產機上。該環境是開發環境到⽣產環境的過渡環境。
  3. 預發佈環境:該環境是為避免因測試環境和線上環境的差異等帶來的缺陷漏測⽽設⽴的⼀套環境。其配置等基本和⽣產環境⼀致,⽬的是能讓我們發正式環境時更有把握!所以預發佈環境是你的產 品質量最後⼀道防線,因為下⼀步你的項⽬就要上線了。要注意預發佈環境服務器不在線上集成服 務器範圍之內,為單獨的⼀些機器。
  4. ⽣產環境:是指正式提供對外服務的線上環境,例如我們⽬前在移動端或PC端能訪問到的APP都是⽣產環境。 這⼏個環境也可以説是系統開發的三個重要階段:開發->測試->上線。⼀張圖總結:

3.2 Git 分支設計規範

對於開發⼈員來説,⼀般會針對不同的環境來設計分⽀,例如Git-Flow模型:

分⽀

名稱

適⽤環境

master

主分⽀

⽣產環境

release

預發佈分⽀

預發佈/測試環境

develop

開發分⽀

開發環境

feature

需求開發分⽀

本地

hotfix

緊急修復分⽀

本地

  • master 分支:
  • master 為主分⽀,該分⽀為只讀且唯⼀分⽀。⽤於部署到正式發佈環境,⼀般由合併release 分⽀得到。
  • 主分⽀作為穩定的唯⼀代碼庫,任何情況下不允許直接在 master 分⽀上修改代碼。
  • 產品的功能全部實現後,最終在master分⽀對外發布,另外所有在master分⽀的推送應該打標籤(tag)做記錄,⽅便追溯。
  • master 分⽀不可刪除。
  • release 分⽀:
  • release 為預發佈分⽀,基於本次上線所有的 feature 分⽀合併到 develop 分⽀之後,基於 develop 分⽀創建。可以部署到測試或預發佈集羣。
  • 命名以 release/ 開頭,建議的命名規則: release/version_publishtime 。
  • release 分⽀主要⽤於提交給測試⼈員進⾏功能測試。發佈提測階段,會以 release 分⽀代碼為基準進⾏提測。
  • 如果在release 分⽀測試出問題,需要回歸驗證 develop 分⽀看否存在此問題。
  • release 分⽀屬於臨時分⽀,產品上線後可選刪除。
  • develop 分⽀:
  • develop 為開發分⽀,基於master分⽀創建的只讀且唯⼀分⽀,始終保持最新完成以及 bug 修復後的代碼。可部署到開發環境對應集羣。
  • 可根據需求⼤⼩程度確定是由 feature 分⽀合併,還是直接在上⾯開發(⾮常不建議)。
  • feature 分⽀ :
  • feature 分⽀通常為新功能或新特性開發分⽀,以 develop 分⽀為基礎創建 feature 分⽀。
  • 命名以feature/ 開頭,建議的命名規則: feature/user_createtime_feature 。
  • 新特性或新功能開發完成後,開發⼈員需合到 develop 分⽀。
  • ⼀旦該需求發佈上線,便將其刪除。
  • hotfix 分⽀
  • hotfix 分⽀為線上 bug 修復分⽀或叫補丁分⽀,主要⽤於對線上的版本進⾏ bug 修復。當線上出現緊急問題需要⻢上修復時,需要基於 master 分⽀創建 hotfix 分⽀。
  • 命名以 hotfix/ 開頭,建議的命名規則:hotfix/user_createtime_hotfix
  • 當問題修復完成後,需要合併到 master 分⽀和 develop 分⽀並推送遠程。⼀旦修復上線,便將其刪除。