企业官网建设流程全解析

做开发这几年，我见过太多新人在项目做到一半才被版本管理这件事打得措手不及。项目文件越积越多，每个人都维护着带日期后缀的"最终版"，同事和你同时改了一个文件却互相不知情，线上出了问题想回到昨天还能用的状态，翻遍文件夹也找不到那份"昨天还能用"的代码。这种手忙脚乱的经历，几乎每个开发者都逃不掉。而Git就是解决这一切的主流工具——当前几乎所有公司的代码协作都在依赖它。这篇攻略专门写给零基础的小白，从Windows、macOS、Linux三个平台的安装开始，一路讲到本地提交、分支、远程协作、冲突处理和日常高频报错，全程给出可直接照抄的命令，照着敲完，你就能在一台机器上把Git跑通，并且理解它每一步在做什么。

1. 先搞明白Git到底解决了什么问题，再决定要不要学它

1.1 没有版本控制时，项目里到底发生了什么

想象一个大四毕业生和三个同学组队做课设。一开始大家约定"谁改完就把文件发到群文件夹"，结果一周后群文件夹里出现了二十几个名为"报告_最终版.doc""报告_最终版2.doc""报告_真真最终版.doc"的文件。更麻烦的是，班长想合并前三章的修改，打开文件发现小王改过的段落已经被另一个人的版本覆盖了，连谁的修改是对的都分不清。

这不是段子，是所有没有版本管理驱动的团队真实经历过的混乱。就算在个人项目里，没有版本管理也意味着：改到一半发现思路错了想回到昨天的状态，只能靠Ctrl+Z碰运气，或者靠为数不多的编辑器历史快照。而这个历史快照往往只存在单个文件层面，一旦项目有几十个文件，根本没法拼回一个可运行的版本。

Git解决的就是三个核心痛点：记录每一次变更、支持任意时间点回退、让多人并行修改同一份代码而不互相覆盖。这三个能力合在一起，就是"版本控制"这个词的全部含义。

1.2 Git的核心设计：快照、本地仓库、分布式

和很多人想象的不同，Git记录历史的方式非常"笨"但也非常可靠：每一次提交（commit），它都像拍照片一样，把当前所有文件的状态完整保存下来，形成一个新的快照。这个快照不是复制所有文件内容的高消耗方案——Git内部会做压缩和去重，本质上是一个物理存储层面的优化，但你在使用时的感受就是：每次提交都是一个完整的存档点。

这套设计和常见的"差异备份"思路有本质区别。SVN这类传统集中式版本控制系统，记住的是"某一行发生过什么变化"，而Git记住的是"这个时刻整个项目长什么样"。所以Git做版本回退的速度非常快，因为它只需要切到对应快照，不需要逐条反推差异。

Git另一个关键特性是完全分布式。这意味着每台电脑上的仓库都包含完整的历史记录，本地提交、本地查看日志、本地切换分支，全都不需要联网。远程仓库（GitHub、GitLab这类平台）的真正作用是充当团队之间的"同步中转站"，而不是唯一的存储中心。哪怕远程服务器今天彻底宕机了，你本地的历史也一份不会少。

1.3 Git的生态位：托管平台、图形客户端、编辑器集成

把Git学了之后，你会发现它无处不在。代码托管平台方面，GitHub是全世界最大的开源社区，GitLab通常被公司内部用来做私有代码托管，Gitee（码云）在国内访问体验比较好。这些平台本身不是Git，但全部建立在Git协议之上，相当于给Git加了一层Web界面和协作工具（Issue、Pull Request、代码评审）。

图形客户端方面，Windows上老牌工具TortoiseGit（俗称"小乌龟"）在资源管理器右键就能操作，很多不习惯命令行的开发者都在用它；JetBrains系列IDE和VS Code都内置了Git面板，可以直接可视化提交和切换分支。但这篇攻略依然推荐你从命令行学起，因为图形界面只是把命令封装成了按钮，所有报错信息、底层逻辑最终都要回到命令行才能看得明白。

2. 三个平台安装Git的完整过程与安装选项怎么选

2.1 Windows安装：下载、安装选项、Git Bash

