企业官网建设流程全解析

写Git本地基础操作的文章，标题本身看起来平淡，但如果你真的在命令行里摸爬滚打过一段时间，就会明白“本地”这两个字才是真正的主角。绝大多数新手一上来就急着搞远程仓库、SSH密钥、推代码，结果本地分支乱成一团，提交历史改得不成样子，最后只能靠删仓库重新clone来“修复”。我也经历过那个阶段，所以这篇文章不做面面俱到的Git百科，就围绕日常开发里真正高频的本地操作，把每个命令背后的逻辑讲清楚，附上我踩过的坑和现在还在用的习惯。

先介绍一下这篇文章能解决什么问题。无论你用的是Windows、macOS还是Linux，只要想在本地用Git管理代码，或者你已经在用但总被各种报错卡住，这篇都适合你。内容从Git安装、初始化仓库、文件状态流转，到分支合并、撤销回退，最后聊几个常见但容易误导人的排查场景。看完之后，你可以不看文档就能处理绝大多数本地开发场景。

1. Git安装与初始配置：第一道门槛没你想的那么顺

1.1 各平台的安装方式和版本选择

Git的安装在不同平台上体验差异挺大，先说Windows。现在官方推荐的安装包是Git for Windows，直接去官网下载64-bit版本就行。安装过程中有几个选项很多教程没说清楚，我重点讲三个：

• Adjust your PATH environment：一定要选“Git from the command line and also from 3rd-party software”，默认选项是“Use Git from Git Bash only”，如果选了它，你在CMD或PowerShell里敲git会提示找不到命令。
• Line ending conversions：建议选“Checkout as-is, commit as-is”，也就是不做换行符转换。默认的“Checkout Windows-style, commit Unix-style”容易导致整个项目的换行符被改来改去，尤其在多人协作时会出现大量无意义的diff。
• Terminal emulator：默认的MinTTY体验还行，但如果你习惯用Windows Terminal，选“Use Windows' default console window”更舒服，避免每次打开自带终端时窗口风格不一致。

macOS这边，如果你装了Homebrew，一条命令的事情：brew install git。如果你不想装Homebrew，直接用官方安装包也可以，但要注意macOS自带的Git版本可能比较老，某些指令的行为和输出格式跟新版有差异。Linux用户直接走系统包管理器，Ubuntu/Debian是sudo apt install git，CentOS/RHEL是sudo yum install git。

安装完之后，在终端输入git --version，如果输出了版本号，说明安装成功。没有输出的话，先检查PATH配置，再看看终端有没有重新打开——这点经常被忽略，老的终端窗口里不会加载新安装的PATH。

1.2 初始化必须做的两步配置

很多人装完Git就急着干活，结果第一次提交时看到一堆带颜色的英文报错，最常见的就是：

Please tell me who you are. Run git config --global user.email "you@example.com"

Git要求每个提交必须关联用户和邮箱，这是提交记录里身份信息的来源。如果没配置，Git会拒绝提交。所以安装之后第一件正事就是：

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

这里用--global意味着这台机器上所有仓库都默认使用这个身份。如果某个项目需要单独身份，可以去掉--global重新配置，优先级上仓库级配置会覆盖全局配置。这个机制在区分个人项目和公司项目的提交身份时非常实用。

配置完之后，用git config --list确认一下，或者直接查单个配置项：

git config --global user.name git config --global user.email

还有几个配置项也建议顺手搞定。git config --global core.editor设置默认编辑器，遇到需要输入多行提交信息时会用到；git config --global init.defaultBranch main把默认分支名从master改成main，避免后续每次都用-M重命名。我不是说master一定不好，但新项目用main已经很普遍，提前设好省一步操作。

1.3 为什么全局配置和代理设置容易踩坑

图片：不少人不理解为什么git config还有http.proxy这类配置。当你所在网络环境需要代理才能访问某些资源时，Git并不会自动读取系统代理，需要手动指明。但本地操作和走HTTP协议拉取远程仓库时，这个配置可能带来负面影响。如果你明确知道当前网络不需要代理，但配置里残留了一些杂项设置，常见表现就是clone或pull操作时一直卡住或SSL报错。遇到这种情况，先检查配置，而不是反复重装Git。

