写在前面：为什么你学了 Git 还是用不好？

很多开发者都有这样的经历：看了一堆 Git 教程，记住了几十条命令，可一到实际工作，面对冲突时还是手忙脚乱，一不小心就覆盖了同事的代码，或者把不该提交的文件推到了远程仓库。原因何在？

因为绝大多数教程只教「命令是什么」，却没告诉你「为什么要用这个命令」以及「在企业里怎么配合团队使用」。本文借鉴了一套经过验证的「6 阶段教学法」，从解决实际痛点出发，逐步深入到企业级落地，让你不仅会用 Git，更能用好 Git，成为团队中让人放心的版本控制专家。

本文覆盖的核心知识点：

  • Git 与 GitHub 的区别与联系

  • 工作区、暂存区、本地仓库、远程仓库

  • 分支的创建、切换、合并、删除

  • 代码的提交、推送、拉取、回退、重置

  • 合并冲突的解决

  • 标签的使用

  • cherry-pick 精选提交

  • Git Flow 工作流

阶段1：问题锚定——为什么需要版本控制？

1.1 场景化抛出问题

假设你是团队中的一名后端开发，正在开发一个电商系统。某天，产品经理要求你添加一个“用户积分”功能。你信心满满地开始写代码，可接下来的场景你熟悉吗？

场景A：代码回滚噩梦

  • 你修改了多个文件，想尝试一个新方案，但不确定是否能成功。

  • 你复制了一份代码备份，命名为 project_backup_20250401。

  • 改了半小时，发现新方案行不通，想回到之前的版本。但你发现备份文件夹里有很多文件已经过时，根本分不清哪个版本才是可用的。

  • 你只能凭记忆手动恢复，甚至可能丢失了最近修复的一个 Bug。

场景B：协作冲突大乱斗

  • 你和前端同事共用同一个项目文件夹，通过 QQ 或微信传递代码。

  • 同事发来一个更新包，你解压后覆盖了自己的文件，结果你之前写的接口全没了。

  • 或者你俩同时修改了同一个文件，最终版本全靠手动合并，每次合并都心惊胆战。

场景C：线上事故溯源难

  • 昨晚发布的新版本出现了一个严重 Bug，导致订单无法支付。

  • 你打开代码，却不知道到底是哪一行代码引发的，因为上次发布后你修改了十几个文件，改动分散在各处。

  • 领导问你“到底是谁改的”，你只能支支吾吾地说“可能是大家改的”。

这些场景在真实开发中每天都在发生。究其根本，是因为缺乏有效的版本控制。

1.2 技术定位梳理

Git 和 GitHub 正是为了解决上述问题而生的工具。

  • Git：一个分布式版本控制系统。它的核心价值是让开发者能够：

    • 记录每次修改（谁、什么时候、改了什么）

    • 随时回退到任意历史版本

    • 创建独立分支，在不影响主代码的前提下进行实验

    • 并行开发，多人同时修改同一项目而互不干扰

  • GitHub：一个基于 Git 的代码托管平台。它的核心价值是：

    • 作为远程中央仓库，供团队共享代码

    • 提供协作功能（Pull Request、Issues、Wiki）

    • 集成CI/CD、项目管理等开发工具链

简单说：Git 是工具，GitHub 是平台。Git 负责在你本地管理版本，GitHub 负责帮你把代码托管到云端，方便团队协作。

1.3 技术边界说明

  • Git 不能做什么：

    • 不能存储超大文件（如视频、数据库文件），但可以通过 Git LFS 扩展。

    • 不能自动解决冲突，最终决定权仍在开发者。

    • 不能取代项目文档或沟通。

  • GitHub 不能做什么：

    • 不能保证私有仓库的绝对安全（需配合权限管理）。

    • 不能完全替代专业的 CI/CD 工具（虽然 GitHub Actions 已很强大）。

    • 在国内访问速度可能受限，部分企业会选择 GitLab 或 Gitee。

阶段2：基础认知——Git 的核心概念与最小示例

2.1 核心概念拆解（大白话版）

2.1.1 工作区、暂存区、本地仓库、远程仓库

把 Git 管理代码的过程想象成在厨房做菜：

  • 工作区：你的厨房台面。你在这里切菜、配菜（修改文件），但还没下锅。

  • 暂存区：你的调料盘。你将要下锅的食材放到盘子里（git add），准备烹饪。

  • 本地仓库：你的锅。你把盘里的食材倒进锅里（git commit），开始烹饪，形成一个菜肴版本。

  • 远程仓库：餐厅的菜单库。你将做好的菜肴拍照上传到菜单（git push），其他食客（同事）就能看到并取用。