Windows安装Git最简单的方式是去官网git-scm.com下载安装包，选择对应系统架构的64位版本。下载完成之后双击安装，大部分人会被一堆英文安装选项劝退，其实大部分保持默认就行，真正需要留意的就三处。

第一处是"Select Components"，建议把"Git Bash Here"和"Git GUI Here"这两个选项勾上，这样之后在任何文件夹里右键鼠标就能直接打开Git Bash，非常方便。第二处是"Choosing the default editor used by Git"，默认是Vim，这个编辑器对新手极其不友好，如果你电脑上装了VS Code，直接在下拉框里选"Use Visual Studio Code as Git's default editor"。第三处是"Adjusting your PATH environment"，建议选择中间那项"Git from the command line and also from 3rd-party software"，这样Git不仅能从Git Bash使用，也可以在CMD、PowerShell以及VSCode终端里直接使用。

安装完成后，按Win键输入Git Bash回车，或者在桌面任意位置右键选择"Git Bash Here"，在弹出来的黑色终端里输入：

git --version

如果能回显类似git version 2.45.0这样的信息，说明安装成功。Git Bash是Windows下一套模拟Linux命令行的环境，里面的命令语法和macOS/Linux保持一致，本教程所有命令都可以直接在Git Bash里运行。

2.2 macOS安装：Homebrew或官方安装包

macOS下最推荐用Homebrew安装，你也可以直接去官网下载macOS的dmg安装包双击安装。如果走Homebrew路线，终端执行：

brew install git

顺便说一句，macOS系统自带的"git"命令其实来自Apple Command Line Tools，版本可能比较老。所以装完Homebrew版之后，建议执行which git确认一下路径，如果显示/usr/local/bin/git或/opt/homebrew/bin/git，说明用的是新版本。第一次运行git命令时，macOS可能会弹窗提示安装开发工具，让它装着就行，这是正常的系统行为。

2.3 Linux安装：包管理器一行搞定

Debian/Ubuntu系：

sudo apt update sudo apt install git -y

CentOS/RHEL系：

sudo yum install git -y

Fedora等现代版本也有dnf install git。装完同样用git --version验证。

2.4 安装后第一件事：验证Git版本和环境变量

装完之后别急着往下走，先确认一件事：确保Git已经进入系统的PATH环境变量。这是个极其常见的坑。

在Windows上，如果安装时选的PATH选项不对，或者安装完成后直接在老的终端窗口里敲git，经常会出现下面这条报错：

git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。

遇到这个先别慌，大概率不是装坏了，而是终端没刷新环境变量。解决办法：把终端窗口全部关掉重新打开，或者注销重新登录。如果重开还不行，手动把C:\Program Files\Git\bin和C:\Program Files\Git\cmd两个路径加到系统环境变量里，加完之后再重开终端。macOS和Linux一般不存在这个问题，因为包管理器安装时已经自动把可执行文件放进了标准路径。

3. 第一次提交前的必做功课：身份配置与SSH免密

3.1 用户名和邮箱：Git提交记录里的"作者签名"

Git每次提交都会在历史里记录一个作者身份，这个身份就是你的用户名和邮箱。它跟你在GitHub注册的账号没有强制绑定关系，但建议保持一致，否则你的提交在平台上显示不出头像和名字。

配置命令：

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

这里有个细节很多人不理解——为什么必须配置，不配行不行？不配置会怎样？答案是会报警告Please tell me who you are，提交被直接拒绝。这就像写合同必须签名一样，Git需要知道你这次变更是谁做的。

查看当前配置：

git config --global --list

3.2 global、local、system三种配置的作用范围

配置系统里有三个层级：--system（系统级，很少动）、--global（全局），以及--local（当前仓库）。如果同一个配置项在多个层级里都出现了，--local的值优先级最高。

这个设计很实用。比如你平时在公司项目里用一个工作邮箱，自己的开源项目想用另一个个人邮箱，那就可以在公司项目的根目录执行不带--global的配置，让当前仓库覆盖全局配置。思路是：

git config user.name "工作花名" git config user.email "工作邮箱"

3.3 SSH密钥配置：原理、生成步骤、托管平台添加

