分支与版本
Git
Git分支和标签的命名规范
- 分支
dev/test/pre/pro(即master) - 标签
- 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,这都是可以的
- 分支与标签的关系
dev–>alpha
test–>beta
pre–>rc
pro–>r
分支在实际中有什么用呢?
假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
怎么办?
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作
四个环境以及各自的功能特点
四个环境分别是:dev、test、pre、pro(master),中文名字:开发环境、测试环境、灰度环境、生产环境
-
dev环境:
开发环境,外部用户无法访问,开发人员使用,版本变动很大。 -
test环境:
测试环境,外部用户无法访问,专门给测试人员使用的,版本相对稳定 -
pre环境:
灰度环境,外部用户可以访问,但是服务器配置相对低,其它和生产一样。 -
pro(master)环境:
生产环境,面向外部用户的环境,连接上互联网即可访问的正式环境。
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
- 首先,pro分支(即master)应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
- 那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本
- 修复bug时,我们会通过创建新的bug分支(即test)进行修复,然后合并,最后删除;
- 当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场
分支相关命令
-
查看分支,此命令会列出所有分支,当前分支前面会标一个*号
git branch //查看本地分支
git branch -a //查看远程分支 -
创建分支
git branch name //仅仅保存本地,远程还需要push
git push <远程仓库名> <本地分支名>:<远程分支名> -
切换分支
git checkout name -
创建+切换分支
git checkout -b name -
合并某分支到当前分支
git merge name
注意:当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
使用用git log --graph命令可以看到分支合并图。 -
删除分支(分本地和远程)
git b