mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4mobile wallpaper 5mobile wallpaper 6
3932 字
20 分钟
G i t 一 定 要 用 对

前言#

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-project
cd my-project
git init
# 克隆远程仓库
git clone https://github.com/username/repo.git
# 只克隆 develop 分支
git clone -b develop https://github.com/username/repo.git

2. 日常开发 (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)
ciCI 配置文件和脚本的变更
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 CHANGE
git 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-feature
git commit -m "feat: add new feature"
# 4. 推送到远程
git push origin main
# 5. 删除已合并的分支
git branch -d feature/new-feature

5. 后悔药 (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. 推送到你的 GitHub
git push origin main

完整的 Fork 工作流#

# === 初始设置 ===
# Fork 仓库后,克隆到本地
git clone https://github.com/你的用户名/repo.git
cd repo
# 添加上游仓库
git remote add upstream https://github.com/原作者/repo.git
# === 开发新功能 ===
# 1. 同步上游最新代码
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
# 2. 创建功能分支
git checkout -b feature/awesome-feature
# 3. 开发、提交
git add .
git commit -m "feat: implement awesome feature"
# 4. 推送到你的 GitHub
git push origin feature/awesome-feature
# 5. 在 GitHub 上创建 Pull Request
# === 功能开发完成后 ===
# 6. 合并回主分支(使用压缩合并保持历史整洁)
git checkout main
git merge --squash feature/awesome-feature
git commit -m "feat: add awesome feature"
git push origin main
# 7. 删除功能分支
git branch -d feature/awesome-feature
git 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 main

7. 常用技巧与最佳实践#

查看差异#

# 查看工作区和暂存区的差异
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. 切换到主分支修复 Bug
git checkout main
git checkout -b hotfix/critical-bug
# 修复 Bug...
git commit -m "fix: critical bug"
# 3. 切回原分支,恢复工作
git checkout feature/my-feature
git 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.0

8. 经验总结与建议#

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. 分支管理策略#

  • 主分支保护mainmaster 分支应该始终保持可部署状态
  • 功能分支:每个新功能都在独立分支开发
  • 及时清理:合并后删除已完成的分支
  • 定期同步:经常从主分支拉取更新,避免冲突累积

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 初学者,建议按以下顺序掌握:

  1. 基础阶段(必须掌握)

    • git init, git clone
    • git add, git commit, git push
    • git status, git log
  2. 进阶阶段(日常开发)

    • git branch, git checkout
    • git merge, git pull
    • git stash
  3. 高级阶段(团队协作)

    • git rebase
    • git cherry-pick
    • git reflog(救命稻草)
  4. 专家阶段(深入理解)

    • 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 的世界里大展身手!


参考资料#


本文基于实际开发经验总结,持续更新中。如有问题或建议,欢迎交流讨论。

分享

如果这篇文章对你有帮助,欢迎分享给更多人!

G i t 一 定 要 用 对
https://l1ngg.info/posts/tech/howtousegit/
作者
L1ngg
发布于
2026-01-19
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

封面
Sample Song
Sample Artist
封面
Sample Song
Sample Artist
0:00 / 0:00