用HTTPS地址clone仓库的时候，每次push都被要求输入账号密码，虽然现在很多平台改成了Personal Access Token（个人访问令牌），但本质上还是麻烦。SSH密钥是解决问题的通用方案：配置一次之后，后续所有Git操作全部自动免密。

SSH密钥的原理用生活类比解释：先生成一对钥匙，一把公钥（锁）放到GitHub/GitLab服务器上，一把私钥（钥匙）留在本地电脑上。你发起操作时，Git用本地私钥"开锁"，服务器用之前存放的公钥"验锁"，验证通过就不再询问密码。公钥可以随便给别人看，私钥永远不能泄露。

生成密钥的方法，在Git Bash（或macOS/Linux终端）里执行：

ssh-keygen -t ed25519 -C "你的邮箱"

一路回车就行，中途会问是否给私钥设置密码短语（passphrase）。这里给了个选择：空密码最方便但安全性略低；设了密码每次操作会多一道验证。我的建议是个人电脑上直接留空，因为你已经通过电脑登录和系统权限保护了环境，不值得为每次push都多输一次密码。生成结束后会有两行提示，默认情况下私钥位置是~/.ssh/id_ed25519，公钥位置是~/.ssh/id_ed25519.pub。

查看公钥内容：

cat ~/.ssh/id_ed25519.pub

把输出的一长串ssh-ed25519 AAAA...完整复制，然后登录GitHub的Settings -> SSH and GPG keys -> New SSH key，粘贴保存。GitLab的话在Preferences -> SSH Keys里操作。然后测试连通性：

ssh -T git@github.com

第一次连接会问Are you sure you want to continue connecting (yes/no)?，输入yes回车。如果看到Hi 你的用户名! You've successfully authenticated，说明免密配置成功。

3.4 为什么推荐SSH而不是HTTPS

我见过不少新手问"两种地址clone的仓库有什么区别"。本质上是传输认证方式的区别：HTTPS依赖用户名/密码/token，SSH依赖密钥对。日常使用里，SSH最大的优势就是稳定免密——除非你手动换了私钥，否则永远不会被登录认证拦住。而且SSH协议在网络环境里默认走22端口，对一些防火墙环境也更容易放行。

如果你手头已经用HTTPS地址clone了仓库，想切换成SSH免密，可以在仓库根目录执行：

git remote set-url origin git@github.com:用户名/仓库名.git

执行完之后git remote -v确认远程地址变了，后续push就和SSH模式下一样免密了。

4. 本地仓库四步循环：init、add、commit、log这样串起来用

4.1 init创建仓库：每个项目都有的那个.git文件夹

在项目根目录打开终端（Windows右键Git Bash Here），执行：

git init

Git会创建隐藏的.git目录，这就是仓库的核心所在。之后所有版本历史、分支指针、配置信息都存在这里。用ls -a能看到它。

一个很容易踩的坑：不要在已有的仓库里再执行git init。如果你本来就在某个仓库的子目录下工作，那么外层仓库会把它当成整个仓库的一部分，形成嵌套——两个仓库互相打架，追踪混乱。如果你不确定当前目录是否已经属于某个仓库，用git rev-parse --show-toplevel查看当前归属的最外层仓库路径。

4.2 分清工作区、暂存区、仓库三个概念

Git接下来全部概念都围绕三个区域展开：

• 工作区（Working Directory）：你正在编辑的实际文件。
• 暂存区（Staging Area / Index）：提交前的"整理台"，把打算纳入本次提交的文件放进来。
• 仓库（Repository / .git）：保存所有历史快照的地方。

绝大多数操作就是在这三个区域间搬运内容。你可以用git status随时查看内容处于哪个状态，这个命令最好没事就敲一遍，它是唯一一个怎么敲都不会搞坏东西的Git命令。

4.3 add的作用：为什么必须分成"暂存"和"提交"两步

git add把工作区的改动挪进暂存区。为什么不能直接一步提交完，非要分两步？我举一个实际项目里特别常见的场景：你同时修改了两个文件，一个修复了登录界面的bug，另一个只是顺手加了两个注释。你应该把它们分成两次提交，这样以后git log里看历史时，能清楚地看到"修复bug"这条记录和"整理注释"这条记录各自对应哪些改动。

