Git的分支与版本

Git

Git分支和标签的命名规范

• 分支
  dev/test/pre/pro(即master)
• 标签
  1. Tag格式： 主版本号.次版本号.修订号-类型标签，其中类型标签可为：alpha、beta、rc、r。
  2. Tag示例：1.0.0-alpha、1.0.0-beta、1.0.0-rc、1.0.0-r

注1：有的公司在版本命名时，前面加v，“-”替换成“_”，更加详细一点还可以在修订号后面添加发布日期
v1.0.0.191220_alpha，这都是可以的

• 分支与标签的关系
  dev–>alpha
  test–>beta
  pre–>rc
  pro–>r

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

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

怎么办？
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作

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

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

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

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

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

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

分支策略

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

1. 首先，pro分支(即master)应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
2. 那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本
3. 修复bug时，我们会通过创建新的bug分支(即test)进行修复，然后合并，最后删除；
4. 当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场

分支相关命令

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 b