1.Git 常用操作与软件版本规范

你想要什么？你在做什么？它们一样吗？

以下分场景来介绍一些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-***的形式

三、按照规范的情况下，新开发一个项目

（一）负责创建分支的同学

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 风格的版本号管理策略：

1. 项目初版本时0.1.0；
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
5. 另外，编译版本号一般是编译器在编译过程中自动生成的，只定义其格式，并不进行人为控制。

2 Window 下的版本号管理策略：

1. 项目初版时，版本号为 1.0 或 1.00；
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
5. 另外 , 编译版本号一般是编译器在编译过程中自动生成的，只定义其格式，并不进行人为控制。

另外，还可以在版本号后面加入 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