你想要什么?你在做什么?它们一样吗?
以下分场景来介绍一些git命令和规范
一、无Git规范的情况下,新开发一个项目
git没有很规范的情况下,直接在master分支开发
1 克隆远程仓库
git clone url
2 设置仓库的用户名和密码
git config user.name "gitlab’s Name"
git config user.email "gitlab@xx.com"
3 克隆远程仓库
git pull
4 在修改后添加本地文件到暂存区
git add filename
5 提交到本地仓库
git commit -m "change comment"
提交规范建议: https://zhuanlan.zhihu.com/p/100773495
commit规范示例:
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
6 提交到远程仓库
git push
二、Git规范介绍
分为三个分支
- master 稳定版本(生产版本)
- develop 开发分支
- 临时分支
- release
预发布分支,发布为正式版本前在预发布环境进行测试的一个版本,从develop分支分出来。完成测试后合并回develop。命名可以采用release-***的形式 - feature
功能分支,为开发某特定功能从develop分支分出来的,开发完成后并入develop。命名可以采用feature-***的形式 - hotfix(fixbug)
修复bug分支, 修补结束以后,再合并进Master和Develop分支。
命名可以采用hotfix-***的形式
- release
三、按照规范的情况下,新开发一个项目
(一)负责创建分支的同学
git有规范的情况下
git clone url
1 根据当前分支创建一个新分支
默认clone下来的分支为master,这里我们根据master分支创建一个分支名为develop
git checkout -b develop
2 根据本地分支创建一个远程分支(将本地分支推送到远程分支)
此处创建一个名为develop的远程分支
git push origin develop:develop
3 将本地分支关联到指定远程分支
origin/develop为远程分支,develop为本地分支
git branch --set-upstream-to=origin/develop develop
到这里分支就创建好了,后续步骤与 无Git规范的情况下,新开发一个项目步骤类似,故不赘述
(二)其他参与项目的小伙伴
1 根据已有远程分支创建一个本地分支
根据远程的origin/develop分支创建一个名为develop的本地分支
git checkout -b develop origin/develop
2 将创建的本地分支和远程分支关联起来
将创建的本地分支develop和远程分支origin/develop关联起来
git branch --set-upstream-to=origin/develop develop
3 查看本地分支和远程分支对应关系
git branch -vv
4 切换到其他分支
切换回master分支,再切换到develop
git checkout master
git checkout develop
(三)合并分支
把develop分支merge到master分支,假设当前在develop分支
git checkout master
git merge develop
四、给稳定版本打标签
通常情况下master为生产版本或者叫稳定版本分支
1 添加标签
根据最新提交,创建一个带注释的标签,标签名为V0.1.0
git tag -a V0.1.0 -m"1期基本完成"
根据指定commit编号创建一个带注释的标签,标签名为V0.1.0
git tag -a V0.1.0 9faeb20 -m "1期基本完成"
2 推送标签
git push –tags
3 推送到远程分支
就像代码修改后需要push一样,tag也需要推送才会到远程仓库
git push origin V0.1.0
4 删除(慎重)
删除本地标签
git tag -d V0.1.0
删除远程标签
git push origin :refs/tags/V0.1.0
5 切换到指定标签
git checkout V0.1.0
五、软件版本号策略
1 GNU 风格的版本号管理策略:
- 项目初版本时0.1.0;
- 当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变,修正版本号加 1;
- 当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加 1,修正版本号复位为 0,因而可以被忽略掉;
- 当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1;
- 另外,编译版本号一般是编译器在编译过程中自动生成的,只定义其格式,并不进行人为控制。
2 Window 下的版本号管理策略:
- 项目初版时,版本号为 1.0 或 1.00;
- 当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变,修正版本号加 1;
- 当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加 1,修正版本号复位为 0,因而可以被忽略掉;
- 当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1;
- 另外 , 编译版本号一般是编译器在编译过程中自动生成的,只定义其格式,并不进行人为控制。
另外,还可以在版本号后面加入 Alpha、Beta、Gamma、Current、RC (Release Candidate)、Release、Stable 等后缀,在这些后缀后面还可以加入 1 位数字的版本号。
对于用户来说,如果某个软件的主版本号进行了升级,用户还想继续那个软件,则发行软件的公司一般要对用户收取升级费用;而如果子版本号或修正版本号发生了升级,一般来说是免费的。
3 测试版本名:
α(alphal) 内部测试版
α版,此版本表示该软件仅仅是一个初步完成品,通常只在软件开发者内部交流,也有很少一部分发布给专业测试人员。一般而言,该版本软件的 bug 较多,普通用户最好不要安装。
β(beta)外部测试版
该版本相对于α版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布,用户可从相关的站点下载。通过一些专业爱好者的测试,将结果反馈给开发者,开发者们再进行有针对性的修改。该版本也不适合一般用户安装。
γ(gamma)版
该版本已经相当成熟了,与即将发行的正式版相差无几,如果用户实在等不及了,尽可以装上一试。
4 正式版本名
release 最终释放版
该版本意味“最终释放版”,在出了一系列的测试版之后,终归会有一个正式版本,对于用户而言,购买该版本的软件绝对不会错。该版本有时也称为标准版。一般情况下,release不会以单词形式出现在软件封面上,取而代之的是符号 ® ,如 windows nt® 4.0、ms-dos® 6.22 等。
参考链接:
http://apr.apache.org/versioning.html
https://zhuanlan.zhihu.com/p/192905133