2.1.2 分支是什么？

分支就像在厨房里开辟多条操作台：

  • 主分支（main/master）：餐厅的正式菜单，只有通过试菜（测试）的菜肴才能放进去。

  • 功能分支（feature）：你为了研发一道新菜（新功能），单独开了一个台面。在这里你可以随意尝试，不用担心影响正式菜单。

  • 合并（merge）：新菜研发成功，你把它添加到正式菜单中。

2.1.3 Git 与 GitHub 的关系再深入

  • Git 是本地厨房里的所有工具和流程。

  • GitHub 是一个可以让你把厨房里的“菜谱”（代码）分享给全世界的平台，并且支持多人同时在一个菜谱上改进。

2.2 最小可运行示例

让我们通过一个最简单的例子，从零开始体验 Git 的全流程。

Step 1：安装 Git

  • 访问 https://git-scm.com/，下载对应操作系统的版本并安装。

  • 安装后打开终端（cmd 或 bash），输入 git --version，看到版本号即安装成功。

Step 2：配置用户信息（这是必须的，因为 Git 会记录每次提交是谁做的）

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

Step 3：初始化仓库并添加文件

# 创建一个新目录
mkdir my-project
cd my-project

# 初始化 Git 仓库（生成 .git 目录）
git init

# 创建一个文件
echo "Hello Git" > hello.txt

# 查看当前状态（可以看到 hello.txt 未被跟踪）
git status

Step 4：将文件添加到暂存区

git add hello.txt
# 或者添加所有变化：git add .
git status  # 现在文件变为绿色，表示已暂存

Step 5：提交到本地仓库

git commit -m "第一次提交：添加 hello.txt"
# 输出：1 file changed, 1 insertion(+)

Step 6：关联远程仓库并推送

  • 首先在 GitHub 上创建一个空仓库（不要勾选 Initialize with README）。

  • 复制仓库地址（如 https://github.com/yourname/my-project.git）。

# 添加远程仓库地址，起名为 origin
git remote add origin https://github.com/yourname/my-project.git

# 推送本地 main 分支到远程，并设置上游关联
git push -u origin main

至此，你已经在本地完成了一次版本记录，并将代码推送到了 GitHub。整个流程就是 Git 最基础的 add → commit → push。

2.3 核心原理极简讲解

2.3.1 Git 的提交对象

每次 git commit 都会生成一个提交对象，它包含：

  • 一个 40 位 SHA-1 哈希值作为唯一 ID（如 a1b2c3d...）

  • 作者、提交者、时间戳

  • 提交说明

  • 指向父提交的指针（第一次提交没有父提交）

  • 一个树对象，记录了当前所有文件的快照

Git 的版本历史实际上就是由这些提交对象串联成的一条有向无环图。

2.3.2 分支的本质

分支只是一个轻量级的指针，指向某个提交对象。默认分支叫 main 或 master，它指向最新的提交。当你创建一个新分支，比如 feature，只是新建了一个指向当前提交的指针。切换分支时，Git 会移动 HEAD 指针指向不同的分支。

正因为分支只是指针，所以创建和切换都非常快，这是 Git 比 SVN 等集中式版本控制高效的关键原因之一。

2.3.3 工作区、暂存区的底层

  • 工作区：你实际看到的文件。

  • 暂存区：对应 .git/index 文件，记录了下一次提交将要包含的文件列表及它们的哈希。

  • 本地仓库：.git/objects 目录下存储的所有对象。

当你 git add 时，Git 会计算文件内容的哈希，将文件压缩为 blob 对象存入 .git/objects，并将该文件的元信息更新到暂存区。git commit 时，Git 根据暂存区内容创建树对象，再创建提交对象。

阶段3：核心用法拆解——企业高频操作

3.1 按场景分类：个人开发与团队协作

我们将 Git 操作分为两大类，每类包含若干高频场景。

