026_Git 常用命令大全和提交关键字规范

一、基础信息查看

命令

用途

git –version

查看 Git 版本信息

git status

查看当前仓库文件状态(暂存/未暂存/未跟踪)

git log

查看提交历史(按时间倒序,含作者、信息、哈希)

git log –oneline

简洁显示提交历史(每行一个哈希+提交信息)

git log –graph

图形化显示分支合并历史

git branch

查看本地所有分支(当前分支前标*)

git branch -a

查看本地+远程所有分支

git branch -v

查看分支最后一次提交信息

git remote -v

查看远程仓库地址(fetch/push)

二、分支操作

命令

用途

git branch <分支名>

创建新分支(基于当前分支)

git checkout <分支名>

切换到指定分支

git checkout -b <分支名>

创建并切换到新分支(等价于branch + checkout)

git switch <分支名>

Git 2.23+推荐的分支切换命令(替代checkout)

git switch -c <分支名>

创建并切换到新分支(替代checkout -b)

git branch -d <分支名>

删除本地已合并分支(未合并需用-D强制删除)

git push origin –delete <分支名>

删除远程分支

git branch -m <旧分支名> <新分支名>

重命名本地分支

三、提交与推送(本地 → 远程)

命令

用途

git add <文件名>

将指定文件加入暂存区

git add .

将所有修改/新增文件加入暂存区(不含删除)

git add -A

将所有修改/新增/删除文件加入暂存区

git commit -m “提交信息”

暂存区文件提交到本地仓库(需写清晰信息)

git commit –amend

修改最后一次提交(补充信息/追加文件)

git push

将本地分支推送到远程对应分支

git push -u origin <分支名>

首次推送本地分支到远程,并关联追踪

四、远程仓库操作

命令

用途

git clone <远程仓库地址>

克隆远程仓库到本地

git remote add origin <远程仓库地址>

本地仓库关联远程仓库(命名为 origin)

git fetch

拉取远程仓库最新分支/提交(不合并到本地)

git pull

拉取远程分支并合并到本地当前分支(等价于fetch + merge)

git pull –rebase

拉取远程分支并变基到本地(避免多余合并提交)

五、撤销与回退

命令

用途

git restore <文件名>

撤销工作区文件的修改(Git 2.23+,替代checkout –)

git restore –staged <文件名>

将暂存区文件撤回工作区(撤销暂存)

git reset HEAD <文件名>

旧版 Git 撤销暂存(等价于restore –staged)

git reset –hard <提交哈希>

回退到指定提交(工作区+暂存区同步回退,谨慎用)

git reset –soft <提交哈希>

回退到指定提交(保留工作区修改,暂存区重置)

git revert <提交哈希>

创建新提交“撤销”指定提交的修改(不删除历史,安全)

六、合并与变基

命令

用途

git merge <分支名>

将指定分支合并到当前分支(如git merge dev)

git rebase <分支名>

将当前分支变基到指定分支(线性化提交历史,替代 merge)

git merge –abort

合并冲突时,终止合并并回退状态

git rebase –abort

变基冲突时,终止变基并回退

七、临时存储(Stash)

命令

用途

git stash

将工作区未提交修改临时存储(干净切换分支)

git stash list

查看所有 stash 记录

git stash apply

恢复最近一次 stash(保留 stash 记录)

git stash pop

恢复最近一次 stash(并删除 stash 记录)

git stash drop

删除最近一次 stash 记录

八、标签管理(版本标记)

命令

用途

git tag

查看所有标签

git tag <标签名>

创建轻量标签(如git tag v1.0)

git tag -a <标签名> -m “标签信息”

创建附注标签(含详细信息)

git push origin <标签名>

推送标签到远程

九、Git 提交信息关键字规范

遵循约定式提交规范,通过固定关键字明确提交类型,可使提交历史更清晰、可维护,同时支持自动化生成版本日志和语义化版本号。以下是核心关键字及使用规范:

1、核心类型关键字(必选)

