点击上方蓝色“大数据实战演练”,选择“设为星标”或“置顶”
回复“资料”领取独家整理的学习资料!
每一个成功人士的背后,必定曾经做出过勇敢而又孤独的决定。
放弃不难,但坚持很酷~
作者:稻草叔叔
整理 + 丰富:create17
Git 是目前最流行的源代码管理工具。为规范开发,保持代码提交记录以及 git 分支结构清晰,方便后续维护,现规范 git 的相关操作。
1、master 分支
master 为主分支,也是用于部署生产环境的分支,所有提供给用户使用的正式版本,都在这个主分支上发布。为确保 master 分支稳定性, master 分支一般由 develop 以及 hotfix 分支合并,任何时间都不能直接修改代码。
2、develop 分支
master 分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做 develop。
develop 为开发分支,始终保持最新完成以及 bug 修复后的代码,一般开发的新功能时,feature 分支都是基于 develop 分支下创建的。
如果想正式对外发布,就在 master 分支上,对 develop 分支进行"合并"(merge)。
3、feature 分支
4、release 分支
release 为预上线分支,发布提测阶段,会 release 分支代码为基准提测。当有一组 feature 开发完成,首先会合并到 develop 分支,进入提测时会创建 release 分支。
如果测试过程中若存在 bug 需要修复,则直接由开发者在 release 分支修复并提交。当测试完成之后,合并 release 分支到 master 和 develop 分支,此时 master 为最新代码,用作上线。
5、hotfix 分支
分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似。线上出现紧急问题时,需要及时修复,以 master 分支为基线,创建 hotfix 分支,修复完成后,需要合并到 master 分支和 develop 分支。
增加新功能
(dev)$: git checkout -b feature/xxx # 从dev建立特性分支
(feature/xxx)$: blabla # 开发
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff # 把特性分支合并到dev
修复紧急bug
(master)$: git checkout -b hotfix/xxx # 从master建立hotfix分支
(hotfix/xxx)$: blabla # 开发
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master,并上线到生产环境
(dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到dev,同步代码
测试环境代码
(release)$: git merge dev --no-ff # 把dev分支合并到release,然后在测试环境拉取并测试
生产环境上线
(master)$: git merge release --no-ff # 把release测试好的代码合并到master,运维人员操作
(master)$: git tag -a v0.1 -m '部署包版本名' # 给版本命名,打Tag
日志规范
在一个团队协作的项目中,开发人员需要经常提交一些代码去修复bug或者实现新的 feature 。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘,最后需要浪费时间去阅读代码。但是好的日志规范 commit messages 编写有帮助到我们,它也反映了一个开发人员是否是良好的协作者。
而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘,最后需要浪费时间去阅读代码。但是好的日志规范 commit messages 编写有帮助到我们,它也反映了一个开发人员是否是良好的协作者。
编写良好的 Commit messages 可以达到3个重要的目的:
目前,社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法,比较合理和系统化。如下图:
Commit messages的基本语法
当前业界应用的比较广泛的是 Angular Git Commit Guidelines
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines
具体格式为:
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
body: 同样使用祈使句,在主体内容中我们需要把本次 commit 详细的描述一下,比如此次变更的动机,如需换行,则使用 |
footer: 描述下与之关联的 issue 或 break change
# 标题:50个字符以内,描述主要变更内容
#
# 主体内容:更详细的说明文本,建议72个字符以内。需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug,增加一个feature,提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到issue地址或者其它文档