企业官网建设流程全解析

Git 这东西我几乎每天都在用，但每次帮人排查环境问题，发现卡住的往往不是命令本身，而是最开始下载、安装、配置这三步没走顺。这篇以 Windows 系统为例，把 Git 从下载安装到配置、再到常用命令和实战示例完整过一遍，适合刚接触 Git 的小白，也适合已经在用但想补强底层的同学。我会把每一步背后的原因也讲清楚，而不是只丢一串命令让你复制。你在自己电脑上照着点，基本能一次走通。

1. 装 Git 前的思考：Windows 上到底需要哪种 Git

1.1 先确认你的 Windows 版本和包管理现状

动手之前，先花一分钟确认环境。按下 Win + R 输入 winver 回车，能看到当前系统版本。Windows 10 和 Windows 11 都是 64 位居多，少数老机器是 32 位，这会直接影响你下载哪个安装包。之后再打开命令行（cmd 或 Windows Terminal），输入 git --version，如果系统提示“不是内部或外部命令”，说明这台机器还没有 Git，或者装了但没加入环境变量。

还有一种情况，电脑上已经装了某个图形化 Git 客户端，比如 GitKraken、SourceTree、TortoiseGit，但命令行里的 git 命令照样不可用。原因是这些图形客户端大多内置了自己的 Git 引擎，没有把可执行文件放进系统 PATH。我的建议是：不管平时习惯用哪种图形界面，都在系统层面装一份 Git for Windows，这样任何终端、任何编辑器都能调用它。

1.2 为什么我不建议用图形化工具完全替代命令行

图形工具的优点是直观，缺点也明显：很多关键操作被按钮封装了，出问题时你看不到底层指令到底是什么。比如一个“同步”按钮背后可能是 fetch、rebase、push 的组合，一旦出现冲突，图形界面给出的提示往往不如一行 git status 来得清晰。

命令行不是让你抛弃效率，而是让你拥有解释错误的能力。Git 本身是一个命令行工具，所有 IDE 的 Git 插件都是在调用它。自己在终端里敲过一遍 init、add、commit、push，以后看 IDE 里的报错日志，你会立刻明白是哪一步出了岔子。这篇教程会尽量说清楚每条命令“为什么要这样写”，而不是让你死记。

2. 下载与安装：走一遍完整流程

2.1 下载源的选择与安装包类型

Git 的官方下载页是 git-scm.com，进入后选择 Windows 版本，页面会自动识别你的系统位数。如果你不确定位数，可以直接选 64-bit 的安装包；如果是 32 位老系统，再选 32-bit 版本。

国内网络环境下，从官方站点下载大文件偶尔会比较慢。如果你遇到这种情况，可以去阿里云开源软件站或腾讯云软件源找 Git 的安装包，它们是国内服务器，速度通常更快。下载时注意认准包名里的版本号，比如 2.4x.x-windows-64-bit.exe，别下成 portable 版。portable 版是免安装的，适合临时用，但集成到右键菜单和环境变量上不如安装版方便。作为主力开发工具，我建议装标准安装版。

安装包下载好后，双击运行。Windows 可能会弹出 UAC 用户账户控制，点“是”就行。接下来的安装向导每一步都值得仔细看，因为某些选项装完以后修改起来比较麻烦。

2.2 逐项勾选安装选项，不踩坑

安装开始后会进入选择组件页。这里我建议保留这几个核心选项：

• Git Bash Here：右键菜单会出现“Git Bash Here”，让你直接在某个文件夹打开 Git Bash 终端，非常实用，建议勾选；Git GUI Here 是打开图形界面，可勾可不勾。
• Git LFS：大型文件支持。如果以后要处理设计稿、二进制包、数据集这类大文件，提前装好能省事，建议勾上。
• Associate .git* configuration files with default editor：把 Git 配置文件关联到默认编辑器，无所谓，可跳过。
• Associate .sh files to be run with Bash：让 .sh 脚本默认用 Bash 运行，建议不勾，避免影响系统里其他脚本的打开方式。