git config --global --list

看到http.proxy或https.proxy不在预期内，可以删除它们：

git config --global --unset http.proxy git config --global --unset https.proxy

这条排查经验我加粗强调一下：绝大多数Git远程连接的诡异问题，先查config再找网络问题，顺序不要反。

2. 仓库初始化与文件状态流转：理解这三个区是省钱的关键

2.1 git init只做了一半的工作

git init这条命令在项目目录下执行，会生成一个.git文件夹。很多人以为执行完这一步仓库就算建好了，其实只完成了一半。.git目录内部保存的是对象库、引用、配置等核心数据，你平时操作的其实是工作区里的文件，它们还没有被Git跟踪。

我第一次带新人的时候，经常看到他们git init之后直接git commit -m "init"，然后报错“nothing to commit”。这个流程没错，但缺了最关键的一步：git add。还有一部分人分不清git init和git clone的差异。git init是从零创建一个新的本地仓库，git clone是把已有的远程仓库完整复制到本地。本地基础操作讨论的范围，绝大部分场景是git init这条路线。

建好仓库之后，推荐立刻看一眼.git目录里有没有东西：

ls -la .git

如果能看到HEAD、config、objects、refs这些文件和目录，基本可以确认初始化成功。之前遇到过用户把git init跑到了错误的目录层级，比如home目录下，然后后续所有操作都在错误的仓库范围内进行。判断方法很简单：git rev-parse --show-toplevel会输出仓库根目录路径，如果输出不是你认为的项目根目录，恭喜你，仓库建错地方了。

2.2 工作区、暂存区、版本库之间的关系

Git本地有三个核心区域：工作区、暂存区（index/staging area）、版本库（repository）。用一个生活化的类比：工作区是你做饭的厨房，所有菜料都摊在操作台上；暂存区是已经洗好切好并装盘的部分；版本库则是已经拍好照片的成品菜谱记录，每按一次快门就是一个commit。

• 工作区：你当前目录里看到的文件，可以被修改。
• 暂存区：通过git add把工作区的修改放进来，表示“我准备要提交这些”。
• 版本库：通过git commit把暂存区内容永久记录成一个版本。

这个设计的价值在于：你可以对多个文件分别操作，选择性地提交某些文件，而不是一次把所有变动都扔进历史。比如你改了A文件修复bug、改了B文件加新功能，就可以分两次提交，让历史记录更清晰。这个习惯在后续回溯问题时能省大量时间。

2.3 文件的四种状态转换

Git官方把文件状态分成四类：

• Untracked（未跟踪）：新文件，Git不知道它的存在。
• Modified（已修改）：文件被改过，但改动还没进暂存区。
• Staged（已暂存）：改动已经加到暂存区，等待被提交。
• Committed（已提交）：改动已经写入版本库，成为历史的一部分。

同一个文件在不同阶段会呈现出不同状态。比如新建一个app.py，用git status会看到它在Untracked列表里；执行git add app.py后变成Staged；执行git commit后，git status就干净了。改一次app.py内容后，状态又变成Modified，但此时可能有两个app.py版本概念：一个是暂存区里上次add的版本，一个是工作区里最新修改的版本。

这里有一个容易混淆的概念：如果你修改了文件但没有git add，然后又执行git commit，提交的内容是暂存区里的版本，不是工作区的最新版本。我在实操中见过有人连续改文件却不add，最后commit完发现改动的文件根本没进提交，就是这个原因。所以提交前养成git status和git diff --cached双重确认的习惯很重要。

2.4 实战：完成你的第一次本地提交

还是用项目初始化来走一遍完整的流程：

mkdir my-project && cd my-project git init echo "# My Project" > README.md git add README.md git commit -m "docs: init project with README"

这几条命令做完，项目目录就有了第一个提交。用git log查看，能看到类似这样的记录：

commit 3a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b (HEAD -> main) Author: your name <you@example.com> Date: ...

HEAD -> main表示当前处于main分支的最新提交。这里多说一句：HEAD是Git的指针，它总是指向当前分支的最新提交。理解了HEAD的含义，后续看分支切换和回退操作都会容易很多。