Git通过暂存区给了你这种精确控制的能力：只把需要提交的文件add进去，然后commit，再继续add另一批。

常用命令：

git add filename.txt # 添加单个文件 git add src/ # 添加整个目录 git add . # 添加当前目录下所有改动

4.4 commit：把暂存区定格为历史快照

执行：

git commit -m "修复登录页面按钮在移动端不居中的问题"

-m后面是提交信息。提交信息质量，直接影响你三个月后再翻历史时的体验。我自己的规范是：用一句话描述这次提交做了什么，动词开头，尽量具体。比如"修改了东西""更新代码"这种就等于没写，而"修复订单列表在金额为空时崩溃的问题"即使过了很久也能快速定位。

关于git commit -am "信息"：加-a参数的意思是"把所有已跟踪文件的改动自动add后提交"。它省了手动add这一步，但有个前提——只对已经被Git跟踪过的文件生效，新建的文件依然要先add，所以对新手来说，老老实实先add再commit更稳。

4.5 log：查看历史记录的正确姿势

git log

你会看到所有提交按时间倒序排列，一个提交对应一条包含哈希值、作者、日期和提交信息。哈希值（commit hash）是每次提交的唯一身份证号。

对新手来说，下面这两个变体更实用：

git log --oneline # 每条提交只显示一行，简洁很多 git log --oneline --graph --all # 带分支图形的完整视图

--graph会画出一条ASCII艺术风格的分支线，这是理解分支合并最直观的方式之一。

4.6 版本回退：reset、checkout与revert的区别

回到过去，是初学者最想学又最怕用的功能。Git提供三种思路，别混用：

git reset——把分支指针回退。

git reset --soft HEAD~1 # 回退到上一个提交，但保留所有改动到暂存区 git reset --mixed HEAD~1 # 回退到上一个提交，改动保留在工作区（默认模式） git reset --hard HEAD~1 # 回退，并且丢弃所有改动。慎重！

--hard模式相当于"读档"，工作区里所有未提交改动直接消失，没有后悔药（除了reflog，后面会讲）。新手如果只是想撤销提交但保留代码改动，用--mixed或--soft。

你不是想撤销提交，只是想把某个文件恢复到某个版本：

git checkout -- filename.txt # 丢弃工作区改动 git restore --staged filename.txt # 把文件从暂存区移回工作区

新版Git更推荐git restore这套命令，语义更清晰。

谨慎场景——提交已经推到远程共享分支了怎么办？这时候别用reset，远程历史已经被同事拉下来了，改写历史会导致混乱。正确做法是生成一个新的反向提交：

git revert HEAD

revert不是删除历史，而是用一次新的提交把之前的改动"反着做了一遍"，最终效果是内容回退了，但历史完整保留了。这一点在团队协作里非常重要。

最后补一个"后悔药的后悔药"：如果你连reset --hard都执行了，想找回被扔掉的提交，git reflog会记录所有HEAD移动的痕迹，找到对应哈希后git reset --hard 哈希就能救回来。这就是Git本地完整历史的威力。

5. 分支不是魔法：创建、切换、合并的全套操作

5.1 为什么需要分支：让多条开发线互不打扰

设想你在开发一个电商首页，同时线上突然报了一个严重的结账bug，必须立刻修复上线。如果没有分支，你要么把写了一半的首页代码直接提交（半成品上线风险大），要么把写了一半的东西藏起来再去改bug（手忙脚乱）。有了分支，你可以从稳定的主分支切出一个bugfix/pay-error分支，在上面修完bug合回主分支，再切回自己的feature/homepage分支继续爽快地开发首页。

分支的意义就是：每个人的工作线可以安全地并行，谁也不会踩到谁。

5.2 分支的本质：一个可移动的指针

初学者以为分支很玄，其实它的本质就是指向某个提交的指针。创建新分支等于给当前提交贴上一张新书签：

git branch feature/homepage

这条命令之后，master（或main）和feature/homepage都指向同一个提交。HEAD是个特殊指针，用来表示"你当前在哪张书签上"。切换分支，本质就是移动HEAD指向。

