企业官网建设流程全解析

如果你跟我一样，经历过电脑里堆满“项目最终版”“项目最终版2”“项目最终版改改改”这种文件的阶段，应该能体会一个分布式版本控制工具到底有多重要。Git 就是目前全球使用最广的版本控制工具，它不只是帮你把代码历史存下来，更关键的是让多人协作时不再互相覆盖、不用反复传压缩包、所有改动都有据可查。这篇文章写给刚接触 Git 或者装了 Git 但一直没搞懂怎么用得顺手的同学，我会从安装讲起，把日常最高频的命令、容易踩的坑、以及最近很多人搜的 git commit --amend 和 Gitee 密钥配置都捋一遍，保证你能照着操作，少走弯路。

1. 为什么需要Git：版本控制的本质与分布式优势

1.1 从“另存为”到真正的版本控制

很多刚开始写代码的人会觉得，我每次改完都把代码备份一个文件夹，不就是在做版本控制吗？说实话，我在刚开始写项目的时候也这么干过。问题是，代码项目不像文档，一个项目可能有几十个文件，你不可能每次都把整个目录复制一遍。就算你真的复制了，过两周后你自己都记不清“v3”和“v4”到底差在哪里。更尴尬的是，两个朋友同时改了同一个文件，最后谁先保存，谁就把对方的内容覆盖掉了。

Git 解决的就是这件事。它把你每一次有意义的改动记录成一个“提交”，每个提交都带着时间、作者、改动说明，你可以随时回到任何一个历史节点，也可以把两条不同的开发线合并在一起。这些操作都在本地完成，速度很快，不依赖网络，所以哪怕你在飞机上、在高铁上，一样可以提交代码，回到有网的地方再推送到远程仓库。

1.2 分布式与集中式的本质区别

如果你之前用过 SVN 或者 TFS，你会熟悉“集中式”的概念：代码集中存放在一台服务器上，每个人需要先“检出”文件，改完再“提交”回去，如果网络断了，很多操作都做不了。

Git 不一样，它是分布式版本控制工具。这个概念听起来有点玄，其实说白了就是：每个人电脑上都有一个完整的仓库，不只是当前文件快照，而是包含全部历史的全量备份。也就是说，就算远程服务器挂了，任何一个人的本地仓库都能把项目恢复出来。这一点在实际工程里救过很多次命，我遇到过公司内网 Git 服务器硬盘损坏，最后靠同事的本地仓库完整恢复了项目。

因为是分布式设计，分支的成本也极低。你在 SVN 上拉一个分支可能要考虑服务器压力，在 Git 上建分支就是一个指令的事，所以大家可以放心地按功能分、按版本分、按实验分，这也就衍生了后面各种成熟的分支协作模型。

2. 安装Git：各平台下的完整步骤与验证

2.1 Windows系统安装Git（含下载与配置）

Windows 下装 Git 最常规的方式就是去官网下载安装包，安装过程一路点“Next”其实也能用，但我建议你注意几个选项，免得后面用起来别扭。

第一次安装时，在“Adjusting your PATH”这一步建议选“Git from the command line and also from 3rd-party software”，这样 Git 的命令不仅能在它自带的 Git Bash 里用，也能在 PowerShell、CMD 里直接调用。默认编辑器我通常选“Use Visual Studio Code（默认）”，如果没装 Vs Code 就选 Nano 或者 Vim 也行，不过新手用 Vs Code 会更直观。行结束符转换那个选项，Windows 下我一般选“Checkout Windows-style, commit Unix-style line endings”，这样团队里不同系统的同学协作时不容易出现整文件被改动的情况。

安装完成后，打开 PowerShell 或者 CMD，输入 git --version，看到类似 git version 2.45.1 的输出就说明装好了。这时候还可以顺手确认一下其他基础命令：git config --list，如果没报错，说明环境没问题。

2.2 macOS和Linux系统安装Git

macOS 上如果你装了 Homebrew，一条命令就能搞定：

