1. 为什么在动手写代码前，必须搞定 Git 基础

如果你刚开始学编程，或者准备加入一个团队项目，我建议你先别急着写第一行代码。最应该花一两个小时搞定的，是 Git 的基础操作。这不是为了应付面试，而是为了让你在真正开始“Vibe Coding”（沉浸式编码）时，不被版本管理、代码丢失、协作冲突这些琐事打断思路。

很多人把 Git 想得太复杂，看了很多命令却不敢用。其实，你不需要背下所有指令。真正影响你编码体验的，是几个最核心的场景：如何安全地保存你的工作进度、如何与别人的代码合并、以及如何回溯到任何一个历史版本。如果这些基础操作不熟，你可能会遇到“代码写了一半不知道怎么办”、“不小心覆盖了文件”或者“无法和别人同步”的尴尬局面，这才是打断你“Vibe”的元凶。

这篇文章不会罗列所有 Git 命令，而是围绕一个新手开发者从零开始到能顺畅进行个人或简单协作开发的核心路径，把必要的 Git 知识串起来。目标是：让你在遇到上述场景时，能立刻知道用什么命令、按什么顺序操作，并且理解每一步在做什么，而不是机械地复制粘贴。

2. 环境准备：安装与首次配置

在接触任何命令之前，先把 Git 装好并完成身份标识。这是所有操作的基石。

2.1 选择与安装 Git

对于 Windows 用户，最直接的方式是访问 Git 官网下载安装程序。安装过程中，有几个选项需要注意：

• 选择默认编辑器：如果你习惯用 VSCode，就选择它，这样后续一些操作会自动在 VSCode 中打开文件。
• 调整 PATH 环境：建议选择“Git from the command line and also from 3rd-party software”，这会把 Git 添加到系统 PATH，让你能在终端（如 CMD、PowerShell）和 VSCode 终端里直接使用git命令。
• 配置行尾转换：选择“Checkout Windows-style, commit Unix-style line endings”。这个设置能更好地处理 Windows 和 Linux/macOS 系统之间的文本文件换行符差异，避免协作时出现大量无意义的修改行。

安装完成后，在任意地方打开终端（CMD、PowerShell 或 Git Bash），输入git --version，如果能看到版本号，说明安装成功。

2.2 完成必要的全局配置

安装后第一件事是设置你的用户名和邮箱。这个信息会记录在你每一次的提交历史中，是身份的标识。

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这里的“全局”意味着对这台电脑上你所有的 Git 仓库生效。你可以通过git config --global --list查看已配置的项。

为什么必须配置这个？因为 Git 是分布式版本控制系统，每一次代码提交（Commit）都需要一个作者。如果没有配置，在你第一次提交时，Git 会报错并提示你进行配置，这会打断你的工作流。提前配好，一劳永逸。

3. 核心工作流：从本地仓库到代码提交

理解了 Git 的基本概念后，我们进入最常用的日常操作流程。你可以把这个流程看作一个循环：修改代码 -> 暂存改动 -> 提交记录。

3.1 初始化仓库与文件状态

一切从创建一个本地仓库开始。进入你的项目文件夹，执行：

git init

这个命令会创建一个隐藏的.git目录，里面包含了 Git 管理这个项目所需的所有元数据。此时，你的项目文件夹就变成了一个 Git 仓库。

接下来，理解文件的状态至关重要。Git 将文件分为几种状态：

• 未跟踪（Untracked）：新创建的文件，Git 之前没见过。
• 已修改（Modified）：已跟踪的文件被修改了，但还没放入暂存区。
• 已暂存（Staged）：已修改的文件被标记，准备纳入下一次提交。
• 未修改（Unchanged/Committed）：文件已提交，自上次提交后无改动。

使用git status命令可以清晰地看到当前仓库中所有文件的状态，这是你最应该频繁使用的命令之一，它能让你时刻掌握工作目录的情况。

3.2 暂存与提交：保存你的工作快照

直接修改文件后，它们处于“已修改”状态。你需要通过git add命令将它们添加到“暂存区”（Staging Area）。

# 添加单个文件 git add filename.txt # 添加当前目录下所有改动和新文件 git add . # 添加所有已跟踪文件的改动（不包含新文件） git add -u

暂存区是什么？你可以把它想象成购物车。git add就是把商品（文件改动）放进购物车，而git commit才是最终结账。这个设计让你可以精心组织一次提交包含哪些改动，而不是一次性提交所有乱七八糟的修改。

提交改动，生成一个历史记录点：

git commit -m “这里写清楚本次提交做了什么改动”

-m后面跟的是提交信息。务必认真写提交信息！好的提交信息像代码注释，能让未来的你或你的队友一眼看懂这次改动的目的。模糊的信息如“更新”或“修复bug”毫无价值。

3.3 查看历史与版本穿梭

提交之后，如何查看历史记录？使用git log。它会按时间倒序列出所有提交，包括提交哈希值（唯一ID）、作者、日期和提交信息。你可以用git log --oneline查看简略信息，用git log --graph查看分支合并图。

如果你发现刚刚的提交有错误（比如漏了文件，或者提交信息写错了），并且还没有推送到远程仓库，可以进行修正：

• 补充漏掉的文件：先git add漏掉的文件，然后执行git commit --amend。这不会产生一个新的提交，而是将这次改动合并到上一次提交中。
• 修改上次的提交信息：直接执行git commit --amend，然后修改弹出的信息即可。

注意：--amend操作会改变提交的哈希值，只适用于尚未与他人共享的本地提交。如果已经推送（git push）了，再修改本地历史并强制推送会造成协作混乱，需谨慎。

4. 分支管理：实现功能并行与代码隔离

