企业官网建设流程全解析

在设计师的日常工作中，最让人抓狂的往往不是灵感枯竭，而是文件命名。

“首页设计_最终版_v12_真最终版_打死也不改版.sketch”，这样的文件名是不是很眼熟？更常见的是：需求今天改一版、明天回退一版、后天又要“按上周那版改”。如果你还在靠不断复制文件夹来保存版本，那么这篇 Git 教程就是为你准备的。

“Git for Designers” 这个概念并不是让设计师去学整套编程知识，而是把 Git 当作一个可靠的设计文件版本管理工具。程序员用它管理代码，我们也可以用它管理 Sketch、Adobe XD、Figma 本地导出文件、设计规范文档，甚至设计 Token 配置。

这篇文章会从为什么需要 Git 讲起，接着带你完成 Git 安装、基础配置、SSH 免密、日常提交与分支合并，最后给出设计师常用的版本管理办法和常见报错排查思路。无论你是 UI 设计师、UX 设计师，还是设计团队的技术对接人，都能按步骤操作下来。

1. 设计师为什么需要 Git：从“最终版 V12”说起

1.1 设计文件版本管理的真实痛点

先举一个很常见的例子。你在做一套 App 界面改版，源文件叫shop_home_v10.sketch。今天改完配色，另存为shop_home_v11.sketch；明天产品说不行，改回旧风格，你又备份一版shop_home_v11_backup.sketch；到了周五，你已经分不清v11_backup和v12_final哪个才是给开发用的版本。

这不仅仅是命名混乱的问题，更关键的是历史版本之间缺少可追溯的关系。你很难回答“这个配色是什么时候改的”“这批切图对应哪一版设计稿”。使用网盘协作虽然能覆盖文件，但当多人同时编辑同一份设计稿时，后保存的人会覆盖先保存的人，一旦覆盖错了，找回成本非常高。尤其是设计源文件体积大，网盘的“历史版本”功能往往有数量或天数限制，过期版本可能直接不可恢复。

Git 解决的核心问题就是：让每一次变更都有记录，让每个版本都能找回，让多人协作不互相覆盖。它并不关心你管理的是代码还是设计稿，它只把一个目录下的所有文件变化记录下来，并通过“提交”形成一条清晰的历史时间线。只要你的设计源文件放在 Git 仓库里，每一次存档、每一版修改都会留下可回溯的记录。

1.2 Git 是什么，它对设计师意味着什么

从专业角度说，Git 是一个分布式版本控制系统（Distributed Version Control System，DVCS）。它最初由 Linux 创始人 Linus Torvalds 在 2005 年开发，用来管理 Linux 内核这种超大规模代码仓库。它的特点是：每个开发者本地都有一份完整的仓库副本，不需要服务器一直在线也能提交版本。

对设计师来说，可以把它理解为“加强版的图层历史记录”。在 Sketch、Photoshop、Figma 里，你可以撤销最近几步操作，但很难回到十几天前的某个状态。Git 能把整个项目目录“快照”下来，任何时候都能回到任意一次提交。

和设计工具自带的“备份”或网盘的“历史版本”相比，Git 的优势在于：

• 完整历史：每次提交都记录了提交人、时间、说明和具体变更内容，团队协作时有据可查。
• 并行不冲突：每个人在独立分支上工作，完成后合并，互相不干扰，不用再等别人“锁文件”。
• 本地优先：即使网络断开，本地提交、查看历史、回滚照样可用，不会因为服务器波动而丢失记录。
• 团队协同：配合 GitLab、GitHub、Gitee 等平台，可以实现设计稿评审与留痕，每个版本都有责任人。

1.3 设计师适合用 Git 的场景

并不是所有设计工作都适合立刻切换到 Git。下面这些场景使用 Git 收益最大：

1. 设计系统维护：设计系统的组件、色彩规范、字体规范通常会以源文件和 Token 形式存在，版本变化频繁且需要团队对齐，Git 能记录每一次规范变更。
2. 团队协作设计稿：多人同时推进一个项目，不想用网盘互相覆盖，每个人在独立分支上工作，最后合并评审。
3. 需要和开发保持同步：设计稿的版本号、提交说明可以直接和代码仓库关联，设计变更记录清清楚楚，开发能快速定位“这一版改了什么”。
4. 探索性设计：需要并行验证“方案 A”和“方案 B”，同时保留主线的稳定版本，分支机制天然适合这种场景。