3.1.1 个人开发场景
场景 命令 说明
初始化仓库 git init 在现有项目中创建 Git 仓库
克隆远程仓库 git clone <url> 从 GitHub 等平台下载项目
查看状态 git status 随时查看哪些文件被修改、暂存
查看历史 git log
git log --oneline --graph		 查看提交记录，图形化展示分支
添加修改 git add <file>
git add .		 将指定文件或所有改动加入暂存区
提交 git commit -m "message" 将暂存区内容提交到本地仓库
推送到远程 git push 将本地提交推送到远程仓库
从远程拉取 git pull 拉取远程更新并合并到当前分支
查看差异 git diff
git diff --staged		 查看工作区与暂存区的差异，或暂存区与上次提交的差异
撤销工作区修改 git checkout -- <file>
git restore <file>		 丢弃工作区的改动（谨慎使用）
撤销暂存 git reset HEAD <file>
git restore --staged <file>		 将文件从暂存区移回工作区，保留修改
修改最后一次提交 git commit --amend 修改提交信息或补充遗漏的文件
3.1.2 团队协作场景
场景 命令 说明
创建分支 git branch <branch-name> 创建新分支
切换分支 git checkout <branch-name>
git switch <branch-name>		 切换到指定分支（推荐 switch）
创建并切换 git checkout -b <branch-name>
git switch -c <branch-name>		 创建分支并立即切换
合并分支 git merge <branch-name> 将指定分支合并到当前分支
删除分支 git branch -d <branch-name> 删除已合并的分支
强制删除 git branch -D <branch-name> 删除未合并的分支
查看所有分支 git branch -a 包括本地和远程分支
拉取指定分支 git pull origin <branch> 拉取远程的特定分支并合并
推送本地分支 git push origin <local-branch> 将本地分支推送到远程
删除远程分支 git push origin --delete <branch> 删除远程分支
解决冲突 手动编辑文件，然后 git add + git commit 冲突解决后提交
标签管理 git tag <tag-name>
git push --tags		 创建轻量标签并推送到远程
精选提交 git cherry-pick <commit-hash> 将某次提交应用到当前分支

3.2 关键参数/配置说明

3.2.1 git commit 的关键参数

  • -m "message"：直接提供提交信息。

  • -a：自动将已跟踪文件的修改加入暂存区（但不会包括新增文件）。

  • --amend：修改最近一次提交。如果之前漏了某个文件，可以先 git add，再 git commit --amend，这样就不会产生多余的提交记录。

3.2.2 git push 的关键参数

  • -u（--set-upstream）：将本地分支与远程分支关联，之后可以直接 git push 或 git pull 而无需指定远程和分支名。

  • --force 或 -f：强制推送，会覆盖远程分支历史。极度危险，通常只在紧急修复或重置后使用，且需团队明确沟通。

3.2.3 git reset 的三个模式

  • --soft：仅移动 HEAD 指针，工作区和暂存区不变。适合“撤销提交但保留修改以便重新提交”。

  • --mixed（默认）：移动 HEAD 并重置暂存区，但工作区不变。适合“撤销提交且取消暂存”。

  • --hard：移动 HEAD、重置暂存区和工作区。所有未提交的修改将永久丢失，使用前务必确认。

3.2.4 git merge 的策略

  • --no-ff（no fast-forward）：即使可以快进，也创建一个新的合并提交。这在 Git Flow 中常用于保留功能分支的合并记录。

  • --squash：将目标分支的所有提交压缩成一个新提交，然后合并到当前分支。适合将多个零散提交整理成一个干净的提交。

3.3 常见坑点演示及解决方案

坑点1：git reset --hard 后丢失未提交的修改

场景：你正在开发一个新功能，工作区有很多改动，但还没提交。你执行了 git reset --hard HEAD^，结果所有未提交的修改瞬间消失。

解决方案：

  • 如果已经发生，尝试用 git reflog 找回丢失的提交。git reflog 记录了 HEAD 的每一次移动，找到之前的提交哈希，然后 git reset --hard <hash> 恢复。

  • 最佳实践：养成经常提交的习惯，尤其是重要改动前先 git commit；或者在执行危险操作前先 git stash 暂存工作区。

坑点2：合并冲突后不知所措

场景：git pull 后提示“Automatic merge failed; fix conflicts”，你看到文件里有 <<<<<<<、=======、>>>>>>> 标记，不知道如何处理。

解决方案：

  1. 打开冲突文件，手动选择保留哪部分代码（或者两者结合）。

  2. 删除 Git 添加的标记行。

  3. 保存文件后，执行 git add <file> 标记为已解决。

  4. 最后 git commit 完成合并。

最佳实践：在合并前确保当前分支是最新的（git pull），并且自己的修改已经提交。合并时尽量使用 IDE 提供的冲突解决工具（如 VS Code、IntelliJ IDEA），它们可以可视化对比，极大降低出错概率。

坑点3：git push 被拒绝（non-fast-forward）

