Git 提交规范：写出清晰、可追踪的 commit
统一提交格式，能让协作、回溯和自动化发布都变得更稳定。
继续阅读
Latest Posts
最新文章
Docker 使用方法：从镜像到容器的快速上手
理解镜像、容器、端口和卷之后，日常开发环境会稳定很多。
继续阅读
Deep Dive
Git 提交规范
让每一次提交都能被团队快速理解
提交信息不是给 Git 看的，而是给未来的自己和协作者看的。 当 commit 写得足够清晰，代码审查、问题追踪、版本回滚和自动生成更新日志都会顺畅很多。
推荐格式
<type>(<scope>): <subject>
其中 type 表示提交类型，scope 表示影响范围，
subject 用一句简短的话概括这次改动。没有明确范围时，
scope 可以省略，但 type 和 subject 最好保留。
常见类型
feat新增功能
fix修复缺陷
docs文档更新
style不影响逻辑的样式或格式调整
refactor重构代码但不修复 bug、不加功能
test补充或修改测试
chore构建、脚本、依赖等杂项变更
写法建议
- 一条 commit 只做一件事，避免把修复、重构、格式化混在同一次提交里。
- 使用动宾结构描述结果，例如“修复登录表单校验错误”，而不是“修改了点东西”。
- 标题尽量简短直接，通常控制在一行内，方便在日志和代码托管平台中快速浏览。
- 如果改动较大，可在正文补充原因、方案和影响范围，而不是把所有信息都塞进标题。
示例
feat(blog): add article section for git commit convention
适合新增页面模块或功能入口。
fix(nav): correct anchor link on mobile menu
适合明确指出修复点和受影响区域。
docs(readme): document commit message convention
适合补充团队规范或项目说明。
推荐
- 提交前先自查，保证代码至少能运行。
- 必要时在正文写清楚为什么改，而不只是改了什么。
- 团队协作时统一规范，避免每个人各写一套风格。
避免
- 使用
update、fix bug、test这类过于模糊的标题。 - 一次提交里混入大量无关改动，导致 review 和回滚困难。
- 把格式化工具产生的大量噪音和真实业务修改放在同一个 commit。
Practical Guide
Docker 使用方法
从拉取镜像到运行服务，完成一次完整的 Docker 入门
Docker 的核心价值是把运行环境和应用一起打包，从而减少“我这里能跑、你那里不行”的问题。 学会几个高频命令后，日常启动数据库、运行 Web 服务和构建发布镜像都会简单很多。
先理解三个核心概念
Image镜像，相当于应用运行所需文件的模板。
Container容器，由镜像启动出的实际运行实例。
Port端口映射，用本机端口访问容器内服务。
Volume数据卷或目录挂载，用于持久化和共享文件。
1. 拉取镜像
docker pull nginx
这条命令会把远程仓库里的 nginx 镜像拉到本地。
拉取完成后，可以用 docker images 查看本地已有镜像。
2. 启动一个容器
docker run -d --name my-nginx -p 8080:80 nginx
-d 表示后台运行，--name 指定容器名，-p 8080:80 把本机 8080 映射到容器内 80 端口。
执行后，在浏览器访问 http://localhost:8080，
就能看到 Nginx 默认页面。
3. 查看运行状态
docker ps
查看当前正在运行的容器。
docker ps -a
查看所有容器，包括已经停止的容器。
docker logs -f my-nginx
持续查看容器日志，适合排查启动失败或请求异常。
4. 进入容器内部
docker exec -it my-nginx sh
如果容器中有 bash，也可以换成 bash。
这一步常用于检查配置文件、查看目录结构或临时排查问题。
5. 停止和删除容器
docker stop my-nginx
停止容器运行。
docker rm my-nginx
删除已停止的容器，避免环境里残留过多无用实例。
6. 用 Dockerfile 构建自己的镜像
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "run", "dev"]
把这份 Dockerfile 放在项目根目录后，可以执行
docker build -t my-app:1.0 . 来构建镜像。
7. 多服务场景使用 Docker Compose
docker compose up -d
当项目同时依赖 Web、数据库、缓存等多个服务时，
用 docker compose 管理会比手写多个 docker run 命令更清晰。
推荐习惯
- 容器名、镜像标签和端口映射都尽量写清楚，便于排查。
- 需要保留的数据尽量挂载卷，不要只存放在容器内部。
- 开发环境优先用
docker compose管理一组服务。
常见误区
- 把容器当作虚拟机长期手工维护，导致环境不可复制。
- 忘记映射端口或挂载目录，结果本机无法访问服务或数据丢失。
- 所有改动都直接在运行中的容器里完成，而不是回到 Dockerfile 固化。