下一步是选择默认编辑器。默认是 Vim，新手容易卡住，因为不小心进入编辑模式后不知道怎么退出。我更推荐选 Visual Studio Code 或 Notepad++，前提是你已经安装了其中一个。如果电脑上都没有，那就先用 Vim，后面我会给出改成 VS Code 的配置方法。记住一句：在 Vim 里要退出编辑提交信息，按 Esc，输入 :wq，回车。

接着是最关键的 PATH 环境选项 ：

• Use Git from Git Bash only：只在 Git Bash 里能用 git，cmd 和 PowerShell 以及 VS Code 终端都会说找不到 git，不建议。
• Git from the command line and also from 3rd-party software：推荐。会把 Git 的可执行目录加进系统 PATH，所有终端都能直接用 git。
• Use Git and optional Unix tools from Command Prompt：会把 Git 自带的 find、sort 等 Unix 工具也加入 PATH，可能与 Windows 自带命令冲突，不推荐。

然后是 HTTPS 传输后端，默认是 OpenSSL，推荐保持默认。它和 Linux 上 Git 的行为一致，很多文档里的 SSL 问题排查方法都能复用。如果你所在环境有大量自签名证书，后面遇到证书报错时，可以再考虑切到 Windows Secure Channel（也就是原生证书库），具体我在常见问题部分展开。

换行符转换页面有三个选项，是 Windows 用户最容易踩坑的地方，我单独用一小节讲。

2.3 安装过程中的换行符选择原理

Windows 文本文件换行符是 CRLF（回车 + 换行），Linux 和 macOS 是 LF（只有换行）。Git 仓库内部倾向统一存 LF，但 Windows 用户希望工作区保持 CRLF。安装向导给你三个选择：

• Checkout Windows-style, commit Unix-style line endings：推荐，适合多数情况。检出到工作区时转成 CRLF，提交到仓库时统一改成 LF。
• Checkout as-is, commit Unix-style line endings：检出时不转换，提交时转成 LF。适合项目里已经有明确换行规范、并且你不想让 Git 自动改动的场景。
• Checkout as-is, commit as-is：完全不转换，最容易出现“文件被 Git 认为全部改动”的乱象，不建议新手选。

我推荐你在安装时选第一项。装完后如果发现某个项目表现异常，再用 .gitattributes 对特定文件单独控制，这个后面讲。

之后会问终端模拟器，选 Use MinTTY 即可，复制粘贴体验更接近 Linux 终端。最后会勾选 Enable file system caching，建议保留，它能提升 Git 在 Windows 上的文件状态读取速度。Enable symbolic links 默认不要勾，除非你开过开发者模式并且确需要符号链接。

一路 Next 完成安装。最后验证：重新打开一个 cmd，输入 git --version，能看到版本号就说明安装成功。如果还提示找不到命令，多半是 PATH 没生效，重启命令行或注销重新登录即可。

3. 基础配置：让 Git 记住你的身份和偏好

3.1 全局用户信息与配置文件位置

Git 每次提交都会记录作者和邮箱，所以第一件事就是配置身份。打开终端执行：

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

这两条命令写入的是全局配置文件。在 Windows 上它的位置是 C:\Users\你的用户名.gitconfig。你可以用记事本打开它，或者用下面命令查看：

git config --global --list git config --global --edit

--edit 会用默认编辑器打开配置文件。之前如果选了 Vim，这里打开的就是 Vim，你同样可以用 :wq 退出。我更推荐把默认编辑器改成 VS Code：

git config --global core.editor "code --wait"

配置文件的优先级是 system（全机器）小于 global（当前用户）小于 local（当前仓库）。也就是说，如果你在一个仓库里执行了不带 --global 的 git config user.name，它会覆盖全局配置，只对这个仓库生效。看当前仓库的实际生效配置，可以执行：

git config --list --show-origin

这个命令会告诉你每个配置项来自哪个文件，排查“为什么我的用户名没变”非常有用。

3.2 换行符与防乱码设置

