一、Git分支
分支的概念：
仓库的分支(Branch)规范，影响到每个团队的工作流的一致性；标签(Tag)便于开发团队、测试团队和其他团队识别每个项目的版本，特别是在协同处理线上问题的时候，大家可以非常清楚地知道线上运行版本和代码库的对应关系。因此我们在制作的时候，主要考虑几个因素：
- 一是要有一定的规则，方便持续集成CI（自动化构建、测试、分布等）
- 二是要有一定的自由度，以适应不同团队的内部协作灵活性
- 要清晰规整，不要参差不齐难以识别
分支的类别：
基于我们当前团队的协作能力和提交代码的质量水平，并考虑方便持续集成CI（自动化构建、
测试、发布），我们约定下列常驻Branch： 四个环境（开发、测试、生产、灰度）
- develop 分支：顾名思义即持续开发的分支，我们希望每个开发组都在这个分支上保持线性的持续小步迭代，正常的CodeReview WorkFlow和开发级的自动CI也在这里进行。当开发完一个迭代(Sprint)，开发小组有信心转测时，就将代码合并到 release 分支，并要求打一个alpha级的Tag(如5.2.0-alpha)
- release 分支：顾名思义即用于发布过程的分支，包括开发转测(实际上我们认为这里的测试集成测试)、测试和BugFix以及发布上线的过程，当发布成功时要打一个发布beta Tag(如5.2.1-beta)，并将代码合并到 master 分支
- master 分支：即有质量保证的、可安全运行的分支，禁止直接代码提交，避免被污染，仅用于代码合并和归集，在这个分支上的代码应该永远是可用的、稳定的。当需要拉一个特别的开发分时，应该基于 master。
- pre分支：灰度环境，外部用户可以访问，但是服务器配置相对低，其它和生产一样。
分支策略：
在实际开发中，我们应该按照几个基本原则进行分支管理：
- 首先，pro分支(即master)应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
- 那在哪干活呢？干活都在develop分支上，也就是说，develop分支是不稳定的，到某个时候，比如1.0版本发布时， 再把develop分支合并到master上，在master分支发布1.0版本
- 修复bug时，我们会通过创建新的bug分支(即release)进行修复，然后合并，最后删除；
- 当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场
分支命令：
1.查看分支，此命令会列出所有分支，当前分支前面会标一个*号
git branch //查看本地分支git branch -a //查看远程分支
可以看出原始只有一个分支master
2.创建分支
git branch name //仅仅保存本地，远程还需要pushgit push <远程仓库名> <远程分支名>
远程仓库中不存在dev这个分支，但是当你推送时，gitee会自动为你创建dev这个分支
3.切换分支
git checkout name4.创建+切换分支
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.重命名本地分支，并提交到远程
重命名 git branch -m oldBranchName newBranchName删除远程分支 git push origin :oldBranchName将重命名过的分支提交git push origin newBranchName
git branch -m 要改的本地分支名 修改后的分支名(修改本地分支)
- git push origin :远程修改前的分支名（删除远程分支）
- git push origin 修改后的分支名:修改后的分支名（push 到远程分支）
- git branch --set-upstream 修改后的分支名 origin/修改后的分支名（绑定远程分支
git操作之pull拉取远程指定分支以及push推送到远程指定分支：
1.pull操作
将远程指定分支 拉取到 本地指定分支上 git pull <远程仓库名> <远程分支名>:<本地分支>将远程指定分支 拉取到 本地当前分支上 git pull <远程仓库名> <远程分支名>
在克隆远程项目的时候，本地分支会自动与远程分支建立追踪关系，可以使用默认的origin来替代远程仓库名，将与本地当前分支同名的远程分支 拉取到 本地当前分支上 git pull <远程仓库名>
所以，我常用的命令就是 git pull origin <远程仓库名>，操作简单，安全可控。
2.push操作
将本地当前分支 推送到 远程指定分支上（注意：pull是远程在前本地在后，push相反）git push <远程仓库名> <本地分支名>:<远程分支名>
将本地当前分支 推送到 远程指定分支上 git push <远程仓库名> <远程分支名>将本地当前分支 推送到 与本地当前分支同名的远程分支上 git push <远程仓库名>推荐使用第2种方式，git push origin <远程分支名> ！！！！！！
二、Tag标签
标签的含义：
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_r，这都是可以的
Git如何打标签：
发布一个版本时，我们通常先在版本库中打一个标签(tag)，这样，就唯一确定了打标签时刻的版本。
将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照
标签管理：
查看标签：
git show <tagname>查看标签信息
创建标签：
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 "一期开发完成" //创建附注标签
一般推荐打带附注信息的标签，这样可以最大限度查看标签版本的修改情况
删除标签：
1.删除本地tag
git tag -d 1.0.0-alpha
注1：因为创建的标签都只存储在本地，不会自动推送到远程。所以，标签可以在本地直接删除
2.删除远程tag
1.如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除
git tag -d 1.0.0-alpha
2.然后，再从远程删除。删除命令也是push，但是格式如下：
git push origin :refs/tags/1.0.0-alpha
三、软件版本阶段说明：
1.Base版:
此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，
只是做为整体网站的一个基础架构
2.Alpha版:
此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，
该版本软件的Bug较多，需要继续修改
3.Beta版:
该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，
需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI
4.RC版:
该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几
5.Release版:
该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。
该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。
命名规范：
软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，
希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。
四、分支与版本的关系
dev-->alpha 开发环境 test-->beta 测试环境 pre-->rc 灰度环境 pro-->r 生产环境
版权归原作者 小朱爱编程 所有， 如有侵权，请联系我们删除。