场景：你执行 git push，报错“! [rejected] main -> main (non-fast-forward)”，意思是远程分支有比你本地更新的提交。

解决方案：

  • 先 git pull --rebase（或 git pull），将远程更新合并到本地，然后再 git push。

  • 如果是因为你之前做了 git reset 或 git commit --amend 改变了历史，那么你需要 git push --force，但务必先和团队沟通，因为这会覆盖远程历史，影响他人。

坑点4：把密码/密钥文件提交到了仓库

场景：你不小心把 application-secret.yml 提交了，其中包含数据库密码，现在想彻底删除它。

解决方案：

  • 如果刚提交且未推送，可以用 git rm --cached <file> 将其从暂存区移除，然后 git commit --amend。

  • 如果已经推送，需要重写历史：git filter-branch 或使用 BFG Repo-Cleaner 工具，然后强制推送。注意：这会改变所有提交的哈希，团队所有人需要重新克隆仓库。

阶段4：场景融合——团队协作中的 Git 实战

4.1 业务流程串联：一个典型的功能开发流程

假设我们有一个电商后台项目，团队有 3 名开发者：Alice、Bob 和 Charlie。他们采用基于 Git 的协作流程：

1. 产品经理在 Jira 上创建一个“用户积分功能”任务，分配给 Alice。
2. Alice 从最新主分支创建功能分支：git checkout -b feature/user-points
3. Alice 在本地开发，多次提交：git add . && git commit -m "xxx"
4. 开发完成后，Alice 将分支推送到远程：git push -u origin feature/user-points
5. Alice 在 GitHub 上创建一个 Pull Request (PR)，请求将 feature/user-points 合并到 main。
6. Bob 和 Charlie 作为 reviewer 查看代码，提出修改意见。
7. Alice 根据反馈修改代码，再次推送，PR 会自动更新。
8. 审核通过后，由维护者（如技术负责人）点击“Merge”按钮，完成合并。
9. 合并后，触发 CI/CD 自动构建、测试、部署到测试环境。
10. 功能测试通过后，由运维部署到生产环境。

这个流程中，Git 和 GitHub 紧密协作，实现了代码审查、持续集成和团队协作的无缝衔接。

4.2 技术选型对比

Git vs SVN（集中式版本控制）

  • Git 优势：分布式，每个开发者本地都有完整仓库，不依赖网络；分支轻量，合并灵活；速度快。

  • SVN 优势：权限控制细致；学习曲线平缓；对大文件支持较好（但 Git LFS 已弥补）。

  • 选型建议：新项目优先 Git，尤其是开源和互联网团队。传统企业若对权限要求极高且团队习惯 SVN，可继续使用。

GitHub vs GitLab vs Gitee

  • GitHub：全球最大开源社区，生态丰富（Actions、Codespaces、Projects），适合开源项目或国际化团队。

  • GitLab：一体化 DevOps 平台，内置 CI/CD 非常强大，私有化部署成熟，适合企业自建。

  • Gitee：国内访问速度快，符合国内开发者习惯，适合以国内为主的团队。

选型建议：预算充足且需要私有部署选 GitLab；国内团队且希望快速上手选 Gitee；开源项目或已有 GitHub 生态选 GitHub。

阶段5：企业级实战——从规范到落地的完整项目

5.1 实战项目选型：构建一个团队协作的“任务管理”应用

为了完整演示 Git 企业级使用，我们设计一个简单的 任务管理 API，技术栈：Spring Boot + MySQL + MyBatis，部署在云服务器。但本文重点不在代码实现，而在 Git 操作和协作规范。

项目结构（简化）：