理解了这点，就明白为什么Git创建分支几乎零成本——它只是新建了一个小小的指针，根本不是复制文件。

5.3 分支操作全家桶

git branch # 查看本地分支列表，当前分支前面有*号 git branch feature/login # 创建分支 git switch feature/login # 切换分支（新版Git推荐） git switch -c feature/login # 创建并切换，等价旧版 checkout -b git branch -d feature/login # 删除已合并的分支 git branch -D feature/login # 强制删除未合并的分支，慎用

命令行里我推荐用git switch而不是git checkout切换分支，旧版checkout同时在承担"切分支"和"恢复文件"两个职责，很多新手容易混。switch命令21年后的Git版本默认可用，语义单一清晰。

5.4 merge合并的三种情况，以及冲突怎么解

当你在feature分支开发完，想把它合并回主分支，先切回主分支，然后执行merge：

git switch main git merge feature/homepage

合并结果有三种类型：

快进合并（Fast-forward）：主分支在你拉出feature之后没有任何新提交，那么Git直接移动主分支的指针指向feature的顶端，历史变成一条直线，没有多余的合并节点。

三方合并（Merge commit）：主分支又有新提交（比如别人合了一个bugfix），情况变成两个分支从同一祖先出发各自产生新提交，Git会创建一个"合并提交"把两边拍到一起。这条记录有两个父节点，代表"两种历史在此汇合"。

冲突（Conflict）：合并时如果两边的改动修改了同一个文件的同一段内容，Git无法自动判断该保留谁，就会停下来等你做人工裁决。冲突文件里会出现类似这样的标记：

<<<<<<< HEAD 这是当前分支（main）的版本 ======= 这是被合入分支（feature）的版本 >>>>>>> feature/homepage

解决冲突的操作流程：git status查看哪些文件冲突 -> 打开文件 -> 找到冲突标记 -> 把不需要的部分删掉，保留你要的最终结果 -> 删除<<<<<<<、=======、>>>>>>>这三行标记 ->git add filename->git commit。

冲突不是错误，是版本控制的常态。我见过很多新人遇到冲突就慌，其实只要记住"Git把两边内容都摆在明面上让我挑"，照着上面的流程一步一步处理，根本没什么难度。真正减少冲突的方法反而很简单：功能分支尽量短命（别分支拖几周不合并）、每次动手前先把主分支最新代码拉下来合并进自己的分支、大改动拆成小改动分批提交。

6. 远程协作三件套：clone、push、pull的配合姿势

6.1 remote与origin：远程仓库别名

远程仓库本质上就是另一台机器上的Git仓库。常用做法是在GitHub等平台点网页上的"New repository"创建一个空仓库，然后把它和本地的仓库关联起来。关联的命令：

git remote add origin git@github.com:用户名/仓库名.git

origin是远程仓库的默认别名，本质上是一个URL的缩写。可以随时用git remote -v查看当前关联了哪些远程仓库。

6.2 clone：从零复制一个仓库到本地

如果你要参与某个已有项目，不需要init，直接clone：

git clone git@github.com:用户名/仓库名.git

重点来了：执行完clone之后，origin已经自动设置好了，不需要再手动remote add。你可以直接git pull拉取最新代码，基于某个分支改东西然后git push。

如果你的需求是"在本地写了一个代码库，想把它推到GitHub上"，彻底从零开始，流程是这样：

cd 项目根目录 git init git add . git commit -m "initial commit" git branch -M main git remote add origin git@github.com:用户名/仓库名.git git push -u origin main

-M main是把默认分支名改成main（很多平台新仓库默认main）；-u的含义是设置上游分支，第一次push之后，以后直接git push就可以，Git知道该往origin哪个分支推。

6.3 push：把本地提交推到远程

git push

如果分支没有设置上游，需要完整写法：

git push -u origin 分支名

push被拒绝是新手高频遇到的情况，典型报错是：

! [rejected] main -> main (fetch first) error: failed to push some refs

这句报错的意思是：远程分支上有一些本地没有的提交，Git不允许你直接覆盖。解决方法是先git pull把远程新提交拉下来合并，解决可能的冲突，然后再push。