格式:<类型>: <描述>(描述简洁明了,首字母小写,不超过 50 字符)

  1. feat: 新增功能
  • 说明:对应语义化版本的 MINOR 版本更新(次版本号递增)
  • 示例:feat: 添加用户登录验证码功能
  • 适用场景:新增业务功能、新增 API 接口、新增页面等
  1. fix: 修复缺陷
  • 说明:对应语义化版本的 PATCH 版本更新(修订号递增)
  • 示例:fix: 修复手机号格式验证错误的问题
  • 适用场景:修复业务逻辑 bug、修复 UI 显示异常、修复接口报错等
  1. docs: 文档修改
  • 说明:仅修改文档内容,不涉及代码逻辑变更
  • 示例:docs: 更新 API 接口文档的参数说明
  • 适用场景:修改 README.md、补充代码注释、更新技术文档等
  1. style: 代码格式调整
  • 说明:不影响代码功能的格式优化,不涉及逻辑变更
  • 示例:style: 统一变量命名为驼峰式
  • 适用场景:调整缩进、修正空格、格式化代码、修改命名规范等
  1. refactor: 代码重构
  • 说明:既不新增功能,也不修复缺陷,仅优化代码结构
  • 示例:refactor: 拆分用户信息处理的工具函数
  • 适用场景:优化代码逻辑、拆分/合并函数、替换第三方库(无功能变更)等
  1. perf: 性能优化
  • 说明:专注于提升代码运行效率、降低资源消耗
  • 示例:perf: 优化商品列表查询的 SQL 语句
  • 适用场景:优化数据库查询、减少内存占用、提升接口响应速度等
  1. test: 测试相关修改
  • 说明:添加或修改测试代码,不影响生产代码逻辑
  • 示例:test: 为登录功能补充单元测试用例
  • 适用场景:新增单元测试/集成测试、修复测试用例、调整测试配置等
  1. build: 构建流程/工具链修改
  • 说明:影响项目构建、打包流程的配置修改
  • 示例:build: 升级 webpack 至 5.x 版本
  • 适用场景:修改 webpack/vite 配置、升级依赖包版本、调整打包脚本等
  1. ci: CI/CD 配置修改
  • 说明:调整持续集成/持续部署相关配置
  • 示例:ci: 添加自动化部署到测试环境的 CI 任务
  • 适用场景:修改 GitHub Actions、Jenkinsfile、GitLab CI 配置等
  1. chore: 琐碎修改(其他)
  • 说明:不涉及代码核心逻辑、文档、测试、构建的其他琐碎修改
  • 示例:chore: 删除项目中过期的临时文件
  • 适用场景:清理日志、删除无用文件、调整目录结构等
  1. revert: 回滚提交
  • 说明:回滚之前的某次提交
  • 示例:revert: revert “feat: 添加用户登录验证码功能”
  • 适用场景:之前的提交引入问题,需要恢复到历史版本

2、可选补充:增强提交信息的精准度

  1. 作用域(Scope)

格式:<类型>(<作用域>): <描述>

说明:指定提交影响的模块/范围,使信息更具体

示例:

  • feat(user): 添加用户个人资料编辑功能(作用域:user 模块)
  • fix(order): 修复订单支付状态同步异常(作用域:order 模块)
  1. 破坏性变更(Breaking Change)

格式:<类型>! : <描述> 或 正文末尾添加 BREAKING CHANGE: <变更说明>

说明:表明包含不兼容的 API 变更,对应语义化版本的 MAJOR 版本更新(主版本号递增)

示例:

  • feat(api)!: 修改用户信息接口的返回格式
  • refactor! : 移除 v1 版本废弃的 API 接口
  1. 详细描述(Body)与脚注(Footer)

格式:

feat: 新增用户登录验证码功能

详细描述:

  • 支持短信验证码登录方式
  • 验证码有效期为 5 分钟
  • 连续 3 次错误后锁定 10 分钟

关联 issue: #123

说明:

  • Body:详细说明提交的背景、修改内容、实现思路(可选)
  • Footer:关联 issue、指定 reviewers、标注破坏性变更等(可选)

三、完整提交示例

feat(order): 新增订单超时自动撤销功能

  • 添加定时任务,每 10 分钟检测超时未支付订单
  • 超时订单自动改为”撤销”状态,并释放库存
  • 向用户推送订单撤销通知

3、使用提议

  1. 提交信息需真实反映修改内容,避免模糊表述(如“修改 bug”“优化代码”)
  2. 一次提交对应一个独立功能/修复,避免多类型修改混在一个提交中
  3. 团队协作时统一关键字使用规范,提议结合项目文档明确作用域划分
  4. 可配合工具(如 commitlint)强制校验提交格式,确保规范落地
© 版权声明

相关文章

暂无评论

none
暂无评论...