最近将常使用的镜像放在了Docker 仓库（Docker Hub）上。GitHub 是托管代码的地方，而Docker Hub 则是托管镜像的地方。
最近需要在Google Cloud 上重新开一台Hk区的服务器，所以写这篇笔记用来记录操作过程。
这篇笔记用来整理如何创建启用 Azure 实例。因为这方面可以找到的资料比较少，所以整理一下。
一是方便自己以后回顾，二是给其他人作为参考。
什么是AWS ？
Amazon Web Services (AWS) 是亚马逊提供的全球最全面、应用最广泛的云平台。
supervisord 是一个用 Python 写的进程管理工具，是类Unix系统中的一个进程管理工具，
Supervisor 只适用于类Unix 系统，不适用于Window。
这篇笔记的主要目的是用来记录学习 Docker 的过程。Docker这个词并不是第一次听说了，印象中好久以前就听说过这个东西了，只是一直没有真正去了解。
不知道大家通常是如何访问图床的，我之前一直使用的方式是：GitHub 图床 + raw.githubusercontent。
图片相关的资源全部放在GitHub上，然后使用GitHub 提供的素材服务器raw.githubusercontent去访问。但是这种方式存在一个问题，那就是放在 Github 的资源在国内加载速度比较慢，如果网络稍微差一些，资源可能就会加载失败。
因此需要使用 CDN 来加速来优化资源加载速度。
其实关于这个问题，老早都想整理了，只是一直没有腾出空来，最近刚好有空，索性整理了下。
这里就不过多介绍什么是Git了，本文的重点是Commit Log，如果还不清楚Git是什么，可以看一下我的Git系列的其他笔记。
为什么要关注提交信息
- 加快
Reviewing Code的过程 - 提醒自己或他人，某个提交具体增加了什么功能，改动了哪些地方
- 提高项目的整体质量
Angular 规范的 Commit message 格式
这种格式（规范）是我目前觉得相对其他格式（规范）而言，最容易接受、上手的一种。
其核心是每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
1 | <type>(<scope>): <subject> |
其中，Header 是必需的，Body 和 Footer 可以省略。
Header
Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。
type 用于说明 commit 的类别，只允许使用下面 7 个标识。
- feat 新功能（feature）
- fix 修补 bug
- docs 文档（documentation）
- style 格式（不影响代码运行的变动）
- refactor 重构（即不是新增功能，也不是修改 bug 的代码变动）
- test 增加测试
- chore 构建过程、辅助工具的变动
- perf 提高性能
- typo 打字错误
scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject 是 commit 目的的简短描述，不超过 50 个字符。
Body
Body 部分是对本次 commit 的详细描述，可以分成多行。
Footer
Footer 部分只用于不兼容变动和关闭 Issue。
总结
本来我自己一直使用的方式就是：git commit -am "fix login bug"，虽然并没有绝对的对错，但这显然不是最好的方式。
这种东西并没有强制性的规定，只要团队之间约定好，然后按照这个约定协作就好了。
所以我觉得在团队之间commit时，可以不用完全按照Angular 规范的Commit message格式去提交，可以按照以下约定来执行。
commit时，只用保留 Header 部分就好。pull request时，才需要 Header、Body、Footer 这三部分。
另外commit时需要注意以下几点：
- 创建短小而明确的
commit，一句话说清楚。 - 一个小改动对应一次
commit，不建议一大堆改动，一次commit。 - 如果添加的代码会使项目发生极大的变化，那么需要及时更新
remade文件以向他人说明此次更改。
最佳实践
1 | docs: add FAQ in readme file |