基於git相對svn在版本管控方面的優勢以及研發中心未來專案研發的需求,我們將逐步採用git替代svn。目前新的專案統一採用git進行版本管控,原有專案也會在逐步進行遷移。
就像**需要**規範一樣,**管理同樣需要乙個清晰的流程和規範,目前比較流行的是git flow的流程管理,它有著廣泛的應用,git ui客戶端如sourcetree都對此有很好的支援。參考git flow的標準,將它與我們的開發實際進行結合,形成符合我們的最佳實踐是我們未來一段時間的工作目標。
下文會簡單介紹一下git flow各分支的使用,並列舉研發工作各階段的實踐規範,需要研發部遵守執行。
根據目前專案的實際情況,下面對研發過程中各階段、常規場景下git分支的使用規範如下:
1.gitlab遠端通常只有master、develop固定分支,允許有hotfix、feature臨時分支,臨時分支完成使命後刪除1. 初始專案2.master 分支為最近發布到生產的**,即當前生產版本
3.本地倉庫分支命名建議為feature-***用於新功能開發,不建議使用其它分支名
2. 常規版本功能開發
3. 生產緊急需求/bug修復開發1. 同時進行v1.1.0版本開發
# 功能開發完成,需要提交,在develop分支完成
## 1.提交到本地倉庫
### 檢視檔案狀態
git status
### 將需要的檔案加入暫存區
git add .
### 提交到本地倉庫
git commit -m 'feat/bug:功能描述'
## 2.同步遠端倉庫
git pull
### 如果有衝突,會有提示衝突進行解決,解決衝突後需要提交到本地倉庫,衝突解決在此不詳細描述
## 3.push到遠端倉庫
git push
2. 進行後續版本功能開發# 當前版本v1.1.0未發布,需要進行v1.2.0版本功能研發
## 1.在本地建立新的分支
### stash本地修改,同步遠端倉庫
git stash
git pull
### 在本地建立feature分支,並切換
git branch feature-v1.2.0-functiondesc
git checkout feature-v1.2.0-functiondesc
### 從stash恢復
## 2.完成功能修改後提交本地倉庫
### 檢視檔案狀態
git status
### 將需要的檔案加入暫存區
git add .
### 提交到本地倉庫
git commit -m 'feat/bug:功能描述'
## 3.push遠端倉庫(開發周期很長,共同開發才需要提交,否則直接在本地即可)
git push origin feature-v1.2.0-functiondesc
## 4.v1.1.0發布後,合併回develop分支並刪除feature分支
### 保證feature分支**都已經提交到本地分支,如有遠端push到遠端
### 本地**合併到develop
git checkout develop
git pull
git merge --no-ff feature-v1.2.0-functiondesc
git commit -m "merge feature-v1.2.0-functiondesc to develop"
git push
### 確認無誤刪除分支feature
### 刪除本地
git branch -d feature-v1.2.0-functiondesc
### 刪除遠端
git push origin --delete feature-v1.2.0-functiondesc
3.生產問題修復/緊急版本開發# 當前生產版本v1.1.0,需要修改乙個問題
## 1.建議使用gitlab從v1.1.0發布版本標籤建立hotfix分支,本地操作參考如下
git pull
git branch hotfix-v1.1.1 v1.1.0
git checkout hotfix-v1.1.1
git push origin hotfix-v1.1.1
## 2.完成功能修改後提交本地倉庫並push
### 檢視檔案狀態
git status
### 將需要的檔案加入暫存區
git add .
### 提交到本地倉庫
git commit -m 'bug:功能描述'
## 3.push遠端倉庫
git push
## 4.合併**回develop和master,並打標籤到master
git checkout master
git merge --no-ff hotfix-v1.1.1
git push
git checkout develop
git merge --no-ff hotfix-v1.1.1
git push
git branch -d hotfix-v1.1.1
git tag -a v1.1.1 master
git push --tags
參考:
git flow guide
git常用命令
MD 文件視覺設計規範
有時候在使用markdown寫筆記時總感覺不是很好看,於是便設計了這個筆記規範,方便以後寫筆記時讓筆記文件格式更加好看美觀 有時候在使用markdown寫筆記時總感覺不是很好看,於是便設計了這個筆記規範,方便以後寫筆記時讓筆記文件格式更加好看美觀有時候在使用markdown寫筆記時總感覺不是很好看,...
git 操作規範
git checkout master git checkout b devgit branch dev git checkout devgit branchgit branch a git add a html git commit m 提交檔案a.html git checkout master...
Git 提交規範
無規矩不成方圓,程式設計也一樣。乙個commit只做一件事情,若乙個commit做了多件事情需要拆分成多個commit 嚴格遵循commit message格式 每次只允許提交乙個commit,若本地有多個commit等待提交,必須等前面的commit合併進入主版本庫並在本地合併完成後才可提交後面的...