星辰

# Git开发规范

团队多人协作开发一个项目，最重要的就是版本控制，一个合理的版本控制规范可以让成员之间高效率的协作开发，稳定的迭代版本。习惯使用版本控制工具，对以后不论在哪个团队都能更快的融入开发中。

# 分支规范

  • master分支 生成环境分支，作为线上正式版本发布分支，每次正式发布打tag标记版本，如有重大bug标记为小版本发布，任何开发测试内容不允许直接提交到此分支。

  • release_分支 预发布分支，在正式发布前的测试分支，从develop分支同步过来，在上面可以做一些bug修复，测试完成同步到master分支和develop分支并删除该分支。这个分支看个人情况是否需要。

  • develop分支 开发环境分支，保持最新的开发迭代代码，只从feature分支进行同步，开发完成后推送到release分支进行测试。禁止推送未开发完成的功能。

  • feature_分支 版本迭代分支，新功能迭代分支，基于develop分支进行创建，每次版本迭代都在此分支上进行开发，版本迭代完成推送到develop分支进行合并，发布完后删除此分支。

  • hotfix_分支 bug分支，生产环境出现bug，创建此分支拉取最新代码修复bug，然后在提交到release分支进行测试，测试完成进行发布和同步然后删除此分支。

主分支master只能用于线上发布，只允许发布版本时从release分支行提交合并，其他分支禁止直接合并到主分支上。develop分支永远保持最新的代码，未完成的功能禁止提交到develop分支上，此分支永远和master分支保持同步，当然有些时候此分支也可以作为测试分支。feature分支只基于develop分支进行创建，开发人员只允许在feature分支上进行开发，其他分支禁止操作。release分支只能从develop分支和hotfix分支进行提交，其他分支禁止提交，测试和修复完成后同步到master和develop分支后删除该分支。

对于权限控制，master、develop都不允许开发人员进行操作，只能在发版时由管理员进行操作，其他分支禁止提交。

# commit提交规范

每次commit提交代码时我们都是要描述清楚本次修改了什么，并且有专门的提交格式，这里我们推荐使用 type: description 格式进行提交。

type 是 commit 的类别，只允许如下几种标识：

feat:新功能
fix:修复bug
to:多次修复bug
update:更新
refactor:重构（即不是新增功能，也不是修改bug的代码变动）
style:代码格式改变
merge:代码合并
docs:文档
revert:撤销
test:增加测试代码
build:构建工具或构建过程等的变动
perf:性能优化

description 是对本次提交的简短描述，推荐以动词开头，如： 设置、修改、增加、删减、撤销

git commit -am "feat:新增用户模块"
git commit -am "style:修改某某样式"

# 多人协作

现在我们开始基于创建好master和develop分支的项目进行团队开发，假如有团队成员A和B。

首先，由管理员初始化项目和分支。

git init
git commit -am "init"
git remote add origin <remote-url>
git push origin master
git checkout -b develop
git push origin develop

项目初始化后，开始功能迭代，由管理员创建新的迭代分支。

git checkout develop
git checkout -b feature_1.0.0
git push origin feature_1.0.0

管理员创建好开发分支后，A和B领到任务，在此分支进行开发。

git clone <remote-url> # 克隆项目
git branch -a
git checkout feature_1.0.0

A和B各自开发自己的任务，如果某个功能A一天无法开发完成，下班了需要把代码提交防止丢失，但是未完成的代码不能随便提交到feature分支上去，这样会影响到B同学开发，这时A同学就可以基于feature分支去创建一个自己的分支。

git add .
git commit -am "feat:部分功能提交"
git checkout -b feature_1.0.0_test
git push origin feature_1.0.0_test

如果B开发完成了某个功能就可以直接提交到feature上

git add .
git commit -am "feat:完成某功能"
git pull origin feature_1.0.0 # 拉取远程，解决冲突
git push origin feature_1.0.0

第二天A开发完成提交代码后，需要把远程的test分支给删除掉。

git add .
git commit -am "feat:完成某功能"
git pull origin feature_1.0.0
git push origin feature_1.0.0


git branch -d feature_1.0.0_test
git push origin --delete feature_1.0.0_test

为了防止冲突，每次在开发前或者代码合并前都需要先拉一下远程dev分支进行merge解决冲突。每天晚上结束工作后都要把已经完成的功能进行提交到feature上，每天在开发前都要先拉取代码。每次开发完某一个小功能时都要及时的进行commit，防止临时回退代码。

A和B开发完成了某个迭代的全部功能，代码提交到feature分支后，由管理员合并代码到develop进行提测。

# 线上bug修改

当线上出现bug，如果是重大bug无法立即修复，则直接回滚版本，代码回滚到上一个正式版本，先恢复线上正常访问，然后再慢慢排查问题，等到问题排查出后再测试打包发版上线。

如果是线上出现某些不会影响正常使用的bug，需要立即解决，我们就需要在主分支上直接创建bug分支进行修改，然后合并到主分支测试打包发布bug版本。

发布好后，我们开发分支也要同步该代码，一级一级的去同步远程版本，否则我们开发分支就无法和主分支保持版本同步，导致无法提交。

git checkout master


git pull origin master


git checkout -b fix_bug # 创建bug分支


...
git push origin fix_bug # 解决问题提交远程合并到主分支


# 同步其他分支代码


git checkout develop


git pull origin master # 拉取bug修改后的版本


git push origin develop # develop分支保持同步

# 版本发布流程

代码开发完成合并到master分支，我们要发布版本所对应的更新信息和代码包，一般都是借助git工具的 releases 功能进行发布。

进入仓库，左侧项目概述点击发布

点击发布，新建发布，填写发布信息

更多：git使用教程

← canvas文档 →