Git分支与标签（干货！！！）

目录

一、Git分支

分支的概念：

分支的类别： 

 分支策略：

分支命令：

git操作之pull拉取远程指定分支以及push推送到远程指定分支：

  1.pull操作

2.push操作

二、Tag标签

标签的含义：

Git如何打标签：

标签管理：

查看标签：

创建标签：

删除标签：

三、软件版本阶段说明：

命名规范：

 

 四、分支与版本的关系

---

一、Git分支

分支的概念：

仓库的分支(Branch)规范，影响到每个团队的工作流的一致性；标签(Tag)便于开发团队、测试团队和其他团队识别每个项目的版本，特别是在协同处理线上问题的时候，大家可以非常清楚地知道线上运行版本和代码库的对应关系。因此我们在制作的时候，主要考虑几个因素：

1. 一是要有一定的规则，方便持续集成CI（自动化构建、测试、分布等）
2. 二是要有一定的自由度，以适应不同团队的内部协作灵活性
3. 要清晰规整，不要参差不齐难以识别
    

分支的类别： 

基于我们当前团队的协作能力和提交代码的质量水平，并考虑方便持续集成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 要改的本地分支名 修改后的分支名(修改本地分支)

1.    git push origin :远程修改前的分支名（删除远程分支）
2.    git push origin 修改后的分支名:修改后的分支名（push 到远程分支）
3.  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   生产环境