3. 高频命令实战：git status、log、diff的合理使用姿势

3.1 git status：不只是看有没有变化

git status是最常被低估的命令。新手会觉得它无非就是显示“nothing to commit, working tree clean”或一堆红色文件名，但它的输出其实包含了非常丰富的信息量。

不带参数的git status显示的是简洁状态；git status -s则用单行缩写显示，每行一个文件，左侧两个字符分别代表暂存区和工作区的状态。比如：

$ git status -s M README.md A new_file.txt ?? untracked_dir/

• M（注意空格在M前面）：工作区有修改，暂存区没有。
• A（A在后面加空格）：已暂存的新文件。
• ??：未跟踪的文件。

这个缩写模式在批量处理文件改动时非常好用，能直观看出哪些文件已经add、哪些没有。配合git diff使用更顺畅：不带参数时git diff比较的是工作区和暂存区；git diff --cached比较的是暂存区和最近一次提交。这两个diff场景很多人搞混，记住一句话就行：git diff看的是“还没add的改动”，git diff --cached看的是“已经add但还没commit的改动”。

3.2 git log：学会过滤你才能真正看懂历史

git log默认输出的是一长串提交记录，信息包括哈希值、作者、日期、提交信息。信息多的时候很乱，所以我会习惯用：

git log --oneline --graph --decorate --all

• --oneline：每条提交只显示一行，包括短哈希和提交信息。
• --graph：用ASCII字符显示分支历史图，分支分叉合并一目了然。
• --decorate：显示分支名和HEAD位置。
• --all：显示所有分支的提交，而不是只有当前分支。

这几个参数组合起来基本就是我日常的默认log命令了。如果只想看某个文件的修改历史，后面加文件名：

git log --oneline -- app.py

想统计某段时间的提交情况可以用--since和--until，比如：

git log --oneline --since="2 days ago"

搜索提交信息里的关键词：

git log --grep="fix"

这些过滤技巧对排查问题非常有效，尤其是项目大了之后，提交数量成百上千，一句log不加参数直接输出能刷屏几十页。

3.3 git diff的三种比较对象

diff看似简单，但三种比较对象的组合逻辑值得好好梳理：

第三种组合其实等同于前两种的合并视图，能一次看到所有未提交的改动。我遇到过大把人在git diff里看不到预期结果，仔细一查发现改动其实已经add过了，得用--cached才能看到差异。如果你不确定改动到底处于哪个阶段，直接跑git status看一眼，状态明确了再用对应的diff命令。

还有一个容易忽略的场景：git diff默认不比较二进制文件，只显示“Binary files differ”。想强制看二进制文件的文本化变化，得加--text参数，不过实际意义不大，因为内容基本不可读。本质上diff命令是让你在提交前做一次自查，避免把调试日志、临时配置等杂物带进提交历史。

3.4 文件删除与重命名的正确处理方式

你在工作区手动删除文件后，git status会显示该文件为deleted。想让删除操作进入暂存区，常见做法是git rm。它实际上做了两件事：删除工作区文件，并把删除操作暂存。如果你已经手动删了文件，再执行git rm也行，Git会识别当前状态并把删除同步到暂存区。

如果只想从版本控制中移除文件但保留本地文件（比如误提交了配置文件，希望它不再被跟踪），用：

git rm --cached config.ini

这个操作很实用，不会动你磁盘上的文件，只是把它从追踪列表里拿掉。

重命名操作不需要特殊命令，git mv old_name.py new_name.py或者直接mv然后git add new_name.py; git rm old_name.py，Git都能识别为rename。识别靠的是内容相似度，不是文件名严格对应，所以大大重命名之后内容改太多也可能被判定为“删除+新增”，但这种差异在功能上没有影响，不用纠结。

4. 分支管理与本地合并：从新建分支到冲突解决

4.1 分支的本质和创建切换的底层逻辑

分支在Git里不是目录的物理拷贝，而是指向提交对象的引用（指针）。创建分支就是创建一个新的可移动指针，切换分支就是让HEAD指向另一个分支名。

创建并切换分支最常用的写法：

git checkout -b feature/login

或者新版Git推荐：

git switch -c feature/login

