Git 版本控制入门：本地仓库、分支与团队协作基础

为什么站长也要学 Git

AI 示意图·以官网当前页面为准

Git 是最流行的分布式版本控制工具（官方定位：处理小到极大项目的分布式版本控制系统），对做网站和跨境业务的开发者，价值很直接：

• 改坏能回退：每次改动都有记录，出问题随时回到上一个可用版本；
• 多人协作不乱：各自分支开发，合并时统一处理冲突；
• 部署更稳：上线前先看 diff，改动可追溯。

就算只维护一个小站，把配置、脚本、主题放进 Git 仓库，也等于给代码上了「后悔药」。

核心概念一句话

本地仓库入门

初始化并在本地管理项目（以官方文档为准）：

1. 初始化仓库：在项目目录创建仓库，让 Git 开始跟踪文件；
2. 暂存与提交：把改动加入暂存区，再生成一次提交，写清改动说明；
3. 查看状态：随时看哪些文件改了、哪些还没提交；
4. 回退：提交记录里找到之前的版本，出问题可回退。

提示：提交说明写清楚「改了什么、为什么改」，历史可读性会好很多。

分支管理

AI 示意图·以官网当前页面为准

分支是 Git 协作的核心机制：

• 默认分支：仓库主线，通常叫 main（或旧习惯 master），以官方文档与平台规范为准；
• 功能分支：每件事开一条分支，做完再合并回主线，主线保持稳定；
• 切换分支：在不同分支间切换，改动互不干扰；
• 合并：把功能分支的改动合回主线，出现冲突时手动解决。

常见的「一条主线 + 多条功能分支」模式，适合小团队；更复杂的规范（如 Git Flow）按项目需要再引入。

远程协作

本地仓库 + 远程托管平台（GitHub、GitLab、Gitee 等，以平台规则为准）组合：

• 克隆：把远程仓库复制到本地，开始干活；
• 拉取：同步远端其他人的改动；
• 推送：把本地提交上传到远程；
• Pull Request / Merge Request：在平台发起合并请求，代码评审后再合入（以平台功能为准）。

小团队建议：主线受保护、改动走合并请求，review 后再上线，能明显减少「把坏代码推上去」的风险。

部署场景怎么用

对独立站/服务器场景，Git 的常见用法：

• 配置管理：Nginx 配置、脚本、部署文件都进仓库，改坏可回退；
• 自动化部署：服务器上用 git pull 拉取最新代码（配合 CI/CD 更规范）；
• 发布标记：每次上线打一个 tag（标签），出问题知道线上是哪个版本。

注意：数据库、密钥、大文件不要进仓库，敏感信息泄露很麻烦；密钥用环境变量或专门的密钥管理。

实用清单

常见问题

1. 新手最容易犯什么错？ 把密钥和数据库文件提交进仓库，以及提交信息写得看不懂；前者影响安全，后者影响协作效率。

2. 合并冲突可怕吗？ 不可怕，冲突只是同一处被两边都改了，手动保留正确版本再提交即可，以官方文档为准。

3. 一定要用 GitHub 吗？ 不一定，GitHub/GitLab/Gitee 等都是托管平台，选哪个看项目与团队习惯，以平台规则为准。

4. Git 和 SVN 什么区别？ Git 是分布式的，每个本地仓库都是完整副本；SVN 是集中式的，以官方文档为准。

官方资料

资料核对日期：2026-10-26

• Git 官网（项目介绍、文档与参考手册）：https://git-scm.com/
• Git 官方文档（Getting Started / Branching and Merging）：https://git-scm.com/doc
• Pro Git 电子书（Git 官方推荐教程）：https://git-scm.com/book/zh/v2