柚子快報激活碼778899分享：git分布式版本控制系統(tǒng)（六）

http://yzkb.51969.com/

目前世界上最先進的分布式版本控制系統(tǒng)

官方網(wǎng)址：https://git-scm.com

學習目標：

1 了解 git 前世今生 2 掌握 git 基礎概念、基礎操作 3 各種 git 問題處理 4 互聯(lián)網(wǎng)常用 gitflow(工作流程規(guī)范) 5 git 代碼提交規(guī)范 6 git 分支管理及命名規(guī)范

代碼提交規(guī)范

Commit message

我們每一次提交必定是有特殊的行為，或是開發(fā)新功能、或是修復bug等等。我們針對不同的操作有如下的分類： type 必填，commit 的類型 ?feat: 開發(fā)新的功能 ?fix: 修復bug ?refactor: 代碼重構 ?docs: 文檔修改 ?style: 代碼格式修改, 注意不是 css 修改 ?test: 測試用例修改 ?perf: 改善性能 ?build: 變更項目構建或外部依賴（例如scopes: webpack、gulp、npm等） ?chore: 其他修改, 比如構建流程, 依賴管理. ?revert: 代碼回退 ?而commit的格式也有標準格式: ?scope: commit 影響的范圍, 比如: route, component, utils, build… ?subject: commit 的概述 ?body: commit 具體修改內(nèi)容 ?footer: 一些備注, 通常是 BREAKING CHANGE 或修復的 bug 的鏈接 scope 可選，表示影響的范圍、功能、模塊 subject 必填，簡單說明，不超過 50個字 body 選填，用于填寫更詳細的描述 footer 選填，用于填關聯(lián)issus,或BREAK CHANGE 要注意的幾點： 1.每一次commit的message需要明確對應代碼的功能，無效信息不會通過，如“添加適配文件”、“First commit”等 2.對于多余無效的commits需要壓縮，如連續(xù)的相同commit messages的commits、連續(xù)的codecheck修改等 示例一：需要壓縮成一條

正確示范

錯誤示范

分支管理及命名規(guī)范

項目分支

一般來說，互聯(lián)網(wǎng)項目有上線分支，預上線分支，測試分支，開發(fā)分支等． 保證不同的分支做不同的事情，防止分支污染。

上線分支(RELEASE/master)，是發(fā)布到線上的分支，以這個分支為準，其他分支都是以這個分支為基礎拉取。預上線分支(preonline)，在預上線環(huán)境當中，防止出錯的最后一道保證。測試分支(testing)，可能測試環(huán)境大家共用一套，所以把代碼都merge到這里，然后發(fā)布。這樣大家各自測試自己的，互不打擾。如果有多個測試 環(huán)境的話，直接使用開發(fā)分支測試也是可以的。開發(fā)分支(feature/{功能名稱(下劃線命名)}_ {用戶名(全拼)})，從上線分支(RELEASE)拉取，根據(jù)需求修改的新分支。

分支規(guī)范

測試分支以及預上線分支要定時清理，和上線分支同步。上線分支以及預上線分支，merge權限保證在少數(shù)人手里。merge的時候，需要檢查提交以及對線上的影響。只能在開發(fā)分支修改代碼，其他分支都是等著被merge.提交之前，需要保證和上線分支沒有沖突。防止分支被污染，特別是受到測試分支污染。

流程規(guī)范之外

人是最難管理的，以及人是懶惰的。這些話是非常準確的，所以會遇到以下問題，還得需要解決。

需求改動非常小，是不是還得走整體流程。緊急修復問題，是不是還得走整體流程。 具體怎么做，每一個公司和組都有自己的做法，是不是都必須都得走一遍流程。但是，分支規(guī)范是必須的，不能隨意修改。直接在上線分支修改，堅決說NO!

柚子快報激活碼778899分享：git分布式版本控制系統(tǒng)（六）

http://yzkb.51969.com/

參考文章