理解 Git: 终极指南

Mon, 10 Mar 2025 00:00:00 GMT

思维模型: 理解 Git 的核心概念

有没有觉得看 Git 文档像是在读象形文字?我也有过这种感受。让我们用更通俗的方式来拆解 Git。

Git 的大图景: 一切都是副本

归根结底, Git 就是一个用来管理你代码不同副本的高级系统:

远程副本: 存放在服务器上 (比如 GitHub, GitLab 或你们公司的服务器)
本地副本: 你电脑上的那份, 你实际操作的代码

有趣的是:

虽然远程可以有很多不同的副本 (分支), 但你本地一次只会操作一个活跃的版本。

可以这样想: 就像大学里小组写论文, “官方”版本存在共享的 Google Drive (远程), 但每个人都有自己的本地副本在修改。Git 帮你管理这些版本如何同步。

仓库: 你项目的家

仓库 (Repository, 简称 “repo”) 就是所有这些副本及其历史的集合。每个仓库都有唯一的 URL (即 repo_url) 。

比如 React 的仓库地址是 https://github.com/facebook/react.git —— 这就是它的 repo_url。

用实际例子解释 Git 概念

什么是 “提交” (Commit) ?

提交就像是在某个时间点给你的代码拍了一张快照。

可以把提交想象成电子游戏里的存档点。你取得了进展, 想确保如果后面出问题, 随时能回到这个状态。

示例场景:

# 你修改了代码
git add index.html styles.css
git commit -m "添加响应式头部并修复导航样式"

此时, 你已经在本地保存了这个存档点, 但远程仓库还不知道。所以我们需要推送 (push) 提交。

什么是 “Origin”?

因为每次输入完整的仓库 URL 太麻烦, Git 用像 “origin” 这样的别名来指代远程仓库。

“origin” 只是 Git 默认给你克隆仓库来源起的昵称。

实际例子:

# 当你克隆一个仓库
git clone https://github.com/your-username/cool-project.git

# Git 会自动把 "origin" 指向这个 URL
# 之后你只需要这样写:
git push origin main

# 而不用每次都输入长长的地址:
git push https://github.com/your-username/cool-project.git main

你还可以添加其他远程仓库, 这在参与开源项目时很有用:

# 添加另一个远程仓库
git remote add upstream https://github.com/original-creator/cool-project.git

# 现在你可以从原始仓库获取更新
git fetch upstream

什么是 “分支” (Branch) ?

很多 Git 教程在这里让人迷惑。我们来理清楚:

分支其实并不是真正意义上的树枝——更像是一个指针或标签, 标记着某条开发时间线。

如果用树来比喻, branch (分支) 其实更像叶子 (时间才是树枝)

更清晰的理解方式:

想象你的项目时间线是一条铁轨。main 分支就是主轨道。当你创建新分支时, 其实是在某个点插了个旗子, 表示”我要从这里开始修一条新轨道”。

实际操作例子:

# 从 main 分支开始新功能分支
git checkout main
git checkout -b feature/user-authentication

# 现在你可以在不影响 main 的情况下修改代码
# 每次提交都会让 feature/user-authentication 指针向前移动

你在功能分支上的所有提交会形成一条独立的开发时间线, 之后可以合并回主时间线。

什么是 “Fetch”?

git fetch 命令就像是去信箱查收新邮件, 但还没拆开看。

fetch 时, Git 会下载远程仓库的最新信息, 但不会把这些更改应用到你的工作区。

示例:

# 检查远程仓库是否有更新
git fetch origin

# 现在 Git 已经知道远程的变化, 但还没应用
# 你可以用下面命令查看所有分支:
git branch -a

fetch 之后, 你可以决定是否以及如何把这些更改合并到本地。

什么是 “Pull”?

git pull 是 fetch 和 merge 的组合:

git pull origin main = git fetch origin + git merge origin/main

就像你查收信箱并把信件带回家一起读。

常见场景:

# 开始一天工作, 先拉取最新更改
git pull origin main

# 这会把队友们在你离开时推送的更改同步到你的本地 main 分支

但有时你可能想用 git pull --rebase, 这就引出了下一个话题……

大战: “合并” (Merge) vs “变基” (Rebase)

这里是 Git 哲学之争, 也是开发者争论最多的地方。让我用实际场景解释:

场景: 你在功能分支上开发了几天, 这期间 main 分支被其他人推进了。

方案一: 合并 (Merge)

git checkout feature-branch
git merge main

合并会生成一个”合并提交”, 把两个分支连在一起。历史记录会显示分支分开又合并的过程。

方案二: 变基 (Rebase)

git checkout feature-branch
git rebase main

变基会把你的更改”重放”到最新的 main 分支上。就像说: “假装我从现在的 main 开始做的这些更改。”

关键区别:

合并: 完整保留历史 (分开又合并)
变基: 让历史更干净, 线性 (好像从没分过支)

什么时候用哪种:

合并: 适合公开/多人协作的分支
变基: 适合你自己的功能分支, 在合并到 main 前使用

专业建议: 在合并功能分支前, 先变基到 main, 这样历史最干净, 也能减少合并冲突。

什么是 “暂存” (Stash) ?

有没有遇到正在开发一半, 突然要切去处理紧急任务, 但又不想提交半成品?

这就是 git stash 的用武之地——就像把你的更改临时塞进抽屉, 等会儿再处理。

实际场景:

# 正在开发新功能, 突然有紧急 bug 要修
# 先把当前更改暂存起来
git stash save "用户资料页半成品"

# 切换去修 bug
git checkout main
git checkout -b hotfix/critical-login-bug

# 修好 bug, 提交并合并

# 回到你的功能分支
git checkout feature/user-profile
git stash list  # 查看所有暂存的更改
git stash apply stash@{0}  # 应用最新的暂存

# 用完某个 stash 后可以删除
git stash drop stash@{0}

可以把 stash 理解为可以贴到不同代码版本上的便签。

常见 Git 工作流

现在你已经了解了各个部分, 让我们把它们串成一个典型的工作流:

功能分支工作流

保持最新:
```
git checkout main
git pull origin main
```

创建功能分支:

git checkout -b feature/awesome-new-thing

小步提交:

# 做一些更改
git add -A
git commit -m "实现 awesome 功能的第一部分"

# 更多更改
git add -A
git commit -m "完成 awesome 功能"

与 main 保持同步:
```
git fetch origin
git rebase origin/main
```

推送你的分支:

git push origin feature/awesome-new-thing

创建 Pull Request (在 GitHub/GitLab 等平台)
审核通过后, 合并或变基并合并

总结

刚接触 Git 时可能觉得复杂, 但理解了它的思维模型后, 一切都豁然开朗。记住:

分支只是指向特定提交的指针
提交是你代码在某一时刻的快照
远程仓库存储着共享的历史
本地仓库是你的个人工作区

最重要的是, 和团队一起制定一套适合自己的工作流, 并坚持执行。

还有哪些 Git 概念让你困惑?欢迎在评论区留言!

版本控制 on 张欣耕的个人博客