6.4 pull和fetch到底啥区别

git fetch只把你的远程追踪分支（比如origin/main）更新到最新状态，但不改动你本地的工作区，也不会修改你的分支指针。git pull则相当于：

git fetch git merge origin/当前分支

也就是说pull是fetch + merge的合并命令。fetch是只下载数据，merge是把下载的内容合入当前分支。

对新手来说，我强烈建议前期养成"先fetch再merge"的好习惯，因为fetch本身是绝对安全的操作，不会动你的工作区，而pull如果遇到冲突，一切都要当场立刻处理。等你对Git有了感觉，再直接用git pull省事。

还有一个常见操作git pull --rebase。它会把本地当前分支的提交先"摘下来"，拉到远程最新代码之后再把本地提交重新放上去，最终形成一条干净的线性历史。这个技巧后面rebace的章节会详细讲，这里先知道它能避免产生多余的合并记录就行。

6.5 团队协作的标准工作流：别憋大招，要常提交常同步

我见过太多新人喜欢一天做十几个小时的活，中间一次都不提交，最后一次性push，结果要么被冲突折磨，要么几百行改动的提交信息根本没法写。

正确的协作节奏应该是：

1. 开工前git pull同步最新代码。
2. 每一次逻辑完整的修改，git add+git commit，提交信息写清楚。
3. 每次准备休息或到时间节点，再git pull合并一遍远程改动。
4. 确认一切正常，git push -u origin 分支名推上去。

这样即使哪次合并出了岔子，回退范围也极小，定位问题很快。

6.6 图形客户端也能用，但别依赖它排错

TortoiseGit（小乌龟）在Windows开发者群体里非常流行，安装之后在资源管理器文件夹空白处右键就能看到菜单，提交、拉取、推送一目了然。还有一个常见需求是IDEA里clone项目：File -> New -> Project from Version Control，粘贴仓库地址，IDE会自动检测并clone，之后右下角Git工具栏就能执行常见操作。

使用图形客户端确实大幅度降低了初学门槛，它们的提交界面能明确显示哪些文件被改动、哪些进了暂存区，比命令行直观。但我的建议是：日常操作你可以用图形界面，但一旦报错，最终还是得回到命令行去看完整错误信息。图形界面的优势是把复杂命令包装成按钮，弱点也是——出错时它给你看的内容往往不够源头。

7. 进阶操作里最容易踩坑的三个场景：stash、tag、rebase与忽略文件

7.1 stash：临时把半成品藏起来

场景：你在离下班还有10分钟时开始重构一个模块，刚改了个开头，线上突然报了个紧急bug，你必须立刻在干净的工作区上切换分支修复。

这时候不允许直接提交半成品代码，因为你不想留"重构到一半"这种丑陋的提交记录。办法是stash：

git stash

当前工作区和暂存区的所有改动都会被保存到一个"储藏堆"里，然后工作区瞬间回到干净状态。你继续切分支、修bug、合并、发布，完事之后切回原来的分支，恢复储藏：

git stash pop

几个补充细节：

• git stash list查看所有储藏记录。
• 默认stash只储藏已跟踪文件的改动，新文件要用git stash push -u才会一起带走。
• 如果你有多个stash，恢复指定记录用git stash apply stash@{1}。

stash还有个隐藏用途：处理"我改了一堆不知道该怎么办，先缓存一下"的情况，但它不能替代提交。stash的内容不会出现在git log里，如果机器丢了就真的丢了。半成品代码如果重要，更保险的是开一个WIP临时分支提交上去。

7.2 tag：给版本打一个不可移动的标记

分支指针会随着提交移动，但标签（tag）一旦打上就钉死在那里。这非常适合标记发布版本号，比如项目第1.0.0版发布的时候：

git tag -a v1.0.0 -m "发布1.0.0版本"

打完tag之后，任何时刻想切到发布版本看一眼，git checkout v1.0.0即可。push的时候注意：tag不会跟着代码自动推送到远程，需要显式推送：

git push origin v1.0.0 # 推送单个标签 git push origin --tags # 推送所有标签

-a表示创建附注标签（annotated tag），会包含打标签的人、时间、说明信息，比轻量标签更适合正式版本发布。

