1. Git分支和标签的命名规范🍿🍿🍿
0.1.分支
dev/test/pre/pro(即master)
0.2.标签
Tag格式： 主版本号.次版本号.修订号-类型标签，其中类型标签可为：alpha、beta、rc、r。
Tag示例：1.0.0-alpha、1.0.0-beta、1.0.0-rc、1.0.0-r
注1：有的公司在版本命名时，前面加v，“-”替换成“_”，更加详细一点还可以在修订号后面添加发布日期
v1.0.0.191220_alpha，这都是可以的
看下面这张图（详细介绍）
3.分支与标签的关系
dev-->alpha
test-->beta
pre-->rc
pro-->r
🥗🥗🥗2. 分支在实际中有什么用呢？
假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，
不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
怎么办？
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，
而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作
3. 四个环境以及各自的功能特点🍠🍠🍠
四个环境分别是：dev、test、pre、pro(master)，中文名字：开发环境、测试环境、灰度环境、生产环境
dev环境：开发环境，外部用户无法访问，开发人员使用，版本变动很大。
test环境：测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定
pre环境：灰度环境，外部用户可以访问，但是服务器配置相对低，其它和生产一样。
pro(master)环境：生产环境，面向外部用户的环境，连接上互联网即可访问的正式环境。
4. 分支策略：在实际开发中，我们应该按照几个基本原则进行分支管理：
1.首先，pro分支(即master)应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
2.那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本
3.修复bug时，我们会通过创建新的bug分支(即test)进行修复，然后合并，最后删除；
4.当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场
🌯🌯🌯学习时，先暂不考虑远程问题，本地搞懂了，再考虑远程问题（建议）
5. 分支相关命令
1.查看分支，此命令会列出所有分支，当前分支前面会标一个*号💟💟💟
git branch
//查看本地分支
git branch -a
//查看远程分支
2.创建分支发🥓🥓🥓
git branch name
//仅仅保存本地，远程还需要push
git push <远程仓库名> <远程分支名>
3.切换分支💖💖💖
git checkout name
4.创建+切换分支🏉🏉🏉
git checkout -b name
5.合并某分支到当前分支😋😋😋
git merge name
注意：当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
使用用git log --graph命令可以看到分支合并图。
6.删除分支(分本地和远程)💦💦💦
git branch
//查看本地分支
git branch -d name
//删除本地分支
git branch -a
//查看远程分支
git push origin --delete dev
//删除远程分支
7.重命名本地分支，并提交到远程☕☕☕
1.重命名
git branch -m oldBranchName newBranchName
2.删除远程分支
git push origin :oldBranchName
3.将重命名过的分支提交
git push origin newBranchName
1.git branch -m 要改的本地分支名 修改后的分支名(修改本地分支)
2.git push origin :远程修改前的分支名（删除远程分支）
3.git push origin 修改后的分支名:修改后的分支名（push 到远程分支）
4.git branch --set-upstream 修改后的分支名 origin/修改后的分支名（绑定远程分支）
6. git操作之pull拉取远程指定分支以及push推送到远程指定分支
1.pull操作
1.将远程指定分支 拉取到 本地指定分支上
git pull <远程仓库名> <远程分支名>:<本地分支名>
2.将远程指定分支 拉取到 本地当前分支上：
git pull <远程仓库名> <远程分支名>
3.将与本地当前分支同名的远程分支 拉取到 本地当前分支上
git pull <远程仓库名>
在克隆远程项目的时候，本地分支会自动与远程分支建立追踪关系，可以使用默认的origin来替代远程仓库名，所以，我常用的命令就是 git pull origin <远程仓库名>，操作简单，安全可控。
2.push操作
1.将本地当前分支 推送到 远程指定分支上（注意：pull是远程在前本地在后，push相反）
git push <远程仓库名> <本地分支名>:<远程分支名>
2.将本地当前分支 推送到 远程指定分支上
git push <远程仓库名> <远程分支名>
3.将本地当前分支 推送到 与本地当前分支同名的远程分支上
git push <远程仓库名>
推荐使用第2种方式，git push origin <远程分支名>
7. Git如何给branch打tag
发布一个版本时，我们通常先在版本库中打一个标签(tag)，这样，就唯一确定了打标签时刻的版本。
将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照
1.查看所有标签：git tag
注1：标签不是按时间顺序列出，而是按字母排序的。可以用git show 查看标签信息
2.创建tag
1.首先，切换到需要打标签的分支上，例如：dev，再创建标签
git branch
git checkout dev
git tag 1.0.0-alpha
2.推送标签到远程
git push origin 1.0.0-alpha
注1：因为创建的标签都只存储在本地，不会自动推送到远程，还需要手动推送
3.git标签分为两种类型：轻量标签和附注标签，区别：附注标签带注解
git tag 1.0.0-alpha //创建轻量标签
git tag -a 1.0.0-alpha -m "一期开发完成" //创建附注标签
一般推荐打带附注信息的标签，这样可以最大限度查看标签版本的修改情况
3.删除tag🍤🍤🍤
3.1.删除本地tag： git tag -d 1.0.0-alpha
注1：因为创建的标签都只存储在本地，不会自动推送到远程。所以，标签可以在本地直接删除
3.2.删除远程tag
1.如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除
git tag -d 1.0.0-alpha
2.然后，再从远程删除。删除命令也是push，但是格式如下：
git push origin :refs/tags/1.0.0-alpha
8. 实战：分支与版本：dev/test/pre/pro(即master)🧇🧇🧇
1.克隆远程库test1（在这里就不展示了）
git clone git@github.com:yanppp999/test1.git
2.依次创建dev/qas/pre分支(pro即master，已存在不用再创建)，然后切换到dev分支
git branch dev git branch test git branch pre
3.创建并编辑Cal.java类，添加一个add(int a,int b)方法，然后三步曲：add->commit-
>push(*****) git add Cal.java git commit -m '项目一期完成' git push origin dev
注1：在有分支情况下，push命令需要添加远程仓库名和分支名这两个参数
git push origin dev
注2：doc窗口切换到master，输入ls命令，Cal.java是找不到的，同理在github网站上，也要选择dev分支才能看到Cal.java文件
git branch master ls
至此，项目一期工作完成，接下来进行测试阶段(会在dev-test两个分支间不断切换)
4. 标签相关内容，在分支讲完之后，再重新添加进来
## 下面命令此步骤先跳过
## 创建并推送标签“dev-1.0.0”至远程
git checkout dev git tag 1.0.0-alpha git push origin 1.0.0-alpha
5.将dev合并到test
git checkout test git merge dev git push origin qas
6.测试结束之后，创建标签：qas-1.0.0
git tag qas-1.0.0
7.将qas合并到pre
git checkout pre git merge qas git tag pre-1.0.0
8.将pre合并到master
git checkout master git merge pre git tag prd-1.0.0
9. git clone指定branch或tag🍦🍦🍦
1.取完整
git clone https://github.com/arvidn/libtorrent.git
2.使用指定branch
git checkout origin/dev
3.使用指定tag
git checkout 1.0.0-alpha
4.也可以在clone的时间指定tag或branch：
git clone -b RC_1_1 https://github.com/arvidn/libtorrent.git
git clone -b libtorrent-1_1_9 https://github.com/arvidn/libtorrent.git
附录一：DEV SIT UAT PET SIM PRD PROD常见环境英文缩写含义
DEV development 开发
SIT System Integrate Test 系统整合测试（内测）
UAT User Acceptance Test 用户验收测试
PET Performance Evaluation Test 性能评估测试（压测）
SIM simulation 仿真
PRD/PROD production 产品/正式/生产
附录二：项目开发中DEV、QAS、PRD是什么意思
IDES：Internet Demonstration and Evaluation System 交互式演示与评估系统
DEV：Development System，开发系统
QAS：Quality Assurance System，质量保证系统
UAT：User Acceptance Test 用户验收测试
PRD：Production System，生产系统
附录三：git stash 应用场景
我们有时会遇到这样的情况，正在dev分支开发新功能，做到一半时有人过来反馈一个bug，让马上解决，
但是新功能做到了一半你又不想提交，这时就可以使用git stash命令先把当前进度（工作区和暂存区）保存起来，
然后切换到另一个分支去修改bug，修改完提交后，再切回dev分支，使用git stash pop来恢复之前的进度继续开发新功能
附录四：场景应用“分支的新建与合并”
实际工作中你可能会用到类似的工作流。 你将经历如下步骤
1.开发某个软件
2.为实现某个新的需求，创建一个分支。
3.在这个分支上开展工作。
正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理
1.切换到你的线上分支（production branch）。
2.为这个紧急任务新建一个分支，并在其中修复它。
3.在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。
4.切换回你最初工作的分支上，继续工作。另外，不要忘记将这个BUG在当前分支中进行修复(重要~~~重要~~~重要~~~)
附录五：实际生产中的APP或软件软件版本命名规范详解
1.软件版本阶段说明🥨🥨🥨
1.Base版:
此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，
只是做为整体网站的一个基础架构
2.Alpha版:
此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，
该版本软件的Bug较多，需要继续修改
3.Beta版:
该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，
需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI
4.RC版:
该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几
5.Release版:
该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。
该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。
2.版本命名规范🍟🍟🍟
软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，
希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。