两者的效果完全一样，switch是后来为单职责设计的新命令，可读性更好。我个人从checkout习惯了，但其实switch更不容易误操作，因为checkout还兼任恢复文件的功能，switch只专注分支切换，语义清晰。

git branch列出所有本地分支，当前分支前会有一个星号和绿色高亮。查看分支和提交的关系可以用：

git branch -v

它显示每个分支最近一次提交的哈希和提交信息。分支多了之后，这个命令能帮你快速判断哪个分支比较新、哪个分支落后了。

4.2 合并操作的两种方式与适用场景

本地合并最常见的两种方式：git merge和git rebase。标题热词里出现的“git分支合并”指的大概率是merge操作，这里先讲merge。merge有两种模式：普通merge和--no-ff（no fast-forward）。

当被合并的分支基于当前分支最新提交直接超前时，Git默认执行fast-forward合并，只是把当前分支指针向前移动到目标分支，不会生成额外的合并提交。这种模式历史是一条直线，很干净。

但某些场景下你想保留“这里发生过一次合并”的痕迹，比如合并一个feature分支进main，希望回看历史时能明确知道功能是从哪合入的。这时用：

git merge --no-ff feature/login

它会强制生成一个merge commit，即使可以fast-forward。项目协作中很多团队会规定主线分支只接受--no-ff合并，原因就是保留合并信息和分支结构，方便追溯。

普通merge模式下，如果两个分支修改了不同文件，合并过程直接完成；修改了同一文件但不同位置，Git通常也能自动合并；只有修改了同一文件的同一区域，才会出现冲突。

4.3 冲突生成与解决的完整过程

冲突是本地操作绕不过去的一关。我先构造一个最简单的冲突场景：

git init conflict-demo && cd conflict-demo echo "line 1" > app.py git add app.py && git commit -m "initial" git checkout -b feature echo "line 1 edited by feature" > app.py git commit -am "feature version" git checkout main echo "line 1 edited by main" > app.py git commit -am "main version"

现在执行git merge feature，几乎一定会收到冲突提示：

Auto-merging app.py CONFLICT (content): Merge conflict in app.py Automatic merge failed; fix conflicts and then commit the result.

打开app.py，会看到类似这样的标记：

<<<<<<< HEAD line 1 edited by main ======= line 1 edited by feature >>>>>>> feature

• <<<<<<< HEAD到=======之间是当前分支的内容。
• =======到>>>>>>> feature之间是被合并分支的内容。

这里要求你手动决定保留哪种内容，或者两者取一个折中。修改完冲突标记后，git add app.py，最后git commit生成合并提交。注意，合并提交不需要你重新写-m提交信息，Git会打开默认的合并信息编辑器，直接保存退出即可。

我处理冲突时还有一个习惯，先把冲突文件在编辑器里改完，再用git diff确认diff里没有冲突标记残留，最后add和commit。有些人改完忘记删<<<<<<<标记，提交出来的文件里还留着这些代码，非常影响后续开发。

另外提示一句：git merge --abort可以放弃本次合并，把仓库恢复到merge前的状态。当你觉得冲突处理起来太复杂，或者合并方向选错了，用这个命令安全退出，不会丢数据。

4.4 合并后分支的清理与状态确认

合并完成后，如果不再需要feature分支，可以删除：

git branch -d feature/login

-d在分支未完全合并时会拒绝删除，防止误删未合入的内容。如果确定不要了，用-D强制删除。这个设计我很喜欢，相当于Git给了你一层后悔药保护。

想看哪些分支已经合并进当前分支、哪些还没有：

git branch --merged git branch --no-merged

这个信息的价值在于安全清理长期不用的分支，避免误删还有独立提交的分支。

5. 撤销操作与版本回退：搞懂reset和revert的区别再动手

5.1 工作区改动的撤销：checkout/restore

撤销还没add的改动：

git checkout -- app.py

或者新语法：

git restore app.py

执行后，工作区文件恢复到暂存区的状态。这条命令会把你对文件的所有未暂存修改全部覆盖掉，不可逆，所以我只在明确不需要那些改动时才使用。如果改动里有不小心写的代码，先备份一下再说。