brew install git

如果没装 Homebrew，也可以下载官方 pkg 安装包，或者用 Xcode Command Line Tools 附带提供的 Git。我个人的习惯是用 brew，因为后续升级也方便。

Linux 用户根据发行版不同，Debian/Ubuntu 用：

sudo apt update && sudo apt install git

CentOS/RHEL 系的用：

sudo yum install git

或者新版系统用 dnf。装完之后同样去验证 git --version。这里多说一句，很多云服务器默认自带了 git，但版本可能比较老，如果你需要更丰富的功能（比如更优雅的分支提示），建议还是装一下官方源里的新版。

2.3 安装后的全局配置：你的第一张“名片”

Git 的提交会记录作者信息，所以安装完第一件事就是告诉 Git 你是谁。这里不是注册账号，只是在本地配置：

git config --global user.name "你的名字" git config --global user.email "your@email.com"

注意，这个 email 不一定非要和 GitHub/Gitee 的账号邮箱一致，但建议保持一致，这样远程平台能把提交记录关联到你的账号上。用git config --global --list可以检查配置是否生效。

我也见过有人忘记配置就直接提交，结果 Git 会默认用你的系统用户名加上一串无序的后缀当作提交者，后面在代码平台上看历史记录非常痛苦，别人根本不知道是谁提交的。所以这一步千万不能省。

3. 核心日常操作：从仓库初始化到提交、分支与撤销

3.1 创建仓库并完成第一次提交

假设你已经有一个项目文件夹，比如叫 myapp，进入这个目录后执行：

git init

这会创建一个隐藏的 .git 目录，里面就是 Git 用来管理版本的数据库。此时项目还没有任何文件被跟踪，你可以用git status看到当前状态，通常会显示一堆未跟踪的文件。

接下来需要先暂存文件，再提交：

git add . git commit -m "init project"

git add .会把当前目录下所有未跟踪、有改动的文件加到暂存区；git commit则把暂存区的内容固化成一个版本。很多人刚开始会混淆这两个动作。我会打一个比方：git add是把自己要寄出的东西收拾好装进快递袋，git commit是填写快递单并寄出。快递袋里到底放了什么，在 commit 之前你都可以随时调整。

提交之后再用git log --oneline能看到一条简洁的提交记录，比如e3a21b0 init project，说明仓库已经正式运转起来了。

3.2 分支管理：并行开发不再互相踩脚

分支是 Git 最强大的功能。为什么需要分支？举个例子：你的项目已经稳定在 v1.0 了，这时候想开发一个 v2.0 的大功能，但它可能要做很久、改动很大，你又不想影响正在线上跑的 v1.0。此时可以开一条新分支：

git branch dev-v2 git checkout dev-v2

或者更省事地一条命令：

git checkout -b dev-v2

这条命令相当于“创建分支并切过去”。在 dev-v2 上改代码、提交，完全不会影响主分支。等开发完成、测试通过，再切回主分支合并：

git checkout main git merge dev-v2

合并的时候可能产生“冲突”，原因通常是两条分支改了同一个文件的同一行。Git 会在冲突文件里用<<<<<<<和>>>>>>>标记双方的改动，你需要手动修改成最终想要的内容，然后保留这些标记，再重新git add和git commit。我第一次遇到冲突时很慌，后来发现其实就是打开文件仔细看两边内容，删掉不需要的，只保留正确结果，完全不可怕。

3.3 修改提交记录：git commit --amend 的正确用法

最近搜这个问题的人特别多，因为提交完之后发现自己写了错别字，或者忘了把某个文件加进去，再或者提交信息写得像“啊啊啊”，想改掉。git commit --amend就是用来“修补”最近一次提交的。

最常见的场景是我刚提交完，发现少加了一个文件：

git add README.md git commit --amend --no-edit

--no-edit表示保留原来的提交信息，只是把新增内容补进去。如果你想顺便修改提交信息，直接：