如果你的工作是零散的单张海报、概念稿，且不需要长期回溯，使用网盘或 Figma 的版本历史可能更轻量。Git 更适合“像项目一样被持续维护的设计资产”，也就是那些需要反复迭代、多人协作、长期留痕的设计文件。

2. 核心概念：先用设计师熟悉的语言理解 Git

2.1 仓库、工作区和版本库

Git 的核心概念不多，但只要理解了它们，后面的命令就顺理成章。

一个 Git 仓库（Repository，简称 repo）就是一个被 Git 管理的项目文件夹。首次在这个文件夹执行git init后，Git 会创建一个隐藏的.git目录，里面存放版本历史和配置。注意，.git目录不要手动改，一旦损坏，历史记录就可能丢失。

在 Git 视角下，项目文件有三个区域：

• 工作区（Working Directory）：你电脑上看到的、正在编辑的文件目录。
• 暂存区（Staging Area / Index）：准备提交到版本库的“待提交清单”。
• 版本库（Repository）：已经提交的历史版本存储位置。

对应到设计师的操作：你打开设计稿改了两笔，文件处于工作区；你想把“改了两笔”这个状态记录到版本库，就要先执行git add把文件加入暂存区，再执行git commit正式提交。只有提交成功，这次改动才会形成历史版本。

用设计工具来类比：工作区就像你画布上正在编辑的内容，暂存区像你准备导出存档的图层组，版本库则是已经导出的历史文件库。理解这个流程后，你就明白为什么 Git 教程经常会提到add和commit这样两个容易混淆的命令。

2.2 提交、分支与合并

提交（Commit）是 Git 最重要的操作。每次执行git commit -m "修改首页按钮配色"，都会生成一条带编号（哈希值）、提交人、时间和说明的历史记录。你随时可以通过这些记录回到过去任意版本。

分支（Branch）则是从某个提交分出来的“平行世界”。你可以在main主线旁边新建一个feature/new-homepage分支，安心尝试新配色、新布局，完全不影响主线。等确认方案可行，再把分支合并（Merge）回主线；如果方案被否，直接丢弃分支即可。

对于设计师来说，分支最实用的场景是“同时推进多个备选方案”。比如三个不同方向的首页改版，各自开分支推进，评审后再决定合并哪个。这比维护五份_v13、_v14、_v15文件夹清晰得多，也不容易弄混“哪个分支对应哪个方向”。

合并时可能会产生冲突（Conflict）。在代码世界里，Git 可以自动合并文本差异；但在设计场景中，二进制文件发生冲突时，通常需要人工确认“到底保留哪一版”。这不算 Bug，而是 Git 在提醒你：两边改了同一个文件，需要你来做决策。

2.3 Git 与常见云端协作平台的关系

Git 本身是一个工具，而实际团队协作往往需要“远端仓库”。常见的 Git 云端平台有 GitHub、GitLab、Gitee（码云）等。在团队内部，GitLab 通常承担了代码托管、评审、权限控制等职责，很多公司的设计资源和开发代码都存放在同一个 GitLab 上。

使用流程一般是：本地提交版本，然后通过git push推送到远端仓库；其他人通过git pull拉取最新版本；需要参与项目时，先git clone克隆一份到本地。这个过程本质上和你在设计协作平台上传、下载、校稿类似。Git 远端仓库就相当于团队项目文件的“共同服务器”，本地电脑则是你的“草稿箱”。

3. 环境准备：Windows / macOS 安装 Git

在开始使用之前，需要先把 Git 装好。下面分别说明 Windows 和 macOS 的安装方式。本文示例以 Git 2.x 版本为参考，具体版本请以官方 git-scm.com 下载页或仓库说明为准，不同小版本的操作基本一致。

3.1 Windows 安装 Git

Windows 安装 Git 最标准的方式是访问https://git-scm.com/download/win，下载 64 位安装包。如果官网下载速度较慢，可以使用学校或企业内部的软件镜像源，注意选择正规渠道，避免下载到捆绑软件。