分支是 Git 的“杀手级”功能，它让你能在一条独立的时间线上开发新功能、修复 Bug，而不会影响主线（通常是main或master分支）。

4.1 分支的创建与切换

默认情况下，你工作在main分支上。创建一个新分支来开发功能：

# 创建并切换到新分支 feature-xxx git checkout -b feature-xxx # 或者使用更语义化的命令 git switch -c feature-xxx

现在，你在feature-xxx分支上的所有提交都不会影响到main分支。你可以自由地编码、测试。

4.2 合并与解决冲突

当功能开发完成并测试通过后，你需要将它合并回主分支。首先，切换回main分支并获取最新代码：

git switch main git pull origin main # 假设远程仓库叫 origin

然后合并你的功能分支：

git merge feature-xxx

如果幸运的话，合并会自动完成。但如果有冲突（Git 无法自动合并的修改），它会提示你。冲突文件里会有类似这样的标记：

<<<<<<< HEAD 主分支上的代码 ======= 你分支上的代码 >>>>>>> feature-xxx

你需要手动编辑这个文件，保留你想要的内容，删除<<<<<<<，=======，>>>>>>>这些标记，然后执行git add标记冲突已解决，最后git commit完成合并提交。

4.3 临时保存现场：git stash

这是另一个提升“Vibe”的神器。假设你正在feature-A分支上写代码，突然需要切到main分支去修复一个紧急 Bug。但你现在的工作还没完成，不想提交。这时可以用：

git stash

这个命令会将你当前未提交的改动（包括暂存区和工作区）保存到一个栈里，让你的工作目录恢复干净，然后你就可以安心地切换分支去处理别的事情了。

处理完紧急任务后，回到原来的分支，恢复现场：

git stash pop

pop会恢复最近一次保存的改动并将其从栈中删除。你也可以用git stash list查看所有保存的记录，用git stash apply stash@{n}恢复指定的记录。

5. 远程协作：连接 GitHub/Gitee 等平台

本地玩得再熟，最终还是要和团队或备份同步。这就需要远程仓库。

5.1 关联与同步远程仓库

通常，你会在 GitHub、Gitee 或公司内建的 GitLab 上创建一个远程仓库。有两种常见情况：

1. 从零开始：本地已有项目，想推到新的空远程仓库。

   # 在远程平台创建空仓库，获得仓库地址（如 https://github.com/username/repo.git） git remote add origin https://github.com/username/repo.git git branch -M main # 确保本地主分支叫 main git push -u origin main # 首次推送，并建立追踪关系

2. 参与已有项目：克隆（Clone）现有的远程仓库。

   git clone https://github.com/username/repo.git

   这条命令会做三件事：下载整个项目历史、自动创建origin远程连接、并检出默认分支（通常是main）。

5.2 推送与拉取

建立连接后，日常同步就靠push和pull。

• git push origin branch-name：将你本地某个分支的提交推送到远程仓库的同名分支。加了-u参数后，后续可以直接用git push。
• git pull origin branch-name：从远程仓库拉取指定分支的最新提交，并合并到当前本地分支。它相当于git fetch（获取远程更新） +git merge（合并到本地）。

一个关键建议：在push之前，先pull一下远程的最新代码，确保本地是基于最新版本进行修改，这样可以减少冲突的概率。养成pull -> 处理冲突（如果有）-> commit -> push的习惯。

6. 避坑指南与高效习惯

最后，分享几个能让你远离麻烦、提升效率的具体习惯。

6.1 提交信息的规范写法

糟糕的提交信息是项目的“债务”。采用类似“约定式提交”的简单规范很有用：

• feat:：新功能
• fix:：修复 Bug
• docs:：文档更新
• style:或refactor:：代码格式/样式调整或重构（不改变功能）
• test:：增加或修改测试
• chore:：构建过程或辅助工具的变动

例如：git commit -m “feat: 添加用户登录接口”或git commit -m “fix: 修复首页图片无法加载的问题”。这样一看历史记录就非常清晰。

6.2 勤用git status和git diff

不要盲目执行命令。在执行add,commit,push前，先用git status确认一下有哪些文件处于什么状态。在commit前，用git diff --staged查看暂存区里的具体改动内容，确认是不是你想要的。这个习惯能避免很多“手滑”操作。

6.3 理解.gitignore文件

项目根目录下的.gitignore文件用于告诉 Git 哪些文件或目录不需要纳入版本管理，比如编译产物（node_modules/,dist/）、本地配置文件、IDE 配置文件（.vscode/）、系统文件（.DS_Store）等。在项目一开始就配置好它，可以保持仓库的整洁，避免误提交敏感或无用文件。

6.4 遇到错误的排查顺序

当你执行 Git 命令报错时（比如常见的fatal: not a git repository），别慌，按这个顺序检查：

1. 检查当前目录：用pwd（Linux/macOS）或cd（Windows）确认你确实在一个 Git 仓库目录里。not a git repository错误就是因为你在一个未被git init或git clone的目录里执行了 Git 命令。
2. 仔细阅读错误信息：Git 的错误提示通常很直接，会告诉你哪里出了问题，比如文件冲突、权限不足、远程连接失败等。
3. 检查网络与远程地址：如果是push/pull失败，检查网络是否通畅，远程仓库地址是否正确（git remote -v）。
4. 善用--help：对任何命令有疑问，比如git merge --help，会打开详细的官方文档。

掌握这些基础，你就能在代码世界里安心地“Vibe Coding”了。真正的熟练不是背命令，而是在需要保存进度、合并代码、回溯历史时，能条件反射般地使用正确的工具，而不会因此中断你的创造流。