目錄:
1-什麼是版本控制系統
2-工做流簡介
3-集中式工做流
4-功能分支工做流
5-GitFlow工做流git
小記:
初看差點放棄了,不事後面仍是有乾貨的,能夠和廖老師教程相輔相成
2018-11-8-廁所感悟一則:
聯想到pt裏的 <伺服> ,我忽然以爲,pt網站是否是就至關於 <分佈式的服務器> ,每一個人都做爲本身已下載資源的服務器,儘可能24小時在線或者開機作種,以提供給他人下載所需資源。
------------------------------------------
1、什麼是版本控制系統
------------------------------------------
2、工做流簡介
2.1 集中式工做流-方面SVN遷移過來-我的(3-5人)
2.2 功能分支工做流-稍大團隊(8-12人)
2.3 GitFlow工做流-實際開發中經常使用但會稍微簡化-整個公司
2.4 Forking工做流-適合大型團隊使用-跨國合做
Pull Requests-請求合併-面試常問的,注意一下
除了第一個,剩下三個都會用到github
------------------------------------------
3、集中式工做流-適合小型團隊
內含demo:
老師說,在GitHub新建倉庫的時候,選了.gitignore和開源協議
還說不選開源協議會比較吃虧???面試
步驟:
初始化倉庫-->全部人克隆倉庫-->小明、小紅開發功能-->小明提交-->小紅提交但失敗-->小紅先pull再push服務器
------------------------------------------
4、功能分支工做流
<這節還受益良多,之前理解得不太好的一些東西明白了>
一般不在master上開發,而是建立不一樣分支,如功能分支、bug分支等
以此來保證master裏的代碼不被污染
(當代碼還有點問題可是又怕丟失的時候,不能夠傳到master裏不然master裏就有壞的代碼了,這時能夠先傳到功能分支裏,這個分支最終是要刪除的,並且能夠本身負責一個分支)框架
演示:
功能分支開發完成後用pull request請求有權限的人(組長之類)合併到master分支
組長有權限,能夠選擇merge該功能到哪一個分支,或者不merge分佈式
------------------------------------------
5、GitFlow工做流-企業經常使用
GitFlow 工做流定義了一個圍繞項目發佈的嚴格分支模型。雖然比功能分支工做流複雜幾分,但提供了用於一個健壯的用於管理大型項目的框架。
發佈分支:
維護分支:當有bug時
GitFlow流五大分支:
主幹分支
熱修復分支
預發佈分支
開發分支
功能分支ide
一個demo:
<一> 開發環節
1-首先建立develop分支-由有權限的人
全部開發工做都在這個開發分支下完成
2-而後開發人員先pull後在develop分支基礎上建立本身的功能分支
3-開發人員小明開發並推送後,可在GitHub裏發起pull request
4-預發佈人員小明在本地切換到develop分支,建立預發佈分支
<注意了> :預發佈分支這個版本是提供給測試人員用的,測試人員把它pull下來作測試
5-測試完成,沒有問題了,再從預發佈分支下,向master分支發起pull request請求
<二> 發佈環節
1-本地打標籤,做爲里程碑式的第一個發佈版本
2-本地打好標籤之後,推送到遠程
<三> 後期修復bug
1-用戶發現bug,在issue裏提交一個
2-
上線:checkout下,在標籤1.0.0基礎上建立新分支
(上一部分寫到,自動生成的問題編號是#4,故hotfix分支命名爲hotfix_0004對應 該問題)
svn
3-在本地的hotfix_0004分支下,修復bug,提交併推送到遠程庫
4-開發人員以爲沒有問題了,能夠在GitHub裏發起pull request
5-在本地master分支下,pull(獲得補丁),並新建標籤1.0.1-RELEASE而後push到遠程(勾選包括標籤)
6-開發完成後,把不須要的分支刪掉:
GitFlow工做流簡化:feature分支能夠省略,其餘都不能
------------------------------------------
Forking工做流
大致操做和廖老師講的一致
在實際開發中不怎麼用
但加入開源社區,或者想作開源貢獻時會用到
------------------------------------------
實際開發中經常使用的工做流:
一個是集中式,一個是GitFlow