安装过程中有几个选项需要留意：

1. 安装路径：不建议包含中文或空格，例如D:\Git，可以减少后面的环境变量问题。
2. 默认编辑器：建议选择 VS Code 或 Notepad++，后续需要手动编辑提交信息时会更方便。
3. PATH 环境变量：选择 “Git from the command line and also from 3rd-party software”，这样 PowerShell、CMD 以及第三方软件中都能直接使用 git 命令。
4. 行尾转换（Line Ending Conversion）：一般保持默认的 “Checkout Windows-style, commit Unix-style line endings”，团队协作时可以减少换行符问题。

安装完成后，可以在“开始菜单”里找到 Git Bash。Git Bash 提供了类似 Linux 的终端环境，命令风格一致，对新手比较友好。如果安装后仍然提示“git 不是内部或外部命令”，或者 PowerShell 中提示“无法将 git 项识别为 cmdlet”，通常是因为 PATH 配置没有生效，可以重启终端后再试，不行就手动添加 Git 的bin目录到系统 PATH。

Windows 上还可以安装小乌龟（TortoiseGit）作为资源管理器右键菜单的图形客户端。它能把 Git 操作变成鼠标右键菜单，适合不太习惯命令行操作的设计师。小乌龟本质上是调用 Git 命令，所以先安装 Git 本体是必须的。

3.2 macOS 安装 Git

macOS 上最简单的方式是通过 Homebrew 安装：

brew install git

如果没装 Homebrew，也可以在 Git 官网下载 macOS 安装包，按向导安装。新版 macOS 首次运行 git 时可能提示需要安装 Command Line Tools，按系统引导安装即可。

macOS 上也可以使用图形客户端，比如 Fork、Sourcetree、GitKraken 等，它们能显示分支图、历史记录，降低新手的上手难度。不过无论用哪个客户端，底层命令都是一样的，掌握命令行之后切到任何工具都不会懵。

3.3 验证安装

无论哪种系统，安装完成后都建议先确认 Git 可用：

git --version

输出类似：

git version 2.39.3 (Apple Git-146)

不同系统、不同版本输出可能不一样，只要能看到版本号，就说明 Git 已加入系统 PATH。如果提示command not found或不是内部或外部命令，就需要检查安装和 PATH 配置。

4. Git 基础配置

装好 Git 后，不要急着建仓库，先做两项基础配置：用户名和邮箱。

4.1 配置用户名和邮箱

每次提交记录都会带上user.name和user.email，用于识别提交人。如果是团队项目，建议使用公司邮箱；如果是个人项目，可以使用常用邮箱：

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

--global表示该配置对当前系统用户的所有 Git 仓库生效。查看当前配置：

git config --global --list

配置完成后，提交记录中会显示这些信息。要注意：如果用户名或邮箱拼错，提交历史也会跟着错，后期修改比较麻烦，所以刚开始就要一次配好。这个问题在新手期特别常见，团队里经常出现“明明提交了，但统计里看不到我的名字”，多数就是邮箱没配对。

4.2 HTTPS 方式配置账号密码

如果团队仓库使用 HTTPS 地址（形如https://gitlab.example.com/group/project.git），在git clone或git push时通常会要求输入账号密码。对于 GitLab 或 GitHub，推荐使用 Personal Access Token 作为密码，因为很多平台已经不再支持直接使用账户密码进行 HTTPS 验证。

第一次推送时，如果希望 Git 记住凭据，可以使用 Git 自带的 credential helper：

git config --global credential.helper store

store模式会把明文密码保存在~/.git-credentials文件中，适合个人电脑但安全性一般。更推荐的是使用 Git Credential Manager 或操作系统的凭据管理器，Windows 上可以配置：

git config --global credential.helper manager

macOS 上默认集成 keychain（钥匙串），安全性更好一些。这里的安全提示很重要：不要在公共电脑上使用store模式，否则其他人可能直接读取到你的账号密码或 Token。

4.3 SSH 免密配置

SSH 免密是团队协作中最常用的方式，配置一次之后，git clone、git push、git pull都不需要每次输入账号密码，这也是热搜词里“git 免密”最常指的内容。