安装时选过换行符，但我建议再把 core.autocrlf 显式写一遍，避免不同版本行为不一致：

git config --global core.autocrlf true

true 的意思是：提交时 CRLF 转 LF，检出时 LF 转 CRLF。这个值适合 Windows 单平台开发。如果你的项目成员全是 Linux，或者团队依靠 .gitattributes 管理，则可以不设这条，保持 false 或 input。

还有一个与中文密切相关的配置：

git config --global core.quotepath false

默认情况下，Git 会把非 ASCII 文件名转义成八进制序列，比如中文文件显示成 \346\226\207\346\241\243.txt。设置成 false 后，中文名会原样显示。这几乎是 Windows 中文用户的必设项。

再来几个顺手配置：

git config --global init.defaultBranch main git config --global color.ui auto git config --global alias.st status git config --global alias.lg "log --oneline --graph --all --decorate" git config --global alias.br branch

init.defaultBranch 让 git init 创建的主分支叫 main，而不是容易引发误会的 master。color.ui auto 让日志和 diff 输出有颜色。别名可以缩短常用命令，比如 git st 等价于 git status，git lg 能画出分支图，建议保存到配置文件里。

3.3 SSH 密钥生成与远程平台连接

推送代码到 GitHub、Gitee 或 GitLab 时，除了 HTTPS 密码登录，更推荐用 SSH 密钥。生成方法在 Windows 上很简单：

ssh-keygen -t ed25519 -C "你的邮箱@example.com"

一路回车，会在 C:\Users\你的用户名.ssh 下生成 id_ed25519（私钥）和 id_ed25519.pub（公钥）。用记事本打开 .pub 文件，把内容完整复制，然后登录代码托管平台，在 SSH Keys 设置里粘贴保存。

验证连接：

ssh -T git@github.com

首次连接会询问是否信任主机指纹，输入 yes。如果看到 “Hi xxx! You've successfully authenticated”，说明通了。

这里有个 Windows 特有的坑：Git Bash 使用的可能是 Git 自带的 ssh，也可能是 Windows 自带的 OpenSSH。可以用 where ssh 查看路径。如果之后出现权限问题，优先检查密钥文件路径是否在 ~/.ssh 下，以及公钥是否粘贴完整。

4. 常用命令速查：从入门到能干活

4.1 本地仓库生命周期

前面配置完成，现在开始接触命令。以“本地仓库”为主线，最基本的一套流程是：初始化、改文件、暂存、提交、看状态。

git init # 初始化仓库 git add README.md # 把文件加入暂存区 git status # 查看工作区与暂存区状态 git commit -m "first commit" # 提交暂存区内容 git log --oneline # 查看提交历史

git add 是把“修改”放上暂存台，git commit 是把暂存台的内容一次性“拍照”保存。你可以多次 add 后一次 commit，也可以一次 add 一个文件。想取消暂存但保留修改，用：

git restore --staged README.md

想彻底丢弃工作区里未暂存的修改：

git restore README.md

这个命令比较激进，它会用暂存区或 HEAD 的内容覆盖当前工作区，不可恢复。确认操作前先 git status 看清楚。

查看改动内容比看状态更重要：

git diff # 工作区与暂存区差异 git diff --cached # 暂存区与最后一次提交的差异 git diff HEAD # 工作区与最后一次提交的全部差异

这里要记住：git status 只告诉你“哪些文件变了”，git diff 才告诉你“具体变了什么”，排查 bug 时后者的价值更大。

4.2 远程仓库协作

拿到一个新的远端仓库，最常用的是克隆：

git clone git@gitee.com:yourname/example.git git clone https://github.com/yourname/example.git

克隆下来的目录会自动关联远端。如果你想给已有本地仓库配置远端：

git remote add origin git@github.com:yourname/example.git git remote -v # 查看远端地址

推送和拉取的常规流程：

git push -u origin main # 首次推送，并记录上游分支 git push # 之后直接推送 git pull # 拉取远端并合并（fetch + merge） git fetch # 只拉取，不合并 git merge origin/main # 手动合并拿到的远端分支