7.3 .gitignore：让Git无视某些文件

项目里总有一些文件不该进版本库：依赖包目录（比如Node.js的node_modules、Java的target）、IDE配置文件（.idea、.vscode）、日志文件和本地环境配置（.env.local）。如果不加约束，这些文件会被add .一股脑提交上去，把仓库撑大、污染提交历史，甚至可能泄露本机密码。

在仓库根目录创建.gitignore文件，按规则写：

node_modules/ dist/ *.log .env.local .idea/

语法规则很简单：

• 斜杠结尾表示目录（如node_modules/）
• *匹配任意字符（如*.log匹配所有.log文件）
• !开头表示排除（如*important.log先忽略了所有log，再!keep-important.log把这个例外回来）

最容易踩的坑是：文件已经被Git跟踪之后，再往.gitignore里加规则是没用的。Git只认你当前的追踪状态，已经进仓库的文件不会被自动忽略。要让它"脱离管理但保留在本地"，执行：

git rm --cached 文件名

把文件从仓库索引里移除，之后它就不再被Git跟踪了，这时.gitignore规则才会对它生效。

7.4 rebase：让分支历史更干净，但有一条黄金法则

merge的历史是一张"交通网"，rebase的历史是一条"直线"。rebase的底层逻辑是：把当前分支的提交逐个"摘下来"，以目标分支最新的提交为新的基底，重新放上去。

git switch feature/logic git rebase main

效果是feature分支上所有提交被"回放"到main最新提交之后，最终看起来就像feature是从main的顶端fork出来、一口气开发完的，历史变得非常线性、整洁。

那什么时候用merge什么时候用rebase？在团队协作里有一个朴素的共识：

• 自己的功能分支在同步主分支最新代码时，用rebase，可以让主线历史干干净净。
• 把功能分支合并回公共分支时，用merge，因为合并节点真实记录了"这里合过一条功能线"这一事实。
• 绝对不对已经push到共享远程的提交做rebase。这是铁律。rebase会改写提交哈希，如果别人已经基于你的旧提交开发，你一旦rebase再push，别人那边就会产生大量无可救药的冲突。

如果你用rebase解决冲突遇到问题，可以用git rebase --abort完全退出rebase状态，恢复原样，这是新手最需要记住的逃生门。

7.5 一个串起来的完整场景

假设你正在写下单功能：

git switch -c feature/checkout # 1. 创建功能分支 git add src/checkout/ # 2. 写了一阵，提交 git commit -m "实现购物车结算第一步" git fetch origin # 3. 同步主分支 git rebase origin/main # 4. 把主分支最新代码作为自己的基底 # 如果冲突，解决后 git add 冲突文件 && git rebase --continue git push -u origin feature/checkout # 5. 推送到远程

这个流程实操下来顺手很多，你会发现主干永远是一条清晰主线，自己的功能分支上面挂着整齐的小步提交。

8. 高频报错急救室：从"无法识别git"到clone慢的排查思路

8.1 Windows报"无法将git项识别为cmdlet"，mac/Linux报command not found

这个报错几乎每个新手都会遇到至少一次。在Windows的PowerShell或CMD中执行git时报出的原文是：

git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。 请检查名称的拼写，如果包括路径，请确保路径正确，然后再试一次。

排查思路就三步：第一步，确认安装版本是否正确，打开C:\Program Files\Git\cmd\git.exe看看文件是否存在；第二步，确认PATH环境变量里有没有Git的cmd目录；第三步，关闭所有已打开的终端窗口重新打开——这是最容易被忽略的一步，因为GUI安装工具的PATH设置要新进程启动时才会生效。

macOS出现command not found，先确认是不是没装：xcode-select --install触发系统开发者工具安装，或者用Homebrew装真Git。

另外一个看报错的关键：仔细看提示里的git是不是多了什么字符。比如有人在系统自带的编辑器里敲了git add.而不是git add .，还有的报git: 'add.' is not a git command，原因大概率是命令格式错误。

8.2 clone速度很慢或断掉，可能的原因与常规处理