第一步，生成 SSH 密钥。打开终端执行：

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

一路回车即可，默认会在~/.ssh/下生成id_ed25519（私钥）和id_ed25519.pub（公钥）。密码短语如果设置，会在每次使用私钥时要求输入，个人电脑可以不设置。

第二步，查看公钥内容：

cat ~/.ssh/id_ed25519.pub

第三步，把这段以ssh-ed25519开头的字符串复制到 GitLab、GitHub 或 Gitee 的 “SSH Keys” 设置页面中。不同平台入口可能叫 SSH Keys、Deploy Keys 或 Access Tokens，作用都是把公钥绑定到账号。

第四步，测试连接。以 GitLab 为例：

ssh -T git@gitlab.com

看到类似Welcome to GitLab, @yourname!的提示，说明 SSH 免密配置成功。需要留意的是，不同云平台的主机名不同，GitLab 自建站可能是git@git.example.com，GitHub 是git@github.com。配置完成后，克隆地址优先选择 SSH 形式，例如：

git clone git@github.com:yourname/design-system.git

这里有个常见误区：SSH 密钥是“电脑 + 账号”维度的，如果你换了电脑，需要在电脑上重新生成密钥并加入平台。同一个账号可以配置多台电脑的公钥，不影响。

5. 设计师实战：从零开始管理设计稿

接下来进入实际操作。假设我们要用 Git 管理一套“设计系统”文件夹，里面包含设计源文件和规范文档。

5.1 创建并克隆仓库

先在本地创建一个项目文件夹：

mkdir my-design-system cd my-design-system git init

git init会在当前目录生成一个.git目录，此时项目已纳入 Git 管理，但还没有任何提交。

如果远程仓库已经存在，比如团队在 GitLab 上已经创建好了设计资源仓库，设计师可以用git clone把远程仓库拉取到本地：

git clone git@gitlab.com:yourteam/design-system.git cd design-system

git clone会自动完成“下载仓库 + 初始化本地仓库 + 配置远程地址”这几步，比手动init后关联远程要省事。

5.2 第一次提交：设计源文件入库

接下来我们把设计稿加入暂存区并提交。假设目录下有assets/design-system.sketch、docs/color-tokens.json。

先用git status查看当前状态，会看到这些未跟踪的文件。接着执行：

git add . git commit -m "init: 初始化设计系统源文件"

git add .表示把当前目录下所有未被忽略的文件加入暂存区；git commit则会生成一条提交记录。如果想提交指定文件，可以写：

git add assets/design-system.sketch git commit -m "update: 更新全局圆角规范"

注意：设计源文件通常是二进制格式，Git 会整体存储每次提交的内容差异，体积较大，后文会介绍 Git LFS 的优化方案。第一次提交后，可以用git log --oneline查看提交记录，能看到类似a1b2c3d init: 初始化设计系统源文件的一行信息。

5.3 分支与合并：并行推进设计稿

假设需求是首页改版。我们新建一个分支，在不干扰主线的情况下自由尝试：

git branch feature/homepage-redesign git switch feature/homepage-redesign

也可以合并为一条命令：

git switch -c feature/homepage-redesign

git switch是 Git 2.23 之后推荐使用的切换分支命令，比旧的git checkout更直观。-c表示创建新分支并切换过去。

在分支上修改文件并提交后，切回主分支，然后把该分支合并进来：

git switch main git merge feature/homepage-redesign

如果合并时报冲突，说明主分支和功能分支改动了同一个文件的同一部分。设计师场景下，二进制设计文件的冲突很难自动合并，通常需要人工确认哪一版是最终方案。此时不要慌，保留需要的版本后，使用git add和git commit完成一次合并提交即可。

如果最终决定放弃这个分支，只需要：

git branch -D feature/homepage-redesign

-D是强制删除分支，适合分支还没有被合并、但你确定不再需要的情况。如果分支已经合并过，使用-d会更安全，Git 会检查是否还有未合并的提交。

5.4 回滚设计稿：用 Git 找回历史版本

设计中最常见的需求是回退到历史版本。Git 提供了两种常用方式。

