前言
Git 是现代软件开发中不可或缺的版本控制工具。无论是个人项目还是团队协作,掌握 Git 的核心命令都能大幅提升开发效率。本文将系统性地介绍 Git 的常用命令,帮助你入门~。
1. 起步与配置 (Setup)
场景:换了新电脑,或者刚开始接手一个新项目。
基础配置
# 设置用户名git config --global user.name "你的名字"
# 设置邮箱git config --global user.email "your.email@example.com"
# 查看配置git config --list初始化与克隆
| 命令 | 说明 | 常用场景 |
|---|---|---|
git init | 初始化仓库 | 把一个普通的文件夹变成 Git 仓库 |
git clone [url] | 克隆仓库 | 把远程代码下载到本地 |
git clone -b [分支名] [url] | 克隆指定分支 | 只想下载特定分支,不需要完整历史 |
示例:
# 初始化新项目mkdir my-projectcd my-projectgit init
# 克隆远程仓库git clone https://github.com/username/repo.git
# 只克隆 develop 分支git clone -b develop https://github.com/username/repo.git2. 日常开发 (Daily Workflow)
场景:每天写代码时重复频率最高的操作。
核心命令
| 命令 | 说明 | 常用场景 |
|---|---|---|
git status | 查看状态 | 写代码前、提交前看一眼,确保知道自己改了什么 |
git add . | 添加所有文件 | 准备提交,把所有修改过的文件放到”暂存区” |
git add [文件名] | 添加指定文件 | 只想提交部分文件时使用 |
git commit -m "说明" | 提交 | 把暂存区的内容存档。“说明”要写清楚做了什么 |
git log | 查看历史 | 看看之前提交了什么,或者找 Commit ID |
git log --oneline | 简洁历史 | 一行显示一个提交,更清晰 |
标准工作流程
# 1. 查看当前状态git status
# 2. 添加修改的文件git add .
# 3. 提交更改git commit -m "feat: add user login feature"
# 4. 查看提交历史git log --oneline提交信息规范
本节参考 约定式提交(Conventional Commits) 规范。良好的提交信息能让团队协作更顺畅,也便于自动生成 CHANGELOG。
提交信息结构
<类型>[可选 作用域]: <描述>
[可选 正文]
[可选 脚注]常用类型
| 类型 | 说明 |
|---|---|
feat | 新功能(对应语义化版本的 MINOR) |
fix | 修复 Bug(对应语义化版本的 PATCH) |
docs | 仅文档更新 |
style | 不影响代码含义的格式调整(空格、分号等) |
refactor | 既不修复 Bug 也不添加功能的代码重构 |
perf | 提升性能的代码变更 |
test | 添加或修正测试 |
build | 影响构建系统或外部依赖的变更(如 npm、webpack) |
ci | CI 配置文件和脚本的变更 |
chore | 其他不修改 src 或 test 的变更 |
revert | 撤销先前的提交 |
post | 新博客文章(自定义类型) |
作用域与 BREAKING CHANGE
- 作用域(scope):可选,用括号包裹在类型后面,表示影响范围,如
feat(auth): add login - BREAKING CHANGE:表示不兼容的 API 变更(对应语义化版本的 MAJOR),有两种写法:
- 在类型/作用域后加
!:feat!: remove deprecated API - 在脚注中声明:
BREAKING CHANGE: 移除了旧的认证接口
- 在类型/作用域后加
示例:
# 基本用法git commit -m "feat: implement user authentication"git commit -m "fix: resolve login redirect issue"git commit -m "docs: update API documentation"
# 带作用域git commit -m "feat(auth): add OAuth2 support"git commit -m "fix(api): handle null response correctly"
# 带 BREAKING CHANGEgit commit -m "feat!: drop support for Node 12"3. 分支管理 (Branching)
场景:开发新功能、修复 Bug、或者做测试,不想影响主线代码。
分支操作
| 命令 | 说明 | 常用场景 |
|---|---|---|
git branch | 列出本地分支 | 看看现在有哪些分支,自己在哪 |
git branch -r | 列出远程分支 | 查看远程仓库有哪些分支 |
git branch -vv | 分支详细信息 | 查看每个分支的最新提交和上游追踪关系 |
git branch [分支名] | 创建分支 | 创建新分支但不切换 |
git branch -m [旧名] [新名] | 重命名分支 | 分支名写错了或想改个更好的名字 |
git switch -c [新分支名] | 创建并切换 | 开始写新功能前第一件事 |
git switch [分支名] | 切换分支 | 在不同分支之间切换 |
git branch -d [分支名] | 删除分支 | 功能开发完并合并后,清理垃圾分支 |
git branch -D [分支名] | 强制删除 | 删除未合并的分支(慎用) |
:::tip 为什么用 git switch 而不是 git checkout?
Git 2.23(2019)将原先身兼多职的 checkout 拆分为两个专用命令:switch 负责分支切换,restore 负责文件恢复。这样语义更清晰,不容易误操作。
:::
分支工作流示例
# 查看所有分支git branch -a
# 创建并切换到新分支git switch -c feature/user-profile
# 在新分支上开发...# 修改代码、提交...
# 切换回主分支git switch main
# 删除已合并的分支git branch -d feature/user-profile分支命名规范
feature/功能名- 新功能开发bugfix/问题描述- Bug 修复hotfix/紧急修复- 生产环境紧急修复test/测试内容- 测试分支release/版本号- 发布分支
4. 合并与同步 (Merge & Sync)
场景:测试通过了,或者需要拉取别人的代码更新。
合并操作
| 命令 | 说明 | 常用场景 |
|---|---|---|
git merge [分支名] | 普通合并 | 保留完整历史。用于同步上游代码 |
git merge --squash [分支名] | 压缩合并 | 把开发分支的多个提交压缩成一个干净的提交 |
远程同步
| 命令 | 说明 | 常用场景 |
|---|---|---|
git fetch | 获取远程信息 | 只看不动。告诉本地 Git 远程有哪些更新 |
git pull | 拉取并合并 | = git fetch + git merge。拉取远程代码并更新本地 |
git pull --rebase | 变基拉取 | 保持提交历史线性,避免不必要的合并提交 |
git push origin [分支名] | 推送 | 把本地的修改上传到远程仓库 |
git push -u origin [分支名] | 推送并关联 | 第一次推送新分支时使用 |
合并工作流示例
# 场景:将 feature 分支合并到 main
# 1. 切换到主分支git checkout main
# 2. 拉取最新代码git pull origin main
# 3. 合并 feature 分支(普通合并)git merge feature/new-feature
# 或者使用压缩合并(推荐用于功能分支)git merge --squash feature/new-featuregit commit -m "feat: add new feature"
# 4. 推送到远程git push origin main
# 5. 删除已合并的分支git branch -d feature/new-feature5. 后悔药 (Undo & Fix)
场景:写错了、删错了、或者提交早了。
撤销操作
| 命令 | 说明 | 常用场景 |
|---|---|---|
git checkout -- [文件名] | 丢弃修改 | 还没 add 时。改乱了一个文件,想恢复到上次提交的样子 |
git restore [文件名] | 丢弃修改(新版) | Git 2.23+ 推荐使用,功能同上 |
git reset HEAD [文件名] | 取消暂存 | 已经 add 但没 commit 时。不小心把不该交的文件加进去了 |
git reset --soft HEAD^ | 撤销最近一次提交 | 已经 commit 了。发现注释写错了,或者漏了个文件。撤销提交记录,但保留代码修改 |
git reset --mixed HEAD^ | 撤销提交和暂存 | 撤销提交,同时取消暂存,但保留工作区修改(默认模式) |
git reset --hard HEAD^ | 毁灭性重置 | 慎用。彻底放弃所有修改,回到上一个版本 |
git revert [commit-id] | 安全撤销 | 创建一个新提交来抵消之前的修改,不改变历史 |
撤销场景示例
场景 1:还没 add,想丢弃修改
# 查看修改git status
# 丢弃单个文件的修改git checkout -- index.js
# 或使用新命令git restore index.js
# 丢弃所有修改git checkout -- .场景 2:已经 add,想取消暂存
# 取消暂存单个文件git reset HEAD index.js
# 取消所有暂存git reset HEAD .场景 3:已经 commit,想修改提交
# 撤销最近一次提交,保留修改git reset --soft HEAD^
# 重新修改代码...
# 重新提交git add .git commit -m "feat: correct implementation"场景 4:想完全回到上一个版本
# 查看提交历史git log --oneline
# 回到指定版本(危险操作!)git reset --hard [commit-id]
# 或回到上一个版本git reset --hard HEAD^场景 5:安全地撤销已推送的提交
# 使用 revert 创建反向提交git revert [commit-id]
# 推送到远程git push origin main重置级别对比
| 模式 | HEAD | 暂存区 | 工作区 | 使用场景 |
|---|---|---|---|---|
--soft | 移动 | 不变 | 不变 | 只想修改提交信息或重新组织提交 |
--mixed | 移动 | 重置 | 不变 | 想重新选择要提交的文件(默认) |
--hard | 移动 | 重置 | 重置 | 完全放弃所有修改(危险) |
6. Fork 仓库同步 (Upstream)
场景:你的项目是 Fork 别人的仓库,想保持和原作者同步,同时自己开发功能。
配置上游仓库
# 1. 查看当前远程仓库git remote -v
# 2. 添加上游仓库(原作者的仓库)git remote add upstream [原作者仓库URL]
# 3. 验证配置git remote -v# 应该看到:# origin https://github.com/你的用户名/repo.git (fetch)# origin https://github.com/你的用户名/repo.git (push)# upstream https://github.com/原作者/repo.git (fetch)# upstream https://github.com/原作者/repo.git (push)同步上游更新
# 1. 获取上游仓库的更新git fetch upstream
# 2. 切换到主分支git checkout main
# 3. 合并上游的更新(普通合并,保留历史)git merge upstream/main
# 4. 推送到你的 GitHubgit push origin main完整的 Fork 工作流
# === 初始设置 ===# Fork 仓库后,克隆到本地git clone https://github.com/你的用户名/repo.gitcd repo
# 添加上游仓库git remote add upstream https://github.com/原作者/repo.git
# === 开发新功能 ===# 1. 同步上游最新代码git fetch upstreamgit checkout maingit merge upstream/maingit push origin main
# 2. 创建功能分支git checkout -b feature/awesome-feature
# 3. 开发、提交git add .git commit -m "feat: implement awesome feature"
# 4. 推送到你的 GitHubgit push origin feature/awesome-feature
# 5. 在 GitHub 上创建 Pull Request
# === 功能开发完成后 ===# 6. 合并回主分支(使用压缩合并保持历史整洁)git checkout maingit merge --squash feature/awesome-featuregit commit -m "feat: add awesome feature"git push origin main
# 7. 删除功能分支git branch -d feature/awesome-featuregit push origin --delete feature/awesome-feature处理冲突
当上游更新和你的修改冲突时:
# 1. 尝试合并上游更新git merge upstream/main
# 如果出现冲突# 2. 查看冲突文件git status
# 3. 手动解决冲突(编辑文件)# 冲突标记:# <<<<<<< HEAD# 你的修改# =======# 上游的修改# >>>>>>> upstream/main
# 4. 标记冲突已解决git add [冲突文件]
# 5. 完成合并git commit -m "merge: resolve conflicts with upstream"
# 6. 推送git push origin main7. 常用技巧与最佳实践
查看差异
# 查看工作区和暂存区的差异git diff
# 查看暂存区和最近提交的差异git diff --staged
# 查看两个分支的差异git diff main..feature/new-feature
# 查看某个文件的修改历史git log -p [文件名]暂存工作进度
# 暂存当前工作(临时保存修改)git stash
# 查看暂存列表git stash list
# 恢复最近的暂存git stash pop
# 恢复指定的暂存git stash apply stash@{0}
# 删除暂存git stash drop stash@{0}使用场景: 正在开发功能时,突然需要切换分支修复紧急 Bug。
# 1. 暂存当前工作git stash
# 2. 切换到主分支修复 Buggit checkout maingit checkout -b hotfix/critical-bug# 修复 Bug...git commit -m "fix: critical bug"
# 3. 切回原分支,恢复工作git checkout feature/my-featuregit stash pop标签管理
# 创建轻量标签git tag v1.0.0
# 创建附注标签(推荐)git tag -a v1.0.0 -m "Release version 1.0.0"
# 查看所有标签git tag
# 推送标签到远程git push origin v1.0.0
# 推送所有标签git push origin --tags
# 删除本地标签git tag -d v1.0.0
# 删除远程标签git push origin --delete v1.0.08. 经验总结与建议
Git 工作流核心理念
Git 的核心工作流:
分支开发 → 测试验证 → 压缩合并 → 生产部署这个流程能够:
- 保持主分支的整洁和稳定
- 让每个功能的开发过程独立且可追溯
- 方便团队协作和代码审查
- 支持快速回滚和问题定位
最佳实践建议
1. 提交频率与粒度
- 频繁提交:每完成一个小功能或修复就提交
- 原子提交:每次提交只做一件事
- 有意义的提交信息:让别人(和未来的自己)能快速理解
# 好的提交git commit -m "feat: add email validation to login form"git commit -m "fix: resolve null pointer in user service"git commit -m 'feat: add 草饲 thephix feature'
# 不好的提交git commit -m "update"git commit -m "fix bug"git commit -m "changes"2. 分支管理策略
- 主分支保护:
main或master分支应该始终保持可部署状态 - 功能分支:每个新功能都在独立分支开发
- 及时清理:合并后删除已完成的分支
- 定期同步:经常从主分支拉取更新,避免冲突累积
3. 危险操作注意事项
以下命令使用前请三思:
| 命令 | 风险 | 建议 |
|---|---|---|
git reset --hard | 丢失所有未提交的修改 | 确认无重要修改后再用 |
git push --force | 覆盖远程历史,影响团队 | 仅在个人分支使用 |
git clean -fd | 删除所有未跟踪文件 | 先用 -n 预览 |
git rebase | 改写提交历史 | 不要在公共分支使用 |
4. 团队协作建议
- Pull Request 流程:不要直接推送到主分支,使用 PR 进行代码审查
- 保持同步:每天开始工作前先
git pull - 解决冲突:遇到冲突及时沟通,不要盲目合并
- 文档化:重要的分支策略和工作流写入
CONTRIBUTING.md
5. 跨平台开发注意
- 行尾符处理:配置
.gitattributes统一处理* text=auto*.sh text eol=lf*.bat text eol=crlf - 文件权限:Windows 和 Unix 系统的文件权限处理不同
- 符号链接:Windows 需要特殊配置(参考我的另一篇文章)
学习路径建议
如果你是 Git 初学者,建议按以下顺序掌握:
-
基础阶段(必须掌握)
git init,git clonegit add,git commit,git pushgit status,git log
-
进阶阶段(日常开发)
git branch,git checkoutgit merge,git pullgit stash
-
高级阶段(团队协作)
git rebasegit cherry-pickgit reflog(救命稻草)
-
专家阶段(深入理解)
- Git 内部原理
- 自定义 Git Hooks
- 复杂冲突解决
常见问题速查
| 问题 | 解决方案 |
|---|---|
| 提交了不该提交的文件 | git reset --soft HEAD^ 然后重新选择文件 |
| 想修改最近的提交信息 | git commit --amend |
| 不小心删除了分支 | git reflog 找到提交 ID,然后 git checkout -b 分支名 [commit-id] |
| 想撤销已推送的提交 | 使用 git revert 而不是 reset |
| 合并时出现大量冲突 | 考虑使用 git merge --abort 取消合并,重新规划策略 |
9. 总结
Git 是一个强大而灵活的工具,掌握它需要时间和实践。本文涵盖了从基础配置到高级操作的常用命令,但最重要的是理解 Git 的核心思想:
- 版本控制:每次提交都是一个快照
- 分支管理:并行开发,互不干扰
- 协作流程:通过合并和同步实现团队协作
最后的建议: 不要害怕犯错。Git 的设计理念就是让你能够安全地实验和回滚。即使执行了 git reset --hard,通常也能通过 git reflog 找回丢失的提交。
祝你在 Git 的世界里大展身手!
参考资料
- Pro Git 官方书籍(中文版,强烈推荐)
- Git 官方文档
- 约定式提交规范 v1.0.0
- GitHub Git 备忘单
- Learn Git Branching(交互式学习)
本文基于实际开发经验总结,持续更新中。如有问题或建议,欢迎交流讨论。
部分信息可能已经过时









