了解git分支和版本管理

0. Git分支和标签的命名规范

   1.分支

     dev/test/pre/pro(即master)

   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

1. 分支在实际中有什么用呢？

   假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，

   不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

   怎么办？

   现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，

   而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作

2. 四个环境以及各自的功能特点

   四个环境分别是：dev、test、pre、pro(master)，中文名字：开发环境、测试环境、灰度环境、生产环境

jquery.js

jquery.min.js

   dev环境：开发环境，外部用户无法访问，开发人员使用，版本变动很大。

   test环境：测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定

   pre环境：灰度环境，外部用户可以访问，但是服务器配置相对低，其它和生产一样。

   pro(master)环境：生产环境，面向外部用户的环境，连接上互联网即可访问的正式环境。

   开发环境->测试环境->灰度环境(测试服)->生产环境(正式发布的完整的项目)

3. 分支策略

   在实际开发中，我们应该按照几个基本原则进行分支管理：

   1.首先，pro分支(即master)应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；product

   2.那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，

     再把dev分支合并到master上，在master分支发布1.0版本

   3.修复bug时，我们会通过创建新的bug分支(即test)进行修复，然后合并，最后删除；

   4.当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场

   

## 学习时，先暂不考虑远程问题，本地搞懂了，再考虑远程问题

4. 分支相关命令

   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/修改后的分支名（绑定远程分支）

5. 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 <远程分支名>

  

6. 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

      

       tag标签就是版本号，在版本号是整个项目的,并不是某个模块的

     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

     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

       

## GUI工具为：TortoiseGit

## 分3个部分：dev/test如何进行代码修复

##            dev->test->pre->pro的发布

##            产品升级重新发布

7. 实战：分支与版本

   dev/test/pre/pro(即master)

   1.克隆远程库test1

     git clone [email protected]:yanppp999/test1.git

   2.依次创建dev/qas/pre分支(pro即master，已存在不用再创建)，然后切换到dev分支

     git branch dev

     git branch test

     git branch pre

   #add(int a, int b){a+b+b}   v1.0.0

   #add(int a, int b, int c)   v1.1.0

   #add(int... arr)            v1.2.0

   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两个分支间不断切换)

     

     ## 标签相关内容，在分支讲完之后，再重新添加进来

     ## 下面命令此步骤先跳过

     ## 创建并推送标签“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

   注1：实际生产中的APP或软件软件版本命名规范详解，详情可参考：资料/12，资料/13

        v1.0.0.191202_be.d

        v1.0.0.191210.t

        v1.0.0.191221.rc

        v1.0.0.191225.r

        

     

   

8. 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

## 作业

9. 综合案例(idea环境)：分支与版本

附录一：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来恢复之前的进度继续开发新功能

详情见：资料/08

附录四：场景应用“分支的新建与合并”

        实际工作中你可能会用到类似的工作流。 你将经历如下步骤

        1.开发某个软件

        2.为实现某个新的需求，创建一个分支。

        3.在这个分支上开展工作。

        正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理

        1.切换到你的线上分支（production branch）。

        2.为这个紧急任务新建一个分支，并在其中修复它。

        3.在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。

        4.切换回你最初工作的分支上，继续工作。另外，不要忘记将这个BUG在当前分支中进行修复(重要~~~重要~~~重要~~~)

附录五：实际生产中的APP或软件软件版本命名规范详解(详情可参考：资料/12、资料/13)

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。