GIT

Git 流程

  1. 新建分支并切换
1
git check out -b <new_branch_name>
  1. 将文件加入缓存区·
1
git add <file_path>
  1. 提交文件
1
git commit -m "修改记录"
  1. 提交到远程仓库
1
git push -u <new_branch_name>

Git 常用命令一览

以下是 Git 常用命令的分类列表。

一、 基础配置

首次使用 Git 时，需要配置您的用户信息。

命令 描述
git config --global user.name "[name]" 设置全局的用户名
git config --global user.email "[email]" 设置全局的用户邮箱
git config --list 查看所有配置信息
git help [command] 获取命令的帮助文档

二、 创建仓库

命令 描述
git init [project-name] 在当前目录或指定目录下创建一个新的本地 Git 仓库
git clone [url] 克隆一个远程仓库到本地

三、 工作区、暂存区和版本库操作 (日常使用最频繁)

这是 Git 工作流程的核心，涉及文件的修改、暂存和提交。

命令 描述
git status 查看工作区和暂存区的状态，显示文件的修改、添加等情况
git add [file] 将指定文件的修改添加到暂存区
git add . 将当前目录下所有文件的修改添加到暂存区
git commit -m "[message]" 将暂存区的所有内容提交到本地仓库，并附上提交信息
git commit --amend 修改最后一次的提交（前提是该提交还未推送到远程）
git diff 查看工作区与暂存区之间的差异
git diff --staged 或 git diff --cached 查看暂存区与上次提交之间的差异
git diff HEAD 查看工作区与上次提交之间的差异
git rm [file] 从工作区和版本库中删除文件
git mv [old-file] [new-file] 重命名文件，并将改动添加到暂存区

四、 查看历史和撤销修改

命令 描述
git log 查看提交历史
git log --oneline 以单行简洁模式查看提交历史
git log --graph 以图形化方式查看分支合并历史
git reflog 查看所有分支的所有操作记录（包括已删除的 commit）
git checkout -- [file] 撤销工作区对指定文件的修改（恢复到最近一次 add 或 commit 的状态）
git reset HEAD [file] 将文件从暂存区撤出，但保留工作区的修改
git reset --hard [commit-id] （危险） 重置当前分支的 HEAD 到指定的提交，并丢弃之后的所有提交和工作区的修改
git revert [commit-id] 创建一个新的提交来撤销指定的提交，是一种更安全的回滚方式

五、 分支管理

分支是 Git 的核心功能之一，允许多人并行开发。

命令 描述
git branch 列出所有本地分支
git branch -a 列出所有本地和远程分支
git branch [branch-name] 创建一个新的分支
git checkout [branch-name] 切换到指定的分支
git checkout -b [branch-name] 创建并立即切换到新的分支
git merge [branch-name] 将指定分支的更改合并到当前分支
git rebase [branch-name] 将当前分支的提交“变基”到指定分支的顶端
git branch -d [branch-name] 删除一个已经合并过的本地分支
git branch -D [branch-name] （强制） 删除一个本地分支，无论其是否已经合并

六、 远程协作

与团队成员共享代码和协作。

命令 描述
git remote -v 查看已配置的远程仓库地址
git remote add [name] [url] 添加一个新的远程仓库
git fetch [remote-name] 从远程仓库下载最新的对象和引用，但 不 合并到本地分支
git pull [remote-name] [branch-name] 从远程仓库拉取最新代码并与本地分支合并（相当于 git fetch + git merge）
git push [remote-name] [branch-name] 将本地分支的提交推送到远程仓库
git push [remote-name] --delete [branch-name] 删除一个远程分支

七、 标签管理

通常用于标记发布版本。

命令 描述
git tag 列出所有标签
git tag [tag-name] 在当前提交上创建一个轻量标签
git tag -a [tag-name] -m "[message]" 创建一个带附注的标签，并包含信息
git push [remote-name] [tag-name] 推送一个本地标签到远程仓库
git push [remote-name] --tags 推送所有本地标签到远程仓库

Git 提交命名规范

目前社区最流行、最完善的方案是 Conventional Commits (约定式提交) 规范。
约定式提交将 Commit Message 格式化，主要包含三个部分：Header、Body 和 Footer。

  • Header (必需): 包含本次提交的类型（type）、作用范围（scope）和简短描述（subject）。
  • Body (可选): 对本次提交的详细描述，解释修改的动机和前因后果。
  • Footer (可选): 通常用于两种情况：
    1. Breaking Changes (破坏性更新): 以 BREAKING CHANGE: 开头，描述不兼容的改动。
    2. 关联 Issue: 例如 Closes #123, Fixes #456。

Header 的构成 (<type>(<scope>): <subject>)

1. type (类型) - 你的提交属于哪种性质？

