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 <远程仓库名> <远程分支名>