第一次 push 用 -u 是为了告诉本地分支“我的默认上游是 origin/main”，后面就能直接 git pull / git push，不用反复指定远端。

如果远端地址换了：

git remote set-url origin git@github.com:new/nrepo.git

想删除远程分支：

git push origin --delete old-branch

4.3 分支合并与冲突解决

分支操作是 Git 日常的核心。切换分支和新建分支在 Git 2.23 以后有更清晰的语法：

git switch feature # 切换到已有分支 git switch -c feature/login # 新建并切换到新分支 git branch # 查看本地分支 git branch -vv # 查看分支与上游的对应关系

老一点的教程会用 git checkout -b，和 git switch -c 效果一样。switch 语义更明确，新手可以直接用它。

把分支合回主分支的经典流程：

git switch main git merge feature/login git branch -d feature/login

如果被合并的分支已经删除，-d 就能确认删除；如果分支还没合并，-d 会拒绝，你需要 -D 强制删。强制删除要谨慎，除非你确定不要这个分支的内容。

合并时最怕的是冲突。当两个分支修改了同一行，Git 无法自动决定保留谁，会把冲突标记写进文件：

<<<<<<< HEAD 当前分支内容 ======= 待合并分支内容 >>>>>>> feature/login

你手动编辑文件，把 <<<<<<<、=======、>>>>>>> 这些标记删掉，留下最终想要的代码，然后：

git add 冲突文件 git commit

这就完成了冲突解决。不要想着机器自动解决所有冲突，人工过一遍内容永远是最稳妥的。

4.4 撤销、暂存和日志恢复

手滑是常态。改错了想放弃、提交错了想撤回，你需要一套撤销工具包。

先看暂存相关。手头做了一半的改动不想提交，可以先藏起来：

git stash push -m "wip" git stash list git stash pop

stash 会把工作区和暂存区的改动藏到一个栈里，pop 会恢复最近一次。注意 pop 时如果工作区已经改动了同一个文件，也会出现冲突，处理方式和分支冲突一样。

再看提交历史修正。想改最近一次提交的信息：

git commit --amend -m "new message"

如果刚才 commit 漏了一个文件，可以先 git add 那个文件，再执行 git commit --amend --no-edit，这样能补进上一次提交而不改提交信息。这里要注意：amend 会改写 commit 记录，如果这个提交已经推送到公共远端，不要再使用。

更深层的恢复工具是 reflog。每次操作都会在本地记录 HEAD 的移动轨迹：

git reflog

假设你 git reset --hard 上错了，可以通过 reflog 找到之前的提交号，然后：

git reset --hard HEAD@{2}

reflog 默认保留 90 天，是误操作的最后一道保险。

管理 reset 的三个模式，可以对照看：

如果你已经产生了需要保留历史的“后悔操作”，更推荐 revert：

git revert <commit>

它会在当前分支生成一个“反向提交”，不会改写历史，适合公共分支。

5. 实战示例：用一条真实场景串起来

5.1 从零初始化并完成第一次分支合并

场景：你在本地新建一个项目，想接入 Git，然后开分支做功能，再合并回主分支。

打开 Git Bash，进入项目目录：

mkdir hello-git cd hello-git git init

新建一个说明文件：

echo "# Hello Git" > README.md git add README.md git commit -m "init project"

提交成功后，查看当前分支和文件状态：

git branch git status

然后开一个功能分支：

git switch -c feature/login echo "login module" > login.py git add login.py git commit -m "add login module"

回到主分支，查看历史，再合并：

git switch main git log --oneline --graph --all git merge feature/login git branch -d feature/login

这时用 git lg 看分支图，会看到 main 分支的记录是线性的，因为 feature 分支是从 main 最新点分出去的，合并时 Git 默认走 Fast-forward，直接把 main 快进到 feature 的位置。如果 feature 分支提交之前 main 又有新提交，就会产生一次真正的 merge commit。

5.2 模拟一次冲突并解决

两个人同时改了同一个文件，是团队协作里最常见的场景。我们本地模拟一下。

