Git 版本控制实战：从 add/commit 到分支与变基

一、为什么离不开 Git

不用 Git 的项目，基本靠"最终版""最终版2""真最终版"这种文件夹续命，出错了无从回溯，协作更是灾难。Git 解决两件事：

• 版本回溯：每一次提交都是快照，出事能回到任意历史点。
• 并行协作：每个人开分支开发，互不影响，最后再合并。

二、最常用的工作流

日常 80% 的操作就这几个：

git init                      # 初始化仓库（新项目）
git clone <仓库地址>          # 拉取已有仓库

git status                    # 看当前改动状态
git add .                     # 把改动加入暂存区
git commit -m "feat: 新增登录接口"   # 提交，写清楚这次干了啥
git pull                      # 拉取远端最新（推之前先拉）
git push                      # 推到远端

git log --oneline             # 看提交历史（一行一条）
git diff                      # 看具体改了哪些内容

习惯：commit -m 的信息别写"改了点东西"这种废话。好的提交信息一看就知道这次变更目的，回退时救命。

三、分支：协作的核心

永远别在 main/master 上直接开发。开一个功能分支：

git branch feature/login          # 新建分支
git switch feature/login          # 切过去（老写法 git checkout feature/login）
# 或者一步到位：
git switch -c feature/login       # 新建并切换

git merge feature/login           # 回到 main 后合并功能分支
git branch -d feature/login       # 合并完删掉本地分支

典型节奏：从 main 切 feature/xxx 开发 → 测完 → 回 main 合并 → 删分支。干净、可追溯。

四、merge 还是 rebase

这是新手最容易懵的一对：

我的用法：功能分支合回 main 用 merge；自己在 feature 分支上想跟上 main 最新，用 git pull --rebase。简单记：rebase 用于"还没给别人看"的提交。

五、高频踩坑

• push 前不 pull：直接 push 被拒，因为远端有别人新提交。先 pull（或 pull --rebase）再 push。
• rebase 出冲突就慌：rebase 中途冲突很正常，解决后 git add + git rebase --continue 即可，别乱 abort。
• 大文件误提交：几百 MB 的视频/包提交进去，仓库就肿了。提前写好 .gitignore，把 node_modules/、构建产物、密钥文件都忽略掉。
• 把密钥提交了：.env、密钥千万别进仓库。一旦提交，光删文件不够，历史里还在，得用 git filter-repo 清理。
• git reset --hard 乱用：它会丢弃工作区改动，不确定前先 git stash 暂存，别硬重置。

六、小结

Git 用熟的关键就三句话：日常三板斧（add/commit/push）打底；功能分支隔离开发；merge 合主干、rebase 跟最新。剩下的就是多在真实项目里踩几次——冲突解决过一两次，Git 就算真正入门了。