git restore还可以带--staged参数，用来把文件从暂存区移回工作区，但保留改动内容：

git restore --staged app.py

这个操作跟git reset app.py效果一样，但语义更清晰，我推荐新手统一用restore来理解这两个场景。

5.2 撤销已暂存的修改

如果你已经git add了，但还没git commit，发现改动有问题，有两种选择：

• 把改动从暂存区放回工作区：git restore --staged app.py，然后继续编辑。
• 彻底丢弃这些改动：git restore --staged app.py && git checkout -- app.py。

第二种做法其实就是组合命令，先把暂存区状态取消，再恢复工作区文件，最终效果是让文件回到上一次提交的状态。我见过有人遇到这种情况动不动就用git reset --hard HEAD，对单个文件来说太重了，容易把其他文件的暂存状态也搞乱。优先用restore，精准且安全。

5.3 已提交版本的撤销：reset与revert的选择

当commit已经产生，撤销操作就进入了“修改历史”的范畴，要格外谨慎。git reset移动的是分支指针和HEAD，有三种模式：

• --soft：只移动HEAD和分支指针，暂存区和工作区都不动。
• --mixed（默认）：移动HEAD和分支指针，重置暂存区，但工作区不动。
• --hard：移动HEAD和分支指针，同时重置暂存区和工作区，所有未提交的改动全部丢失。

实际中最常见的组合是：

git reset --soft HEAD~1

这会撤销最近一次提交，但把变更保留在暂存区，方便你修改后重新提交。如果你完全不要这次提交了，用git reset --hard HEAD~1，但要想清楚，这会彻底销毁这次提交以及工作区里对应的改动，无法从Git历史中找回。

git revert则是反向提交，它生成一个新的提交来“抵消”指定提交带来的变化，历史记录里会保留一条“revert xxx”的提交信息。它不改动已有历史，只是追加一条新记录。

两者怎么选？一个简单判断标准：如果这个commit已经推送到共享远程仓库，永远优先用revert；如果只是本地未推送，reset更干净。因为把共享历史回退会破坏其他开发者的克隆副本，造成大量合并冲突和混乱。本地操作阶段没有远程时，reset用起来轻松很多，但一旦涉及协作，要有敬畏心。

5.4 实操演练：回到某个指定commit

回到指定commit前，先用git log找到目标提交的哈希值，比如a1b2c3d。然后：

git reset --hard a1b2c3d

这会让当前分支指向a1b2c3d，之后的提交从当前分支历史中消失。但这些提交真的“消失”了吗？没有。Git的reflog会记录HEAD移动的历史，你依然可以通过git reflog找到它们：

git reflog

这是Git的万能恢复工具，尤其适合在reset之后发现自己回退错了，想找回原本的提交哈希时使用。我在实战中救过不止一次，所以强烈建议每个Git使用者都养成查看reflog的习惯。

6. 本地操作中常见的坑：从SSH认证失败到大小写误判

6.1 SSH认证失败：关键不在远程而在于本地密钥

热词里出现了“ssh认证失败 git”，这个坑在本地操作阶段其实也有体现。SSH认证失败的报错长这样：

git@github.com: Permission denied (publickey).

排查思路按顺序走：

1. 检查本地是否生成SSH密钥：ls ~/.ssh，看看有没有id_ed25519或id_rsa文件。
2. 没有就生成：ssh-keygen -t ed25519 -C "你的邮箱"，一路回车。
3. 把公钥（id_ed25519.pub内容）添加到远程仓库的SSH Keys设置里。
4. 用ssh -T git@github.com测试连接，看到成功提示说明通了。

如果这些步骤都做了还是失败，检查SSH agent是否在运行并加载了密钥：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

Windows上如果用的是Git Bash，还需要确保~/.ssh目录权限不是everyone可读，否则SSH会拒绝使用密钥。权限问题很容易忽略，也是认证失败的经典原因之一。

6.2 文件大小写与文件名错误

在Windows和macOS默认不区分大小写的文件系统上，Git对文件大小写的追踪有坑。假设你有一个文件readme.md，你把它改成README.md，git status可能不显示任何变化，因为文件系统认为它们是同一个文件。强制让Git识别大小写变化：