如果只是撤销工作区未提交的修改，使用git restore：

git restore assets/design-system.sketch

这条命令会把工作区文件恢复到最近一次提交的状态，相当于“扔掉还没存档的修改”。

如果已经提交到历史记录，但想回到某一个历史版本，可以先查看日志：

git log --oneline

输出类似：

a1b2c3d update: 更新全局圆角规范 e4f5g6h init: 初始化设计系统源文件

要回到e4f5g6h这一版，可以执行：

git reset --hard e4f5g6h

这里要特别提醒：reset --hard会丢弃当前工作区的未提交修改，并且会让提交历史“倒退”。如果改动已经推送到远程仓库，使用git push --force-with-lease强制推送时一定要和团队确认，最好不要直接操作公共分支，否则会覆盖其他人的提交。

更安全的回退方式是先基于历史版本创建新分支，确认后再合并。比如：

git switch -c restore-old-version e4f5g6h

这就相当于“先回到旧版做备选区，再决定是否采用”，不会破坏主线历史。

6. 设计文件在 Git 中的特有问题

6.1 二进制文件与 Git 的存储方式

代码文件是纯文本，Git 能一行一行地显示差异；但设计源文件如.sketch、.psd、.xd是二进制格式，Git 只能把它们当作整体快照存储，无法逐像素对比。这意味着：

• 每次修改后提交的体积可能接近整个文件的大小，仓库会快速膨胀。
• 合并冲突时往往只能二选一，不能自动合并两版设计。
• 评审体验不如文本 diff 直观，git diff对二进制文件基本帮不上忙。

所以设计师使用 Git 时，要养成“小步提交”的习惯：每次改动尽量保持单一目标，比如“更新首页按钮状态”，而不是攒到周末一次性提交。小步提交能让历史记录更清晰，也让回退成本更低。比如某个颜色调得不好，你只需要找到“调整主色”的那次提交，而不是在一大坨改动里翻找。

6.2 大文件与 Git LFS

Sketch、PSD 文件动辄几十 MB，甚至上百 MB，普通 Git 仓库上传和下载会非常慢，仓库体积也会快速膨胀。Git LFS（Large File Storage）是官方的解决方案之一。

开启 Git LFS 后，大文件的实际内容会被存储在远程 LFS 服务器上，Git 仓库内保存的是一个轻量指针文件。团队其他成员拉取代码时，会自动从 LFS 拉取真实文件。

brew install git-lfs # macOS git lfs install git lfs track "*.psd" git lfs track "*.sketch" git add .gitattributes git commit -m "chore: 使用 Git LFS 管理大型设计源文件"

之后*.psd、*.sketch这类大文件就会自动被 LFS 管理。需要提醒的是，LFS 需要远端仓库（GitLab、GitHub）支持，不同平台的免费配额不同，使用前最好和团队管理员确认。如果你刚接触 Git，建议先不要急着配置 LFS，等仓库明显变慢或体积过大时再引入，避免增加学习负担。

6.3 设计稿对比与评审流程

文本代码有 diff 工具，设计稿却没有办法完全没有对比方案。如果团队使用的是纯 Git 平台，评审设计稿通常依赖两种方式：

1. 在提交说明中尽量写明改动动机，例如“修改主按钮 hover 状态，颜色从 #3370FF 调整为 #2F54EB”，让浏览历史的人能快速理解设计意图。
2. 使用支持设计文件预览的托管平台，或结合在线设计工具，比如先在 Figma 的版本历史中评审，再把最终结果同步到 Git 仓库。这样 Git 仓库保存的是“已确认版本”，而不是中间的试探性过程。

如果你是团队里第一个推动 Git 落地的人，可以先从“设计 Token”和“文档规范”这类文本资产入手，因为它们 diff 起来最直观。当团队习惯 Git 的提交、分支、合并流程后，再逐步引入设计源文件。直接一步到位把大型 PSD 文件丢进 Git 仓库，容易在前期就让大家丧失信心。

7. 常见问题与排查清单

下面把 Git 使用中最高频的几个报错整理出来，按“现象—原因—解决思路”给出排查方向。这张表也可以作为团队入门培训的速查手册。