先在 main 分支上提交初始文件 main.py，内容是：

def hello(): return "hello"

然后开一个分支 feature/zhang，把返回改为 "hello zhang"，提交。再切回 main，把同一行改成 "hello wang"，提交。此时 main 和 feature/zhang 在同一个文件同一行都产生了新提交。

将 feature 合并进来：

git switch main git merge feature/zhang

Git 会提示：

CONFLICT (content): Merge conflict in main.py

打开 main.py，能看到：

def hello(): <<<<<<< HEAD return "hello wang" ======= return "hello zhang" >>>>>>> feature/zhang

手动把文件改成想要的内容，删掉所有冲突标记：

def hello(): return "hello from both"

然后：

git add main.py git commit -m "merge: resolve conflict"

到这里冲突解决完毕。我的经验是：解决冲突时不要只看自己所在分支，尽量把两边代码的上下文都读一遍。很多线上 bug 就是冲突解决时顺手删了对方的逻辑导致的。

5.3 克隆远端项目并推送自己的修改

现在模拟真正参与一个已有项目。

从远端克隆：

git clone git@gitee.com:yourname/example.git cd example

确认当前分支，然后基于最新 main 建自己的功能分支：

git switch -c task/update-readme

改完文件后提交：

git add README.md git commit -m "docs: update readme"

推送前先更新本地分支与远端同步：

git pull --rebase origin main

为什么推荐 pull --rebase？普通 pull 会产生一个 merge 提交，时间一长历史就变得复杂。用 --rebase 会把你本地未推送的提交“垫”到远端最新提交之后，历史更干净。如果 rebase 过程中出现冲突，解决完冲突后执行：

git add 冲突文件 git rebase --continue

最后推送：

git push -u origin task/update-readme

输出结果会显示远端仓库新增了一条分支。接下来你就可以在代码托管平台上发起合并请求，让团队其他人评审。

整个过程看起来步骤多，但拆开只有四件事：新建分支、改代码、同步远端、推送。熟练以后一分钟就能完成。

6. 常见问题与排查技巧实录

6.1 中文乱码：文件名、提交内容、记事本三连坑

很多 Windows 用户在 Git 里看到中文文件名显示成 \346\226\207\346\241\243.txt，这其实不是文件名被改坏，而是 Git 的转义显示。解决方法是：

git config --global core.quotepath false

设置完之后，重新执行 git status，中文就能正常显示。

Git Bash 窗口里如果提交信息的中文显示成乱码，可能是终端编码问题。在 Git Bash 窗口标题栏右键，选择 Options，把 Text 里的 Character set 改成 UTF-8。Windows Terminal 则默认使用 UTF-8，基本不会出现这个问题。

有人还会遇到系统记事本打开 UTF-8 文件中文乱码。新版 Windows 的记事本默认是 UTF-8 编码，如果打开旧的无 BOM 文件却被当成 ANSI 读取，就会乱码。实际处理时，可以在“编码”下拉菜单里手动选择 UTF-8，或者把文件另存为带 BOM 的 UTF-8。对 Git 项目来说，更推荐用 VS Code 这类专业编辑器，并统一给文件配置好编码。

6.2 提交时遇到一长串 git -c 开头的命令

使用 VS Code 或其他 IDE 提交时，你有时会在 IDE 的输出面板看到类似这样的命令：

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks push -u origin main

这不是异常，而是 IDE 为了控制 Git 行为附加的临时配置。它实际等于在命令行里临时设置了几个配置项：core.quotepath=false 关闭中文转义，diff.mnemonicprefix=false 让 diff 前缀更简洁，--no-optional-locks 避免后台操作给仓库加锁。你在命令行里也可以这样用：

git -c core.quotepath=false status

这里的 -c 只是“本次命令临时覆盖配置”，不会修改你的全局配置，很安全。

6.3 fatal: unable to access SSL certificate problem

Windows 下访问 HTTPS 远端仓库时，有时会报：

fatal: unable to access 'https://...': SSL certificate problem: unable to get local issuer certificate