Git clone慢，困扰了很多开发者。原因通常不是Git本身，而是目标托管服务器和你的网络链路之间存在较高的延迟或丢包。能给出的常规处理手段，按优先级排序：

浅克隆：只拉取最新一层提交历史，显著减少网络传输量：

git clone --depth 1 git@github.com:用户名/仓库名.git

缺点是之后需要完整历史的部分功能会受限，但单纯为了看代码、改代码完全够用。

换网络环境：如果你在热点或校园网环境下clone特别慢，换到更稳定的宽带网络通常立竿见影。网上很多教程让你配置各种代理，但从合规性和稳定性角度，我更建议直接换一个网络链路良好的环境。

换托管平台：如果是Gitee上有镜像的仓库，从Gitee clone会快很多；或者让同事把仓库打包发给你再导入，然后重新设置remote指向原平台。这类做法完全合法合规，就是绕过网络瓶颈的思路。

大仓库考虑Git LFS：如果仓库包含大量二进制文件（设计稿、数据集），常规Git方式会让仓库体积失控，团队应该引入Git LFS（Large File Storage）把这些大文件放到扩展存储中，避免clone时每次都拉全量二进制内容。

8.3 push或clone报登录失败、token验证错误

项目实战里，IDEA等IDE连接GitLab时经常出现这类报错：

Login failed. Check API token or GitLab version. Log in via Git if the version of your IDE is not supported.

这个报错的原因通常是IDE安装的GitLab插件版本太老，或者token已过期。可以在IDE的Version Control设置里把GitLab集成方式改为"Use credentials from Git"而不是"Use API token"，或者重新生成一个有效期较长的Personal Access Token。

如果是命令行push时报：

fatal: Authentication failed for 'https://github.com/用户名/仓库名.git'

大概率是HTTPS方式下的账号密码或token失效。解决思路：Windows打开"控制面板 -> 凭据管理器 -> Windows凭据"，找到GitHub相关条目删除，下次push重新输入；macOS在"钥匙串访问"里删除对应git密码记录；Linux看使用的credential helper配置。

嫌这些麻烦，干脆回到第3章把SSH配置好，从根上绕开HTTPS每次都要认证的问题。

8.4 换了换行符？LF和CRLF的警告要不要理

Windows和Linux/macOS对换行符的编码不同。当你看到一个警告：

warning: LF will be replaced by CRLF

这不算错误，是Git在提示你文件里的换行符会被转换。团队项目里解决这个问题的正规操作是统一配置一行：

git config --global core.autocrlf true # Windows推荐

Windows上设true，提交时自动把CRLF转成LF存进仓库，checkout时再转回CRLF，这样团队跨平台协作不会因为换行符产生"整个文件都被标记为改动"的灾难。

8.5 一个容易忽视的安全红线：.git目录不能暴露在线上

最后说一个偏安全但很重要的点。项目根目录下的.git文件夹里存着完整的源码历史、远程地址、可能还有临时凭证信息。如果部署Web项目时整个目录都传到了服务器，并且Web服务允许访问/.git/config这个路径，等于源码和全部历史都暴露给任何能访问网站的人。这就是"git目录泄露"这个网传话题背后的真实风险。

防护手段也很简单：部署时排除.git目录（比如用rsync加--exclude='.git'，或者构建镜像时做一个.dockerignore写入.git），同时在Web服务器或CDN层面禁止外部访问所有/.git路径。不要等到被爬取扫描到才想起来处理。

下面是一张高频命令速查表，放在这里方便日常翻：

写到最后想分享一个我带新人时的感觉：Git的学习曲线看着陡，其实真正的"拐点"就两个。第一个拐点是理解"提交对象"——当你搞清楚一次commit到底存了什么、分支和HEAD是什么关系之后，后面所有操作都是这些基础概念的组合。第二个拐点是从"单人操作"迈到"多人协作"——merge冲突来那么一次、处理那么一下，你对Git的信任感会完全不同。不要试图第一天就背熟所有命令，先把status -> add -> commit -> log这个循环跑顺，再一个功能一个功能地叠加。需要什么查什么，比死记硬背高效得多。真遇到解不开的问题，记住git help永远在线，git reflog永远兜底，Git的本地仓库自愈能力比你想象中强得多。