task-manager/
├── .gitignore
├── README.md
├── pom.xml
├── src/
│   ├── main/
│   │   ├── java/com/example/taskmanager/
│   │   │   ├── controller/
│   │   │   ├── service/
│   │   │   ├── mapper/
│   │   │   └── model/
│   │   └── resources/
│   │       ├── application.yml
│   │       └── mapper/*.xml
│   └── test/
└── docs/

5.2 企业开发规范落地

5.2.1 分支命名规范

采用 Git Flow 风格的命名：

  • main：生产环境代码，任何时候都是可部署状态。

  • develop：开发主线，集成所有已完成的功能。

  • feature/*：功能分支，如 feature/user-login、feature/task-create。

  • release/*：发布分支，如 release/1.0.0，用于准备发布。

  • hotfix/*：热修复分支，如 hotfix/fix-login-bug。

5.2.2 提交信息规范

参考 Conventional Commits 规范：

<type>(<scope>): <subject>

<body>

<footer>

  • type：feat（新功能）、fix（修复）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（构建/工具）

  • scope：可选，表示影响的模块（如 api、db、config）

  • subject：简短描述，不超过 50 字

  • body：详细说明，说明“为什么改”和“怎么改”

  • footer：关闭的 Issue 号等

示例：

feat(task): 添加任务创建接口

实现了 POST /api/tasks 接口，接收任务标题和描述，返回创建后的任务对象。

Closes #12

团队可以使用 commitlint 等工具强制校验提交信息格式。

5.2.3 代码分层与目录结构

  • Controller：接收请求，参数校验，调用 Service。

  • Service：业务逻辑，事务管理。

  • Mapper/DAO：数据库访问。

  • Model：实体类、DTO、VO。

在 Git 层面，每次提交应保持“逻辑原子性”，即一个提交只做一件事，比如“添加用户注册接口”不应该同时包含“修复登录 bug”。

5.2.4 Pull Request 流程规范

  1. 开发者从 develop 分支创建 feature/xxx。

  2. 开发完成后，推送分支，在 GitHub/GitLab 上创建 PR，目标分支为 develop。

  3. PR 模板包含：

    • 简述功能

    • 关联的 Issue

    • 测试情况

    • 截图（如果有 UI）

  4. 至少一位 reviewer 批准后，由代码负责人合并。

  5. 合并方式：通常选择 Squash and merge（将整个分支的提交压缩成一个）或 Merge commit（保留完整历史），根据团队习惯选择。

  6. 合并后删除远程分支。

5.2.5 异常处理与日志规范

在代码中合理使用日志，同时在 Git 提交中不应包含调试用的 System.out.println 或注释掉的代码。可以在 .gitignore 中忽略 IDE 配置文件、编译输出等。

5.3 测试&部署与 Git 集成

5.3.1 单元测试

在提交前，开发者应运行本地单元测试（如 mvn test）。可以在 Git 的 pre-commit 钩子中自动运行测试，防止破坏代码的提交进入仓库。

5.3.2 持续集成（CI）

使用 GitHub Actions 或 GitLab CI，当推送代码到远程时自动触发：

  • 拉取最新代码

  • 编译构建

  • 运行测试

  • 静态代码分析（如 SonarQube）

  • 构建 Docker 镜像

  • 部署到测试环境

配置文件示例（.github/workflows/ci.yml）：

name: CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
    - name: Build with Maven
      run: mvn clean install
    - name: Run tests
      run: mvn test
5.3.3 持续部署（CD）

当 main 分支接收到合并时，自动构建并部署到生产环境。可以通过 Git 标签触发：如 git tag v1.0.0 后推送标签，触发生产部署。

阶段6：复盘升华——从会用走向用好

6.1 最佳实践总结

6.1.1 提交规范

  • 小步提交：每次提交只包含一个逻辑单元，方便回退和审查。

  • 提交前测试：确保当前版本至少能编译通过。

  • 不要提交无意义的文件：通过 .gitignore 忽略编译产物、日志、本地配置等。

6.1.2 分支策略

  • 保持主分支干净：main 分支只能通过 PR 合并，且必须经过测试和审查。

  • 定期同步 develop：功能分支应经常从 develop 拉取最新代码，避免最后合并时出现大量冲突。

  • 及时删除合并后的分支：避免分支数量膨胀。

6.1.3 冲突解决

  • 在合并前先 git fetch 和 git diff 查看差异。

  • 冲突发生后，不要慌张，使用专业工具（如 VS Code 的 3-way merge）。

  • 解决冲突后，再次测试确保功能正常。

6.1.4 备份与恢复

  • 定期推送远程，本地仓库不是唯一的。

  • 使用 git reflog 作为最后的救命稻草。

6.2 技术演进讲解

6.2.1 Git 的诞生

2005 年，Linux 内核开发社区与 BitKeeper（当时使用的版本控制工具）关系破裂，Linus Torvalds 用两周时间编写了 Git。它的设计目标：

  • 分布式

  • 高性能

  • 数据完整性（SHA-1 校验）

  • 支持非线性开发（分支）

6.2.2 Git Flow 与 GitHub Flow

  • Git Flow：由 Vincent Driessen 提出，定义了严格的分支模型（master、develop、feature、release、hotfix）。适合有明确发布周期的项目。

  • GitHub Flow：更简化，只有一个长期分支 main，所有改动都通过 PR 合并。适合持续部署的 Web 项目。

  • 演进趋势：随着 CI/CD 普及，很多团队转向 GitHub Flow 或 GitLab Flow，减少分支复杂度，加快迭代速度。

6.2.3 Git 的未来

  • Git 2.x 不断优化性能，引入 git switch、git restore 等更直观的命令。

  • Git LFS 解决了大文件存储问题。

  • Git 与 DevOps 深度融合，成为现代软件开发的核心基础设施。

6.3 面试/工作高频问题及解答

Q1：Git 和 SVN 的主要区别是什么？

  • 分布式 vs 集中式：Git 每个开发者都有完整仓库，SVN 只有中央仓库。

  • 分支模型：Git 分支轻量，创建合并成本极低；SVN 分支是目录拷贝，成本高。

  • 速度：Git 本地操作速度快，SVN 多数操作需要网络。

  • 存储方式：Git 基于内容哈希存储，SVN 基于文件差异。

Q2：git reset、git revert、git checkout 的区别？

  • git reset：移动 HEAD 和分支指针，可改变历史（危险）。

  • git revert：创建一个新的提交来撤销之前的提交，不改变历史，安全。

  • git checkout：用于切换分支或恢复工作区文件。git restore 是它的替代命令。

Q3：如何解决合并冲突？

  • 先用 git status 查看冲突文件。

  • 手动编辑文件，保留需要的代码，删除冲突标记。

  • 执行 git add 标记为已解决。

  • 执行 git commit 完成合并。

Q4：什么是 git rebase？和 git merge 有什么区别？

  • git merge：将两个分支的历史合并，产生一个合并提交，历史真实反映分支结构。

  • git rebase：将当前分支的提交“变基”到目标分支上，形成线性历史，使提交记录更整洁。但注意不要在公共分支上使用 rebase，否则会导致其他人历史冲突。

Q5：git pull 和 git fetch 的区别？

  • git fetch：只下载远程更新，但不合并到当前分支。

  • git pull = git fetch + git merge（或 git fetch + git rebase 如果配置了 --rebase）。

Q6：如何删除一个远程分支？

bash

git push origin --delete <branch-name>

或者在 GitHub 上直接删除。

Q7：如何撤销已经推送的提交？

如果只是提交信息错了，可以用 git commit --amend 修改后强制推送（git push --force），但必须确保没有其他人基于该提交工作。更安全的方式是用 git revert 创建一个反提交。

Q8：如何找回被删除的分支或提交？

使用 git reflog 找到对应的哈希，然后 git checkout -b <new-branch> <hash> 恢复。

写在最后

Git 和 GitHub 是每个开发者必备的技能，但真正掌握它们需要理解背后的思想，而不仅仅是记忆命令。通过本文的六个阶段，我们从“为什么要用”开始，到“怎么用”，再到“企业里怎么规范用”，一步步构建了完整的知识体系。

希望你在今后的开发中，能够：

  • 像用记事本一样自然使用 Git

  • 在团队协作中成为版本控制的专家

  • 避免因版本混乱导致的线上事故

如果你觉得本文对你有帮助，欢迎分享给更多朋友。如果你有任何疑问或想深入了解某个知识点，请在评论区留言，我会持续更新。

附录：常用命令速查表

命令 说明
git init 初始化本地仓库
git clone <url> 克隆远程仓库
git status 查看状态
git add <file> 将文件加入暂存区
git commit -m "msg" 提交
git push 推送
git pull 拉取并合并
git fetch 只拉取不合并
git branch 列出分支
git checkout -b <branch> 创建并切换分支
git merge <branch> 合并分支
git rebase <branch> 变基
git reset --hard HEAD^ 回退到上一个版本
git revert <commit> 撤销某次提交
git cherry-pick <commit> 应用某个提交到当前分支
git tag <name> 创建标签
git log --oneline --graph 图形化查看历史
git reflog 查看所有 HEAD 变动
git stash 暂存当前工作区

本文参考了 Pro Git 书籍、Git 官方文档以及众多社区实践。文中案例代码可在 [GitHub 仓库] 获取。

# github # git
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

一个 API 入口调用多个大模型：AiiOnly客户端 + CC Switch 打通 Codex AI编程流程

avatar AI编程社区
cover

VSCode Claude Code + MiMo 中转免登录完整配置教程（解决原生登录弹窗 + 模型报错）

avatar AI编程社区
cover

从零开始做一个属于自己的 Skill（保姆级教程）

avatar AI编程社区