大多是系统根证书库不完整，或者某些企业网络对 TLS 加密做了二次封装。排查思路分几步：

1. 先确认远端地址是否写对，浏览器能打开不一定代表命令行能直接访问。
2. 如果本地仓库使用的是自签名证书或内网证书，可以考虑让 Git 使用 Windows 证书库：

git config --global http.sslBackend schannel

这是让 Git 调用 Windows 原生证书库，而不是 OpenSSL 的自带库。很多内网环境下，这个配置能直接解决证书不识别问题。

3. 不要一上来就执行 http.sslVerify false，那等于永久跳过所有证书校验，非常不安全。除非你是临时验证，用完立刻改回 true。

如果你的远端在海外而访问不稳定，更务实的做法是把远端仓库也托管一份到国内代码托管平台，在本地把远端地址切换到那份上。这样既不牺牲安全，也能改善访问体验。

6.4 fatal: detected dubious ownership in repository

Git 2.35.2 以后增加了安全检查。Windows 下有时打开某个路径下的仓库会报：

fatal: detected dubious ownership in repository at 'D:/projects/xxx'

原因是 Git 检测到仓库目录的所有者与当前用户不一致，比如从压缩包解压出来的目录、从同事那里拷贝的项目、或者是通过某些云盘同步来的目录。

正确做法是把目录加入安全白名单：

git config --global --add safe.directory D:/projects/xxx

如果你确定这台机器上所有 Git 仓库都由你个人管理，也可以一次性配置：

git config --global --add safe.directory '*'

但我不建议在共用机器上这么做，安全保护有它存在的意义。逐个添加受影响目录更稳妥。

6.5 换行符导致的“全文件 diff 风暴”

Windows 用户经常遇到一个奇怪现象：自己只改了一行代码，git diff 却显示整个文件几百行全部被修改，甚至每行末尾都出现 ^M。这不是代码真的全变了，而是换行符从 CRLF 变成了 LF 或者反过来。

最根本的解决方案是把换行符规则写进版本库。在仓库根目录创建 .gitattributes 文件，内容可以这样写：

* text=auto *.sh text eol=lf *.bat text eol=crlf *.cmd text eol=crlf *.png binary *.jpg binary

第一行表示文本文件统一由 Git 自动判断换行符；第二行强制脚本文件在仓库内和工作区都用 LF；第三四行让 Windows 批处理保持 CRLF；二进制文件明确标记为 binary，避免 Git 尝试处理。

提交 .gitattributes 后，需要一次性纠正仓库里已有的换行符：

git add --renormalize . git commit -m "normalize line endings"

这个命令会按新规则重新规范化所有文件的换行符。它只会影响换行符，不会动文件内容。建议团队在项目初始化阶段就把 .gitattributes 加上，越早代价越小。

6.6 误操作后如何恢复到某个历史状态

最后再来一条兜底技巧。假设你在分支上开发了三天，昨天一个 git reset --hard 把所有工作区改动清掉了，心态快崩了。先别急，在 Git 里大部分操作都能救回来。

第一步，用 reflog 看所有历史：

git reflog

输出里每一行是一个历史标记，形如 HEAD@{0}、HEAD@{1}。找到你想要的提交，比如三小时前那个 HEAD@{2}，然后：

git reset --hard HEAD@{2}

reflog 是本地的操作日志，只要你没有清理过 Git 的回收机制，这个回退操作通常能成功。但如果改动从没被 add 或 commit 过，reflog 也帮不了你，因为没有提交就没有恢复依据。

这也是我一直提醒自己的习惯：可以把一个功能的改动拆成多次小提交，宁可多 commit，不要长时间攒着不提交。

.gitattributes 我提了两次，这里再重复一次：它是我在 Windows 环境里最推荐的团队级配置文件。花十分钟写好它，能避免无数个换行符引发的假冲突。最后再分享一个小技巧：在 PowerShell 里装一个 posh-git，你的命令行提示符会直接显示当前分支、是否有未提交改动，日常操作会顺手很多。