类型 (Type) 说明
feat **新功能 (Feature)**：增加了一个新的功能
fix **Bug 修复 (Bug Fix)**：修复了一个已知的 Bug
docs **文档 (Documentation)**：仅仅修改了文档，例如 README、API 文档等
style **代码样式 (Styling)**：不影响代码逻辑的修改，例如格式化、缺少分号等
refactor **代码重构 (Refactoring)**：既不是修复 Bug 也不是增加新功能的代码修改
perf **性能优化 (Performance)**：提升代码性能的修改
test **测试 (Tests)**：增加或修改测试用例
build **构建系统 (Build System)**：影响构建系统或外部依赖的修改，例如 package.json
ci **持续集成 (Continuous Integration)**：修改 CI/CD 配置文件或脚本
chore **杂项 (Chores)**：其他不修改源码或测试的提交，例如更新 .gitignore
revert **回滚 (Revert)**：撤销之前的某次提交

2. scope (范围) - 本次修改影响了哪个模块？

Scope 是可选的，用于说明本次提交影响的范围，比如某个模块、组件或功能。

  • feat(auth): ... (认证模块的新功能)
  • fix(parser): ... (修复了解析器的 Bug)
  • docs(readme): ... (修改了 README 文档)
  • test(user-service): ... (为用户服务添加测试)

3. subject (主题) - 本次修改做了什么？

Subject 是对修改的简短、精炼的描述。请遵循以下黄金原则：

  • 使用动词开头的祈使句，例如 add, fix, update, remove，而不是 added, fixed。
  • 首字母小写。
  • 结尾不加句号。
  • 尽量不超过 50 个字符。

不同场景下的命名实例

掌握了基本结构后，我们来看在具体场景下如何应用。

场景 1：开发一个新功能

场景描述：你为网站的认证模块添加了“使用 Google 账号登录”的功能。

1
git commit -m "feat(auth): add google sign-in provider"

场景 2：修复一个紧急的线上 Bug

场景描述：用户列表的分页功能在计算总页数时出错，导致最后一页显示不正确。这个问题关联了工单系统中的 #235 号问题。

1
2
3
4
5
6
git commit -m "fix(api): correct total page calculation for user list

The off-by-one error in pagination logic was causing an incorrect 'totalPages' value.
This commit adjusts the calculation to use Math.ceil().

Fixes: #235"

注意: Fixes: #235 会在 GitHub 等平台上自动关闭对应的 Issue。

场景 3：重构代码

场景描述：你发现获取用户信息的服务层代码太臃肿，决定将其拆分成多个更小的、可复用的函数，但对外的功能和表现没有变化。

Bash

1
2
3
4
git commit -m "refactor(service): simplify user data fetching logic

Decomposed the monolithic 'getUserProfile' function into smaller, more manageable units.
No functional changes are introduced. This improves readability and maintainability."

场景 4：修改文档

场景描述：你更新了项目的 README.md 文件，添加了关于如何设置本地开发环境的说明。

Bash

1
git commit -m "docs: add local development setup guide to README"

场景 5：调整代码格式

场景描述：你运行了 prettier 或 eslint --fix 工具，格式化了整个项目中的代码。

Bash

1
git commit -m "style: format code across the project with prettier"

场景 6：引入破坏性更新 (Breaking Change)

场景描述：你将一个公共 API 的参数 userId 重命名为 userUUID，这是一个不向后兼容的改动。

Bash

1
2
3
git commit -m "feat(api): rename userId parameter to userUUID for clarity

BREAKING CHANGE: The 'userId' parameter in the '/v1/user/:userId' endpoint has been renamed to 'userUUID'. All API consumers must update their requests to use the new parameter name."

重点: BREAKING CHANGE: 必须大写，并放在 Body 或 Footer 的开头，这对于版本管理和发布通知至关重要。

场景 7：首次提交项目

场景描述：你刚刚使用 create-react-app 创建了一个新项目。

Bash

1
2
3
4
5
# 方案一：作为新功能的起点
git commit -m "feat: initial commit from create-react-app"

# 方案二：作为一次构建/杂项任务
git commit -m "chore: initial project setup"

两者皆可，feat 更强调这是项目的第一个功能版本，chore 更强调这是初始化项目的管理性任务。

场景 8：撤销之前的提交

场景描述：你发现上一个提交 a8e3d4f 引入了严重的 Bug，需要立刻撤销。

通常使用 git revert a8e3d4f 命令，它会自动生成一个 Commit Message，你只需要确认或微调即可。

1
2
3
revert: feat(auth): add google sign-in provider

This reverts commit a8e3d4f8a1d7c0e8b2a3c6f1a8e3d4f8a1d7c0e8.

小Tips

  1. 一个提交只做一件事: 保持提交的原子性。不要把新功能、Bug 修复和代码格式化混在一个 Commit 里。
  2. 用好 Body: 当 Header 无法说清时，务必使用 Body 详细解释“为什么”要这样改，而不仅仅是“改了什么”。

Git 不同场景模拟

Git 错误add如何取消

Git 错误commit后如何取消