目录
git操作之pull拉取远程指定分支以及push推送到远程指定分支：
一、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 ? ? ?//仅仅保存本地，远程还需要push
- ? ? ?git push <远程仓库名> <远程分支名>
?
?远程仓库中不存在dev这个分支，但是当你推送时，gitee会自动为你创建dev这个分支
? ? ?
? ?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.重命名本地分支，并提交到远程
- ? ? 重命名?? 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 <远程仓库名> <远程分支名>
- ? ? ?将与本地当前分支同名的远程分支 拉取到 本地当前分支上? ? ?git pull <远程仓库名>
??在克隆远程项目的时候，本地分支会自动与远程分支建立追踪关系，可以使用默认的origin来替代远程仓库名，
? ? ?所以，我常用的命令就是 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? ?生产环境