git mv readme.md README.md

如果mv做不了，可以分两步：先git mv readme.md tmp.md，再git mv tmp.md README.md。这个操作在项目从Windows迁移到Linux时会变得非常重要，因为Linux严格区分大小写，一旦大小写不一致，代码引用可能直接崩溃。

还有一种情况是误提交了巨大的临时文件，或者不小心把密码文件提交了。对于本地操作来说，前者可以用排除法避免。创建.gitignore文件，把构建产物、日志、依赖目录排除掉：

node_modules/ dist/ *.log *.env

注意，.gitignore只影响未跟踪的新文件，已经纳入版本控制的文件不受影响。想忽略一个已经跟踪的文件，得先git rm --cached再添加到ignore。

6.3 误删文件与误清暂存区的恢复

本地操作中，误删文件是常见的悲剧。比如你手动删了一个还没提交的源文件，或者执行了git checkout --覆盖了不该覆盖的改动，而且没提交历史可以还原。这时第一反应是看reflog：

git reflog

你会发现，虽然工作区文件被覆盖了，但Git可能仍然记录着对应的对象数据。用git fsck --lost-found扫描没有引用的对象，有时能找回丢失的内容：

git fsck --lost-found

找回的文件会出现在.git/lost-found/other目录里，虽然文件名已经丢失，但内容还在。这个场景不常遇到，但遇到的时候几乎等于救命。

6.4 误用--hard导致工作区大改丢失

git reset --hard是危险系数最高的命令之一，因为它会把工作区所有改动与索引全部重置到指定提交。执行前我强烈建议养成一个习惯：先git status确认没有需要保留的改动，或者先git stash把改动临时储藏起来。储藏后如果反悔了，可以随时恢复：

git stash push -m "临时保存的改动" git stash list git stash apply

stash是本地操作里最被低估却能有效避险的功能。它尤其适合在需要临时切换分支处理紧急任务、又不希望把半成品提交到历史上的场景。用它做重置前的安全网，比事后从reflog里捞数据轻松得多。

7. 用alias和习惯打造高效的本地Git工作流

7.1 把常用命令变成短命令

Git支持为子命令设置别名，配置文件在~/.gitconfig。我用的几个常用alias：

git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg "log --oneline --graph --decorate --all" git config --global alias.unstage "restore --staged"

配置完之后，git st、git co、git br用起来顺手很多。git lg尤其推荐——一个命令就能看到所有分支的完整历史拓扑，日常排查非常够用。别小看这些alias，敲命令容易出错的小而繁琐，缩短之后错误率自然下降。

7.2 遵循可读性更好的commit风格

本地提交信息的质量直接影响后续log检索的效率。我倾向于用类似conventional commits的写法，简洁干练：

git commit -m "fix: 修复登录模块超时问题" git commit -m "feat: 新增用户资料导出功能"

fix和feat作为前缀，让log过滤时一眼识别改动类型。再配合上面提到的git log --grep，排查某类变更会非常方便。提交信息写清楚的是“为什么改”，而不是“改了哪些文件”——后者diff里都有，前者才是真正有价值的历史信息。

7.3 本地提交流程的一个自我检查清单

我在本地执行每一步操作前，心里都有一个小清单，按此操作即可：

1. git status看看有哪些改动，确认哪些是要提交的。
2. git diff检查工作区改动，确认内容符合预期。
3. git add精确添加需要的文件，避免用git add .把无关文件一起带进去。
4. git diff --cached观察暂存区内容，和期望一致后再提交。
5. git commit提交，并写好信息。
6. git log --oneline -1确认提交已生成。

这个流程虽然多几个步骤，但每一步都很轻，习惯了就成自然反应。相比提交错了之后再去reset或者revert，前置确认是成本最低的防错方式。把时间花在事前的确认上，比花在事后的清理上划算得多。

我在实际项目里见过太多因为少了这一步确认，把临时调试代码、日志文件、甚至敏感信息直接提交进历史的案例，这比功能写得慢更让人头疼。Git本地操作本身不复杂，复杂的是养成正确的习惯。掌握了这套基础打底的操作逻辑，后面接远程协作、多人分支管理时，才不会手忙脚乱。