git commit --amend -m "修正后的提交信息"

这个命令会把最近一次提交“重写”成新的提交，原来的记录被替代，Git 会生成一个新的提交哈希值。

但这里有个特别重要的注意事项：git commit --amend只能改“还没有推送”的提交。如果你已经把这次提交推送到了远程仓库，其他人也基于它工作了，这时候再用 amend 改写历史，会导致别人的本地历史和远程历史对不上，后面 pull 会出现一堆冲突。遇到这种情况，更安全的做法是新增一个提交，在提交信息里说明“修正上一步”。如果你确实需要调整多条历史提交，那就得用交互式 rebase：git rebase -i HEAD~n，但那属于进阶操作，新手不建议一上来就用。

3.4 撤销操作：三个“后悔药”怎么选

Git 里撤销方式很多，新手最容易懵，我自己也踩过不少坑。我按场景给你分清：

• git checkout -- 文件名：把某个文件在工作区的改动全部丢弃，回到最近一次提交的状态。适合改了半天发现改错了，想彻底还原。
• git reset HEAD~1 --soft：撤销最近一次提交，但保留改动内容在暂存区。适合提交完突然发现还有其他方西要一起放进去，又不想新增一条提交时用。
• git reset --hard HEAD~1：撤销提交并丢弃所有改动。这个要慎用，因为丢弃的内容无法直接恢复。
• git revert <commit>：反向生成一个新提交，用来“撤销”某个历史提交的改动，但不会删除历史记录。适合已经推送到远程仓库的提交。

我对新手的建议是，在还没有完全熟悉仓库机制之前，尽量少用--hard，因为那相当于把工作区、暂存区、本地仓库全部强制重置，万一你有些代码并没有完整备份，那损失是很大的。

4. 远程仓库协作：Gitee密钥配置与推送

4.1 配置Gitee的SSH密钥（从生成到验证）

很多人直接把代码托管到 Gitee（国内代码托管平台）或 GitHub，这样既方便备份，也方便和同事协作。用 SSH 比用 HTTPS 省心得多，至少推送时不用每次都输密码。下面以 Gitee 为例。

生成 SSH 密钥：

ssh-keygen -t ed25519 -C "your@email.com"

一路回车，默认会在用户目录下生成一对密钥：~/.ssh/id_ed25519和~/.ssh/id_ed25519.pub。公钥是给别人看的，私钥自己保留，千万别泄露。

然后查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制输出的整行内容，打开 Gitee 网站 → 个人设置 → SSH 公钥 → 添加公钥，粘贴进去保存。添加完之后验证：

ssh -T git@gitee.com

如果看到 Hi 你的用户名，说明密钥配置成功。这里有个容易出错的地方：如果你以前生成过密钥，重装系统后使用的不是老电脑的私钥，而是新生成的私钥，同时 Gitee 上还留着老公钥，就会报权限错误。所以每次重装系统，都要记得去平台删掉旧公钥、重新配置。

4.2 连接远程仓库并推送拉取

在 Gitee 上新建一个空仓库，拿到仓库的 SSH 地址，然后绑定到本地：

git remote add origin git@gitee.com:你的用户名/myapp.git git push -u origin main

-u的含义是第一次把本地 main 分支和远程 main 分支建立关联，之后直接git push就行。后续如果你在本地新建了 dev 分支，想把它推到远程：

git push origin dev

拉取远程更新一般用git pull。这里我习惯先git fetch再看git diff，确认无误后再git merge。因为git pull相当于 fetch + merge，有时候远程更新会打乱我本地未提交的改动，分两步做能多一层缓冲。

4.3 被很多IDE “藏起来”的命令参数：git -c 系列详解

很多同学在用集成开发环境（比如 Android Studio 或 VS Code）操作 Git 时，经常会在控制台看到一长串命令，里面有：

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks ...

这串命令看起来像“天书”，其实就是 Git 运行时的一些临时配置。git -c可以理解为不修改配置文件，只对这一次命令临时设置某些参数。

