每个公司都有自己的一套git操作模式,但git的各种规范都是相同,下面总结了下常用开发规范操作
分支命名
master
- 主干(默认)
一般master位于线上正式服务器的版本,每一次在 master
上的提交或合并都应该伴随着版本号的变更。(这样会更好的记录和版本回退)
master 分支应保证是随时可发布的(可能包含Bug),每个发布的版本应打上 tag,便于回滚。对于有重大 Bug 的版本,应备注,避免回滚到错误的版本。
-
feature/*
- 特性分支Example: feature/this-is-a-feature-name,名称中间通过
-
分割。该分支创建自
master
分支,充分测试后,合并到master
分支开发人员使用的分支,针对每一个功能点
issue
创建一个feature
,一般命名规范为feature/<issue_number>-<feature_name>
,该feature
下的每次提交格式为#<issue_number> <description>
,当feature
开发完毕后merge
到develop
,并关闭issue
。实际开发中,可能有些
feature
算不上什么功能上的需求,不太必要有issue
,所以命名时可以没有<issue_number>
。实际开发中,每个新特征功能都应该进行独立的测试,所以可能需要发布到测试环境中供测试人员进行测试。目前开发流程不方便部署
feature
分支,所以目前不进行feature
的独立测试。 -
develop
- 测试分支该分支创建自
master
分支,定期与master
分支同步,featrue
分支 在本merge
到develop
后push
到github
进行测试。测试服运行此分支代码,作为开发环境中的主分支使用,任务是收集各个
feature
分支。合并到
develop
分支的代码必须是已经完成开发并在本地进行过充分测试的feature
,即能够交给测试人员测试的版本
。因该分支上可能包含多个
feature
,且 多个feature
可能处于不同阶段,所以该分支一般不合并的到master
-
release/*
- 预发布版本预发布版本,当
develop
收集够了做一次版本发布所需的代码,就checkout -b
出一个release
分支,作为上线前的最后测试,除了bugfix
外不接受任何提交。确认发布后分别merge
到master
和develop
。如果能够明确定义版本,且明确定义 某版本包含哪些功能的情况下,可在 某版本 定义的功能全部开发完毕之后,创建
release
分支,进行master + release
灰度部署。 -
hotfix/*
紧急修复分支,当
master
上出现bug
需要修复时,基于master
创建hotfix
分支,修复完成后分别merge
到master
和develop
。开发分支中可能存在Bug,直接修改就可以了,无须创建分支修复Bug,所以,
hotfix/*
只针对发布的版本。
标签命名
- 语义化版本 2.0.0
- 软件版本周期
-
版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
- 主版本号:当你做了不兼容的 API 修改,通常是进行了大规模的重新设计,重新定义了 API。
- 次版本号:当你做了向下兼容的功能性新增,通常对应发布了
feature/*
。 - 修订号:当你做了向下兼容的问题修正。通常对应发布了
hotfix/*
。 -
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
Example:
Commit
Format
<type>[(<scope>)]: <subject> // 空一行 [<body>]
Format with GitEmoji
:emoji1: :emoji2: 不超过 50 个字的摘要,首字母大写,使用祈使语气,句末不要加句号 提交信息主体 引用相关 issue 或 PR 编号 <#110>
# Ref https://github.com/thoughtbot/dotfiles/blob/master/gitmessage # # 50-character subject line # # 72-character wrapped longer description. This should answer: # # * Why was this change necessary? # * How does it address the problem? # * Are there any side effects? # # Include a link to the ticket, if any. # # Add co-authors if you worked on this code with others: # # Co-authored-by: Full Name <email@example.com> # Co-authored-by: Full Name <email@example.com>
-
type:
- feat - 新功能
- fix - 修复bug
- br - 此项特别针对bug号,用于向测试反馈bug列表的bug修改情况
- test - 测试
- docs - 文档()
- style - 格式(不影响代码运行的变动)
- refactor - 重构(即不是新增功能,也不是修改bug的代码变动)
- chore - 构建过程或辅助工具的变动
- revert - 执行了
git-revert
-
scope
scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
-
Develop -> Deploy
-
创建分支
git checkout feature/xxx
注意:
feature/xxx
应基于master
,所以 此时命令应在master
分支上进行 -
修改
git add
git commit
-
推送到远程
git push
-
同步
develop
分支,自动部署develop
分支部署到demo
服务器git branch -f develop feature/xxx
git push -f origin develop
自定义快捷命令,放到
~/.bashrc
~/.zshrc
中即可function gitdd () { echo 'deploy current branch to demo' git branch -f develop HEAD git push -f origin develop }
usage:
gitdd
以上命令在当前分支
feature/xxx
下进行,不需要切换分支 -
Pull Request
请求将
feature/xxx
合并到master
上 -
部署正式服
-
将分支 切回
master
git checkout master
此时
feature/xxx
已经完成任务,可以删除 -
· 打 Tag,部署正式服 服务自动处理
git tag vx.x.x
git push origin vx.x.x
-
创建
release/vx.x.x
,部署正式服git branch release/vx.x.x
git push origin release/vx.x.x
-