diff.mnemonicprefix=false表示 diff 中的前缀不使用 a/ 和 b/ 这类简短助记符，而是直接显示源文件与目标文件的路径，IDE 里这样处理是为了让差异展示更直观。

core.quotepath=false很实用，它的作用是关闭 Git 对非 ASCII 文件名的转义。如果不设置，你的中文文件名会显示成类似\346\265\213\350\257\225.txt的八进制编码，看着非常头疼。在命令行里执行一次git config --global core.quotepath false，以后中文文件名就能正常显示了。

--no-optional-locks的意思是禁止 Git 在执行只读命令（比如 status、diff）时获取额外的文件锁。多进程并发运行时可以避免一些临时锁导致的等待问题。这些参数你不需要死记硬背，但理解它能帮你以后在遇到 IDE 输出命令时，知道 Git 正在做什么，从“看着害怕”变成“原来如此”。

5. 我的Git实操心得与常见问题排查

5.1 几个容易踩的坑：中文乱码、大文件、提交信息

先说中文乱码。如果你的仓库里出现了中文文件名，而且命令行里看到的是转义序列，别慌，执行：

git config --global core.quotepath false

改完之后，git status和git log里就能正常看到中文路径了。如果是提交信息里的中文显示乱码，可以再补充设置git config --global i18n.commitencoding utf-8，但仓库本身采用 UTF-8 编码是前提。

再说大文件。很多人不看提示，把编译产物、依赖包、视频素材直接提交进去了，结果仓库体积迅速膨胀，后面每次拉取和推送都变得很慢。正确的做法是新建一个.gitignore文件，把不需要版本控制的目录和文件写进去，比如：

node_modules/ dist/ *.log .DS_Store

如果你已经误提交了大文件，可以在网上搜一下“git filter-repo”的历史清理方法，但那种操作会影响整个仓库历史，如果仓库已经被推送到远程，务必提前和团队沟通。

5.2 常见问题速查表

下面这张表是我平时总结比较多的场景，也许不完整，但覆盖了新手最容易遇到的几类问题。

这些解决办法只要你照着做一遍，基本都能顺利解决。如果遇到其他报错，建议先阅读命令行给出的英文提示，Git 的报错信息其实相当明确，很多人只是没耐心往下看。

5.3 给新手的工作流建议

看到这里，你是不是已经想马上建仓库试试了？那就试。我的实操体会是，Git 这种东西，光看命令记忆效果很差，真正练习一遍之后，很多命令会内化成肌肉记忆。为了让你少走弯路，我给你几个最具体的小建议。

第一，提交频率要适度。不要一行改动就提交，也不要攒一周才提交。我自己的标准是：一个完整的小功能、一次 bug 修复、或者一次重构，就是一个提交。提交信息尽量写清楚动机，比如“修复登录页在移动端溢出”，而不是“update”。

第二，永远不要直接往 main 分支上乱推。哪怕只有你一个人开发，也建议先开一个dev分支或者功能分支，稳定之后再合并。这个习惯能让你以后进入团队协作时非常自然。

第三，善用git log --oneline --graph。这个命令可以一直查看提交历史的树状结构，看到每个分支的走向。如果你发现历史乱成一团，往往说明分支操作逻辑需要调整。

另外，我可以分享一个我个人的小技巧：每天开始写代码前，先git pull拉取远程最新代码，每天结束前，把当天改动提交并推送。这样就算第二天不小心改坏了，也能靠 reset 回到昨天状态，非常安心。

最后再说一句，Git 不像某些工具需要背一堆“快捷键”。把一个命令拆开看，重点就是三个对象：工作区、暂存区、仓库。想清楚改动目前“在哪一步”，需要让它“去哪一步”，命令自然就理解了。希望这篇文章能帮你真正把 Git 用起来，之后代码备份、协作、复盘历史，都会变成一件轻松的事。