在设计圈摸爬滚打久了很多人都会遇到一个尴尬场景设计稿改了十几版桌面上的文件名从首页终版.fig一路变成了首页最终版_v12_真的不改了.fig最后自己也分不清哪一版才是交付给开发的那一版。平时我们做设计协作依赖的是 Figma、Sketch 这类在线工具的自动版本记录但一旦回到本地源文件、批处理脚本、切图资源、或者与开发同学共用的项目仓库就会立刻发现设计资产的版本管理其实一直处于“裸奔”状态。Git 并不仅仅是程序员的“代码存钱罐”。它的核心能力是追踪文件的每一次变化、支持多人并行修改、随时回退到任意历史版本。这套逻辑对于设计师管理源文件、整理切图、配合前端协作同样非常适用。本文就从设计师的视角出发围绕“Git for Designers”这个概念完整梳理设计师使用 Git 的环境搭建、核心概念、图形化工具操作、命令行对照、高频报错排查和工程建议。不管你是刚接触 Git 的设计新人还是想建立一套设计资产管理流程的资深设计师这篇文章都能提供一套可以直接落地的方案。1. 设计师为什么需要 Git从版本混乱到资产沉淀很多人第一次听到“设计师用 Git”会觉得夸张。因为在大多数设计团队里版本管理这件事一直都存在只是被设计工具自身承担了。Figma 有 Version HistorySketch 可以通过云协作保留历史这些能力在一定程度上解决了“找不到上一版”的问题。但真实工作流中还是会遇到大量工具覆盖不到的缝隙本地源文件的版本管理缺失。Figma 的版本记录只存在于云端如果你的交付物是 PSD、AI、Sketch 源文件或者需要在本地处理的 C4D、Blender 工程一旦本地文件被误修改、误删除或者想找回三天前删掉的一个画板很多设计工具并不会给你后悔药。切图资源的多版本问题。一套界面往往伴随着 1x、2x、3x 多套切图再加上图标字体、动效素材、设计规范文档文件数量很快就会膨胀到几百个。如果只靠压缩包归档每次更新都要手动对比效率和准确率都很低。设计与开发的协作断裂。现在的产品开发绝大部分采用 Git 管理代码。前端工程师拉取分支、修改样式、提交合并这一套流程非常成熟。设计师如果能够把设计资产设计规范、切图、标注文档也放进同一个仓库或者平行的资产仓库开发同学就可以直接通过 Git 拉取最新设计资源不再需要设计师手动传文件。多人协作时的冲突问题。当两位设计师同时修改同一个设计系统库或者两个前端同时引用不同版本的切图时如果没有统一版本管理很容易出现资源覆盖和引用紊乱。Git 的设计哲学是“记录每一次变化的快照并允许你在任意时间点切换”。它不关心文件是用什么软件生成的只关心文件内容是否发生变化。因此它天然适合用来管理一切需要追溯历史的文件资产包括设计师的源文件、切图、文档、配置文件。跨过“Git 是程序员专属工具”这个心理门槛之后设计师会发现它其实是一套通用的资产管理思维把每个稳定版本固化下来把每次实验性修改放到独立分支里把最终确认的资源合并回主线。这样设计资产就不再是一堆命名混乱的压缩包而是一个可以随时回溯、对比、合并的资产库。2. Git 的核心概念用设计场景理解版本管理在为设计师讲解 Git 的时候最好的方式是把抽象概念翻译成设计师熟悉的语言。下面就把 Git 的核心概念和设计工作流的对应关系做一个梳理。2.1 仓库Repository设计资产的“总项目文件夹”仓库是 Git 管理的基本单位可以理解成一个“被 Git 监控的项目文件夹”。你在文件夹里执行git init之后Git 就会开始记录这个文件夹内所有文件的变化情况。在设计师的实践中一个仓库可以对应某个 App 项目的全部设计资产。一套设计规范/Design System 的源文件与文档。一个团队的公用的图标库和切图资源。仓库与普通文件夹的区别在于它拥有一套完整的“历史记录系统”包括每次修改的作者、时间、修改内容、修改说明。2.2 提交Commit给设计稿打一个“版本快照”commit是整个 Git 流程中最核心的动作。可以把提交理解成当前所有文件状态的一份“存档”。设计师不必为“提交”这个名词感到紧张。其实之前做设计稿时每次导出一版新的文件本质上就是在做一次“手动提交”。Git 把这件事自动化了并且每次提交时可以附带说明例如“完成首页改版替换顶部 Banner 切图”“修改登录页按钮 hover 状态”“更新设计规范中的颜色变量”提交记录形成一条时间线。你可以随时回退到任何一个提交查看当时所有文件的内容。这里有一个非常重要的概念提交不是“保存文件”。保存文件只是更新了本地文件内容而提交是把当前内容正式记录到 Git 历史中。所以修改文件后一定要记得提交否则 Git 不知道你做了修改。2.3 分支Branch并行尝试多个设计方案分支是 Git 最强大的功能之一也是设计师最容易理解的部分——它就像是“设计方案的平行宇宙”。举个例子团队要对首页进行一次大的改版但你还不确定是采用“卡片流”布局还是“列表流”布局。传统的做法是复制两个文件夹分别做两版设计。而 Git 的做法是从主分支上创建两个分支feature/card-layout和feature/list-layout。在两个分支上分别尝试不同的设计方案互不干扰。最终确定方案 A 后把feature/card-layout分支合并回主分支即可。分支让“并行探索”变得安全。你可以在一个分支上放心大胆地做激进尝试而不用担心破坏已有的稳定版本。2.4 合并Merge与冲突Conflict多人协作的接缝处当你把两个分支合并到一起时如果同一份文件的不同位置都发生了修改Git 能自动处理大部分情况。但如果两个人修改了同一份文件的同一部分Git 就无法判断谁是对的这时会提示“冲突”。冲突在设计文件上的表现比较特殊。因为 Sketch、PSD 这类二进制格式文件无法按行自动合并Git 只能判定“文件冲突”需要人工决定采用哪个版本。这并不意味着 Git 不能用于设计文件管理。实际项目中的通行做法是同一时间只允许一个人在某一个分支上修改同一份源文件通过合理分工避免冲突。切图类资源通常是 PNG、SVG 文本可以自动合并或者通过规则避免冲突。文本类文件设计规范 Markdown、JSON、SVG 图标源码可以享受 Git 完整的行级合并能力。2.5 远程仓库Remote云端同步与团队共享远程仓库是放在服务器上的 Git 仓库副本常见平台包括 GitHub、GitLab、Gitee。它承担两个职责备份本地仓库损坏或电脑丢失时可以从远程恢复。协作团队成员通过push推送到远程和pull拉取到本地同步各自的分支和提交。设计师的使用场景通常是把最终的切图、设计规范、设计源文件推送到远程仓库前端工程师直接拉取即可。这个流程打通了设计与开发之间的传输链路。2.6 工作区、暂存区与 HEAD一次提交的三个阶段初次接触 Git 时最困惑的是git add和git commit为什么要分成两步。可以这样理解工作区你当前看到的、正在编辑的文件目录。暂存区Index你“选中”准备提交的一批文件变更。类似于做设计时先挑选要放进交付文件夹的素材。HEAD当前分支最后一次提交的指针。运行流程是工作区修改文件 → git add → 暂存区 → git commit → 本地仓库HEAD→ git push → 远程仓库拆成两步的好处是你可以把多个文件的修改分批提交比如这次提交只包含界面的改动下次提交只包含切图的改动每次提交都保持一个清晰的逻辑单元。理解了以上这些概念设计师就已经掌握了 Git 最基本的心智模型。下面进入真正的实操环节从安装配置开始。3. 环境准备Git 安装与基础配置3.1 在 macOS 上安装 GitmacOS 上安装 Git 最推荐的方式是使用 Homebrew# 安装 Homebrew如果还没有安装 /bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) # 使用 Homebrew 安装 Git brew install git # 验证安装 git --version如果你不想安装 Homebrew也可以直接从 Git 官网下载 macOS 安装包使用系统默认的安装向导完成安装。3.2 在 Windows 上安装 GitWindows 用户推荐从 Git 官网下载安装包。安装过程中有几个选项需要特别留意调整 PATH 环境建议选择 “Git from the command line and also from 3rd-party software”这样可以让 Git 命令在 CMD、PowerShell、Git Bash 中都能使用。换行符转换建议选择 “Checkout as-is, commit as-is”避免在不同操作系统间产生换行符问题。终端模拟器默认选择 “Use MinTTY” 即可。安装完成后打开 Git Bash或 PowerShell验证安装git --version很多 Windows 用户在初次使用时遇到git 不是内部或外部命令的报错原因就是安装时没有把 Git 加入 PATH。解决办法是重新运行安装程序在 Adjusting your PATH environment 这一步选择第一项。3.3 全局配置与 SSH 免密配置Git 安装完成后第一件事是配置用户名和邮箱。这个信息会记录在每次提交中方便团队知道修改是谁做的# 配置全局用户名和邮箱 git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com # 查看当前配置 git config --list如果你计划通过 HTTPS 方式与远程仓库交互每次 push 和 pull 都需要输入账号密码。为了避免这个麻烦可以配置 SSH 免密登录# 生成 SSH 密钥一路回车即可 ssh-keygen -t rsa -b 4096 -C 你的邮箱example.com # 查看公钥内容 cat ~/.ssh/id_rsa.pub把输出的公钥复制到 GitHub/GitLab/Gitee 的 “SSH Keys” 设置页面中保存。之后在克隆仓库时使用 SSH 地址就可以免密操作了。3.4 推荐设计师使用的图形化客户端命令行并不是所有人的舒适区。虽然本文后面会提供常用命令对照但设计师在实际工作中完全可以使用图形化客户端完成大部分操作。常用的选择客户端适用场景特点GitHub DesktopGitHub 用户界面简洁上手门槛低Sourcetree通用 Git 平台功能完整支持分支可视化TortoiseGit小乌龟Windows 资源管理器集成右键操作非常符合 Windows 用户习惯VS Code 内置 Git 面板配合开发协作前后端同事常用方便对接图形化工具和命令行是互补关系。刚开始可以用图形化工具完成日常提交、推送、拉取遇到问题时再用命令行排查。熟练之后会发现命令行在某些批量操作场景下更高效。4. 实战案例用 Git 管理一套设计资产下面我们从一个完整的场景出发演示设计师如何用 Git 管理一套 App 设计资产。假设你要管理一个移动端项目的 UI Kit包含以下内容design-assets/ ├── source/ # 设计源文件 │ ├── app-home.fig │ └── design-system.sketch ├── exports/ # 切图导出 │ ├── ic-home2x.png │ ├── ic-home3x.png │ └── ic-profile3x.png ├── docs/ # 设计规范文档 │ └── design-tokens.md └── README.md # 仓库说明4.1 创建项目结构并初始化仓库首先创建项目目录并初始化 Git 仓库# 创建目录 mkdir design-assets cd design-assets # 初始化 Git 仓库 git init # 创建基础目录结构 mkdir -p source exports docs4.2 准备 .gitignore 文件.gitignore文件用来告诉 Git哪些文件或目录不需要纳入版本管理。对于设计师项目典型的忽略规则包括# 系统文件 .DS_Store Thumbs.db # 临时文件 *.tmp *~ # 设计软件自动生成的本地缓存 *.autosave .idea/ .vscode/ # 大体积中间产物根据实际情况决定是否忽略 exports/*.bak exports/*.old/注意.gitignore不会影响已经被 Git 跟踪的文件。如果你发现某些文件已经被跟踪了需要先执行git rm --cached 文件将其从跟踪列表中移除。4.3 添加依赖或配置在项目的根目录创建README.md说明这个仓库的用途、目录结构、更新规范。这对团队协作非常重要# 移动端 App 设计资产仓库 本仓库用于管理 XX 移动端项目的设计源文件、切图和设计规范。 ## 目录说明 - source/设计源文件Figma/Sketch/PSD同一时间只允许一人修改 - exports/切图导出资源按 1x/2x/3x 命名 - docs/设计规范、标注文档 ## 提交规范 - 提交信息格式类型: 简述 - 示例feat: 新增首页空状态插图、fix: 修正登录页按钮切图尺寸4.4 创建第一次提交把项目文件加入暂存区并创建第一个提交# 查看当前仓库状态 git status # 将当前目录下所有文件加入暂存区 git add . # 创建提交 git commit -m feat: 初始化设计资产仓库添加目录结构与说明文档 # 查看提交历史 git log --oneline这里需要强调一下git status的作用它会告诉你当前工作区的状态包括哪些文件被修改、哪些文件已暂存、哪些文件未跟踪。养成随时查看状态的习惯可以避免很多误操作。4.5 编写核心操作流程一天的真实工作流假设现在是第二天的上班时间你完成了首页改版设计导出了新的切图。整个操作流程如下# 1. 先看一下当前仓库状态确保没有遗漏 git status # 2. 将修改的文件加入暂存区可以按文件精确添加 git add source/app-home.fig exports/ic-home2x.png exports/ic-home3x.png # 3. 创建提交 git commit -m feat: 完成首页改版设计更新 2x/3x 首页图标切图 # 4. 如果配置了远程仓库推送到远程 git remote add origin gitgithub.com:你的用户名/design-assets.git git push -u origin main这样一次完整的设计更新就通过 Git 记录并同步到了远程仓库。开发同学拉取代码后可以直接在指定目录下获取最新切图。4.6 创建分支尝试不同方案现在假设需要对“个人中心页”进行一次改版你有两套方案。使用分支可以安全地并行推进# 创建并切换到新分支 git checkout -b feature/profile-card # 在这个分支上修改文件、提交 git add source/profile-page.fig git commit -m feat: 个人中心页卡片式布局方案 # 切回主分支创建另一个分支 git checkout main git checkout -b feature/profile-list git add source/profile-page.fig git commit -m feat: 个人中心页列表式布局方案两个分支互不干扰。经过评审确定采用“卡片式布局”后把该分支合并回主分支# 切回主分支 git checkout main # 合并 feature/profile-card 分支 git merge feature/profile-card # 删除已合并的分支 git branch -d feature/profile-card4.7 回滚到历史版本如果发现最新的修改有问题需要回到之前的稳定版本。先使用git log查看提交历史git log --oneline输出类似a1b2c3d feat: 个人中心页卡片式布局方案 e4f5a6b feat: 完成首页改版设计更新切图 f6g7h8i feat: 初始化设计资产仓库如果需要完全回退到某个历史提交注意这会改变提交历史只推荐在本地分支未推送的情况下使用git reset --hard e4f5a6b如果只是临时查看历史版本的内容更安全的做法是切换到临时分支git checkout -b temp-branch e4f5a6b在确认是否需要恢复后再决定合并还是删除该临时分支。设计师在面对版本回退时要格外小心尤其是仓库已经推送到远程并多人协作时尽量不要使用git reset --hard操作已被推送的历史建议改用git revert生成一个新的反向提交。开发团队的通常做法是本地未推送使用git reset --hard回退。已经推送远程使用git revert commit产生一次反向提交保留完整历史。只是想查看旧版本使用git checkout commit或创建临时分支。4.8 运行与验证在完成上述操作后可以用一套组合命令来对比提交之间的差异确认修改是否正确# 查看工作区与暂存区之间的差异 git diff # 查看暂存区与上一次提交之间的差异 git diff --cached # 查看两个提交之间的差异 git diff 旧提交号 新提交号git diff对文本文件非常友好会精确到每一行的变化。对于二进制设计源文件diff 并不能看到具体内容变化只能看出文件是否被修改。这个限制设计师需要了解但不影响版本管理本身的价值。以下是一个简单的设计资产版本管理流程可视化用文字描述工作区修改 → git add → 暂存区 → git commit → 本地仓库 → git push → 远程仓库 ↑ git pull / git fetch从远程同步5. 面向设计师的常用 Git 命令速查日常设计资产管理并不需要掌握太多 Git 命令。下面是一份精简版速查表建议收藏。5.1 仓库操作操作命令初始化仓库git init克隆远程仓库git clone 远程地址查看远程仓库git remote -v添加远程仓库git remote add origin 远程地址5.2 提交操作操作命令查看状态git status添加单个文件git add 文件名添加所有文件git add .提交git commit -m 提交说明修改上一次提交说明git commit --amend -m 新的说明查看提交历史git log --oneline5.3 分支操作操作命令查看分支git branch创建并切换分支git checkout -b 分支名切换分支git checkout 分支名合并分支git merge 分支名删除分支git branch -d 分支名5.4 同步操作操作命令推送到远程git push origin 分支名拉取远程更新git pull origin 分支名抓取远程更新但不合并git fetch origin5.5 撤销与回退操作命令撤销工作区修改git restore 文件名撤销暂存区修改git restore --staged 文件名生成反向提交git revert 提交号回退到指定提交git reset --hard 提交号6. 常见问题与排查思路设计师在使用 Git 时会遇到一些典型问题。下面按问题现象、常见原因、解决思路列出。6.1 报错git 不是内部或外部命令 / 无法将“git”项识别为 cmdlet项目内容问题现象在 CMD 或 PowerShell 中输入git命令提示找不到该命令常见原因Git 安装时未加入系统 PATH 环境变量解决思路重新运行 Git 安装程序在 Adjusting your PATH environment 步骤选择 “Git from the command line and also from 3rd-party software”或者手动把 Git 安装目录下的cmd目录添加到系统环境变量 PATH 中预防方案Windows 安装时仔细阅读每个步骤不要一路默认。尽量使用 Git Bash 而不是 CMD6.2 报错fatal: not a git repository项目内容问题现象执行git status或git commit时提示当前目录不是 Git 仓库常见原因当前目录或上级目录中没有执行过git init解决思路先执行git init初始化仓库或者使用cd切换到正确的项目目录预防方案在执行任何 Git 命令前先确认当前所在目录是否符合预期6.3 提交时没有设置用户名和邮箱项目内容问题现象执行git commit时提示无法自动识别用户信息常见原因安装 Git 后没有执行git config --global user.name和user.email解决思路按前文全局配置步骤补齐配置预防方案新环境安装 Git 后的第一件事就是配置用户信息6.4 合并设计源文件时出现冲突项目内容问题现象合并分支时提示 CONFLICT文件无法自动合并常见原因两个分支中同一文件的不同修改同时存在设计源文件为二进制格式Git 无法自动合并解决思路手动选择保留某一个版本或者使用最新版本覆盖旧版本后重新提交预防方案对source/目录下的源文件约定“同一时间仅一人修改”的规则将可合并的文件JSON、SVG、Markdown与二进制文件分开管理6.5 误上传了大文件或敏感文件项目内容问题现象仓库体积急剧膨胀或不小心提交了包含账号密码的配置文件常见原因未提前配置.gitignore将不该提交的文件纳入了版本管理解决思路使用git rm --cached 文件从 Git 跟踪中移除如果敏感信息已经推送到远程需要立即修改密码/密钥并联系团队管理员清理远程历史可使用 BFG Repo-Cleaner 工具预防方案提交前一定执行git status确认将要添加的文件列表大文件使用 Git LFS 管理6.6 远程仓库连接失败或证书报错项目内容问题现象push/pull 时出现unable to access或证书相关的报错常见原因网络策略限制、代理设置错误、SSL 证书配置异常解决思路先检查网络连通性如果使用代理确认代理地址是否配置正确如果证书异常可联系管理员或临时使用 SSH 协议替代 HTTPS 协议预防方案在企业内网环境中优先使用 SSH 协议配合管理员分配的访问权限尽量避免个人修改全局证书配置6.7 设计文件版本过多导致仓库体积膨胀项目内容问题现象仓库体积迅速增长clone 和 push 都变慢常见原因设计源文件体积大且每次修改都产生新版本历史中积累了过多大文件解决思路将大体积源文件转移到 Git LFSLarge File Storage管理或者在依赖在线设计工具的团队中只把切图和文档放入 Git 仓库源文件保留在设计工具云端预防方案从一开始就明确仓库边界哪些文件进 Git哪些不进 Git写入 README7. 设计团队 Git 工作流最佳实践7.1 明确仓库边界不是所有设计文件都必须进 Git设计团队需要根据自己的工作流决定 Git 管理什么、不管理什么。以下是三种常见的仓库策略策略一全量资产仓库将源文件、切图、文档全部纳入 Git。适合本地工具为主PSD/AI/Sketch、文件体积可控的团队。策略二输出资产仓库依赖 Figma 等在线工具的团队源文件本身已经有云版本记录因此 Git 仓库只放切图、设计规范 JSON、Markdown 文档、图标 SVG。这种策略最轻量也最容易和前端协作。策略三设计系统仓库专门为 Design System 建立独立仓库包含颜色令牌、字体规范、组件切图、使用文档。前端、设计师都围绕这个仓库协作修改需要走分支评审流程。7.2 提交信息规范让历史记录可读提交信息是团队协作的“日志”。建议采用以下约定类型: 简述常见类型包括类型含义示例feat新增功能/资源feat: 新增支付成功页插图fix修复问题fix: 修正首页按钮禁用态颜色docs文档更新docs: 更新设计规范中的间距说明style格式或资源调整style: 图标统一改为圆角风格refactor重构不改变功能refactor: 调整切图目录层级提交粒度要适中。一次提交只做一件事不要把几十个无关改动混在一起。这样后续回溯时会非常方便。7.3 分支策略简单不等于低效设计团队不需要照搬复杂的 Git Flow。建议使用简约的模式main分支始终保留已确认可用的稳定版本。feature/xxx分支每个新功能或改版任务创建独立分支完成后合并回 main 并删除分支。release/xxx分支可选需要发布给开发时从 main 拉一个发布分支冻结修改。尽量不要在 main 上直接修改并提交。强制走“分支开发 → 合并回 main”的流程虽然刚开始觉得繁琐但习惯了之后会非常安全。7.4 与开发同学协作的正确姿势设计资产仓库最大的价值不在于“归档”而在于“打通”。推荐流程是设计团队在代码托管平台创建独立的design-assets仓库。前端项目通过 Git 依赖方式submodule 或包管理器引用设计资产仓库中的切图/规范文档。设计师更新切图后发起合并请求前端完成适配后拉取最新资源。这样整个流程就变成了“设计更新 → 提交 → 通知 → 前端拉取”不再需要手动传压缩包也避免了“你发我的还是旧版”这种尴尬。7.5 安全边界与权限管理设计资产同样是公司的重要知识产权建议在团队协作中做好权限控制设置仓库私有外部人员不可见。按角色分配权限设计师具备读写权限前端工程师可以只读或读写指定目录外包/实习人员使用只读权限。不要将机密设计稿、未发布的品牌物料提交到公开仓库。7.6 Git LFS设计师的大文件解决方案如果必须把 Sketch、PSD 这类大文件放进 Git 仓库强烈建议启用 Git LFS。Git LFS 将大文件替换为文本指针实际文件存储在 LFS 服务器上从而避免仓库无限膨胀。启用方式以 GitHub 为例# 安装 Git LFS git lfs install # 在仓库中指定大文件后缀 git lfs track *.psd git lfs track *.sketch git lfs track *.fig # 提交 .gitattributes 文件 git add .gitattributes git commit -m chore: 添加 Git LFS 跟踪规则注意Git LFS 有存储配额限制对于超大文件依然要谨慎。如果团队主要使用 Figma 这类在线工具源文件建议保留在云端Git 仓库只放轻量的切图和文档。8. 设计师学习 Git 的下一步路径对于设计师来说Git 是一个“入门容易、精通难”的工具。但好在日常设计中用到的高级操作并不多只要掌握了以下几件事就足以支撑绝大部分工作场景能够初始化仓库、添加文件、提交修改、推送到远程。能够创建分支、切换分支、合并分支。能够在需要时回退到历史版本。能够看懂提交历史和团队协作日志。能够使用.gitignore避免误提交无关文件。能够用图形化客户端完成以上操作命令行为辅助。下一步可以尝试的方向学习如何在 Figma 插件中调用 Git 能力把设计变量直接导出为代码仓库中的 JSON token。掌握 GitHub/GitLab 的 Pull Request / Merge Request 流程主动参与设计与开发之间的代码评审。尝试自己为团队搭建一套设计资产仓库把切图、规范、文档完整地管理起来。阅读 Git 官方文档中关于 reflog、cherry-pick、stash 等进阶命令的说明逐步提升“救场”能力。在实际项目中最优先关注的永远是提交前确认文件列表推送到远程前检查分支删除分支前确认是否合并。这三条习惯可以避免绝大多数事故。Git 本质上不是程序员的特权而是一种通用的协作规范。设计师掌握它并不意味着要转行写代码而是为自己的设计资产建立一套真正可靠的版本管理体系。当一个项目做了半年、一年之后你还能轻松找到半年前某个方案的设计稿并且知道它和现在的版本之间发生了什么变化你就会发现学 Git 的这点投入是值得的。如果本文对你有帮助可以收藏备用。下一步建议直接在你的电脑上试着创建一个仓库把自己的设计稿放进去体验一次完整的“提交-分支-合并-回退”流程。只有亲手操作过一遍才能真正理解 Git 的设计思路。 
长河君 · 2026/8/31 9:43:44 · 阅读 1.2k 设计师的Git版本管理实战指南：从入门到资产协作
在设计圈摸爬滚打久了很多人都会遇到一个尴尬场景设计稿改了十几版桌面上的文件名从首页终版.fig一路变成了首页最终版_v12_真的不改了.fig最后自己也分不清哪一版才是交付给开发的那一版。平时我们做设计协作依赖的是 Figma、Sketch 这类在线工具的自动版本记录但一旦回到本地源文件、批处理脚本、切图资源、或者与开发同学共用的项目仓库就会立刻发现设计资产的版本管理其实一直处于“裸奔”状态。Git 并不仅仅是程序员的“代码存钱罐”。它的核心能力是追踪文件的每一次变化、支持多人并行修改、随时回退到任意历史版本。这套逻辑对于设计师管理源文件、整理切图、配合前端协作同样非常适用。本文就从设计师的视角出发围绕“Git for Designers”这个概念完整梳理设计师使用 Git 的环境搭建、核心概念、图形化工具操作、命令行对照、高频报错排查和工程建议。不管你是刚接触 Git 的设计新人还是想建立一套设计资产管理流程的资深设计师这篇文章都能提供一套可以直接落地的方案。1. 设计师为什么需要 Git从版本混乱到资产沉淀很多人第一次听到“设计师用 Git”会觉得夸张。因为在大多数设计团队里版本管理这件事一直都存在只是被设计工具自身承担了。Figma 有 Version HistorySketch 可以通过云协作保留历史这些能力在一定程度上解决了“找不到上一版”的问题。但真实工作流中还是会遇到大量工具覆盖不到的缝隙本地源文件的版本管理缺失。Figma 的版本记录只存在于云端如果你的交付物是 PSD、AI、Sketch 源文件或者需要在本地处理的 C4D、Blender 工程一旦本地文件被误修改、误删除或者想找回三天前删掉的一个画板很多设计工具并不会给你后悔药。切图资源的多版本问题。一套界面往往伴随着 1x、2x、3x 多套切图再加上图标字体、动效素材、设计规范文档文件数量很快就会膨胀到几百个。如果只靠压缩包归档每次更新都要手动对比效率和准确率都很低。设计与开发的协作断裂。现在的产品开发绝大部分采用 Git 管理代码。前端工程师拉取分支、修改样式、提交合并这一套流程非常成熟。设计师如果能够把设计资产设计规范、切图、标注文档也放进同一个仓库或者平行的资产仓库开发同学就可以直接通过 Git 拉取最新设计资源不再需要设计师手动传文件。多人协作时的冲突问题。当两位设计师同时修改同一个设计系统库或者两个前端同时引用不同版本的切图时如果没有统一版本管理很容易出现资源覆盖和引用紊乱。Git 的设计哲学是“记录每一次变化的快照并允许你在任意时间点切换”。它不关心文件是用什么软件生成的只关心文件内容是否发生变化。因此它天然适合用来管理一切需要追溯历史的文件资产包括设计师的源文件、切图、文档、配置文件。跨过“Git 是程序员专属工具”这个心理门槛之后设计师会发现它其实是一套通用的资产管理思维把每个稳定版本固化下来把每次实验性修改放到独立分支里把最终确认的资源合并回主线。这样设计资产就不再是一堆命名混乱的压缩包而是一个可以随时回溯、对比、合并的资产库。2. Git 的核心概念用设计场景理解版本管理在为设计师讲解 Git 的时候最好的方式是把抽象概念翻译成设计师熟悉的语言。下面就把 Git 的核心概念和设计工作流的对应关系做一个梳理。2.1 仓库Repository设计资产的“总项目文件夹”仓库是 Git 管理的基本单位可以理解成一个“被 Git 监控的项目文件夹”。你在文件夹里执行git init之后Git 就会开始记录这个文件夹内所有文件的变化情况。在设计师的实践中一个仓库可以对应某个 App 项目的全部设计资产。一套设计规范/Design System 的源文件与文档。一个团队的公用的图标库和切图资源。仓库与普通文件夹的区别在于它拥有一套完整的“历史记录系统”包括每次修改的作者、时间、修改内容、修改说明。2.2 提交Commit给设计稿打一个“版本快照”commit是整个 Git 流程中最核心的动作。可以把提交理解成当前所有文件状态的一份“存档”。设计师不必为“提交”这个名词感到紧张。其实之前做设计稿时每次导出一版新的文件本质上就是在做一次“手动提交”。Git 把这件事自动化了并且每次提交时可以附带说明例如“完成首页改版替换顶部 Banner 切图”“修改登录页按钮 hover 状态”“更新设计规范中的颜色变量”提交记录形成一条时间线。你可以随时回退到任何一个提交查看当时所有文件的内容。这里有一个非常重要的概念提交不是“保存文件”。保存文件只是更新了本地文件内容而提交是把当前内容正式记录到 Git 历史中。所以修改文件后一定要记得提交否则 Git 不知道你做了修改。2.3 分支Branch并行尝试多个设计方案分支是 Git 最强大的功能之一也是设计师最容易理解的部分——它就像是“设计方案的平行宇宙”。举个例子团队要对首页进行一次大的改版但你还不确定是采用“卡片流”布局还是“列表流”布局。传统的做法是复制两个文件夹分别做两版设计。而 Git 的做法是从主分支上创建两个分支feature/card-layout和feature/list-layout。在两个分支上分别尝试不同的设计方案互不干扰。最终确定方案 A 后把feature/card-layout分支合并回主分支即可。分支让“并行探索”变得安全。你可以在一个分支上放心大胆地做激进尝试而不用担心破坏已有的稳定版本。2.4 合并Merge与冲突Conflict多人协作的接缝处当你把两个分支合并到一起时如果同一份文件的不同位置都发生了修改Git 能自动处理大部分情况。但如果两个人修改了同一份文件的同一部分Git 就无法判断谁是对的这时会提示“冲突”。冲突在设计文件上的表现比较特殊。因为 Sketch、PSD 这类二进制格式文件无法按行自动合并Git 只能判定“文件冲突”需要人工决定采用哪个版本。这并不意味着 Git 不能用于设计文件管理。实际项目中的通行做法是同一时间只允许一个人在某一个分支上修改同一份源文件通过合理分工避免冲突。切图类资源通常是 PNG、SVG 文本可以自动合并或者通过规则避免冲突。文本类文件设计规范 Markdown、JSON、SVG 图标源码可以享受 Git 完整的行级合并能力。2.5 远程仓库Remote云端同步与团队共享远程仓库是放在服务器上的 Git 仓库副本常见平台包括 GitHub、GitLab、Gitee。它承担两个职责备份本地仓库损坏或电脑丢失时可以从远程恢复。协作团队成员通过push推送到远程和pull拉取到本地同步各自的分支和提交。设计师的使用场景通常是把最终的切图、设计规范、设计源文件推送到远程仓库前端工程师直接拉取即可。这个流程打通了设计与开发之间的传输链路。2.6 工作区、暂存区与 HEAD一次提交的三个阶段初次接触 Git 时最困惑的是git add和git commit为什么要分成两步。可以这样理解工作区你当前看到的、正在编辑的文件目录。暂存区Index你“选中”准备提交的一批文件变更。类似于做设计时先挑选要放进交付文件夹的素材。HEAD当前分支最后一次提交的指针。运行流程是工作区修改文件 → git add → 暂存区 → git commit → 本地仓库HEAD→ git push → 远程仓库拆成两步的好处是你可以把多个文件的修改分批提交比如这次提交只包含界面的改动下次提交只包含切图的改动每次提交都保持一个清晰的逻辑单元。理解了以上这些概念设计师就已经掌握了 Git 最基本的心智模型。下面进入真正的实操环节从安装配置开始。3. 环境准备Git 安装与基础配置3.1 在 macOS 上安装 GitmacOS 上安装 Git 最推荐的方式是使用 Homebrew# 安装 Homebrew如果还没有安装 /bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) # 使用 Homebrew 安装 Git brew install git # 验证安装 git --version如果你不想安装 Homebrew也可以直接从 Git 官网下载 macOS 安装包使用系统默认的安装向导完成安装。3.2 在 Windows 上安装 GitWindows 用户推荐从 Git 官网下载安装包。安装过程中有几个选项需要特别留意调整 PATH 环境建议选择 “Git from the command line and also from 3rd-party software”这样可以让 Git 命令在 CMD、PowerShell、Git Bash 中都能使用。换行符转换建议选择 “Checkout as-is, commit as-is”避免在不同操作系统间产生换行符问题。终端模拟器默认选择 “Use MinTTY” 即可。安装完成后打开 Git Bash或 PowerShell验证安装git --version很多 Windows 用户在初次使用时遇到git 不是内部或外部命令的报错原因就是安装时没有把 Git 加入 PATH。解决办法是重新运行安装程序在 Adjusting your PATH environment 这一步选择第一项。3.3 全局配置与 SSH 免密配置Git 安装完成后第一件事是配置用户名和邮箱。这个信息会记录在每次提交中方便团队知道修改是谁做的# 配置全局用户名和邮箱 git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com # 查看当前配置 git config --list如果你计划通过 HTTPS 方式与远程仓库交互每次 push 和 pull 都需要输入账号密码。为了避免这个麻烦可以配置 SSH 免密登录# 生成 SSH 密钥一路回车即可 ssh-keygen -t rsa -b 4096 -C 你的邮箱example.com # 查看公钥内容 cat ~/.ssh/id_rsa.pub把输出的公钥复制到 GitHub/GitLab/Gitee 的 “SSH Keys” 设置页面中保存。之后在克隆仓库时使用 SSH 地址就可以免密操作了。3.4 推荐设计师使用的图形化客户端命令行并不是所有人的舒适区。虽然本文后面会提供常用命令对照但设计师在实际工作中完全可以使用图形化客户端完成大部分操作。常用的选择客户端适用场景特点GitHub DesktopGitHub 用户界面简洁上手门槛低Sourcetree通用 Git 平台功能完整支持分支可视化TortoiseGit小乌龟Windows 资源管理器集成右键操作非常符合 Windows 用户习惯VS Code 内置 Git 面板配合开发协作前后端同事常用方便对接图形化工具和命令行是互补关系。刚开始可以用图形化工具完成日常提交、推送、拉取遇到问题时再用命令行排查。熟练之后会发现命令行在某些批量操作场景下更高效。4. 实战案例用 Git 管理一套设计资产下面我们从一个完整的场景出发演示设计师如何用 Git 管理一套 App 设计资产。假设你要管理一个移动端项目的 UI Kit包含以下内容design-assets/ ├── source/ # 设计源文件 │ ├── app-home.fig │ └── design-system.sketch ├── exports/ # 切图导出 │ ├── ic-home2x.png │ ├── ic-home3x.png │ └── ic-profile3x.png ├── docs/ # 设计规范文档 │ └── design-tokens.md └── README.md # 仓库说明4.1 创建项目结构并初始化仓库首先创建项目目录并初始化 Git 仓库# 创建目录 mkdir design-assets cd design-assets # 初始化 Git 仓库 git init # 创建基础目录结构 mkdir -p source exports docs4.2 准备 .gitignore 文件.gitignore文件用来告诉 Git哪些文件或目录不需要纳入版本管理。对于设计师项目典型的忽略规则包括# 系统文件 .DS_Store Thumbs.db # 临时文件 *.tmp *~ # 设计软件自动生成的本地缓存 *.autosave .idea/ .vscode/ # 大体积中间产物根据实际情况决定是否忽略 exports/*.bak exports/*.old/注意.gitignore不会影响已经被 Git 跟踪的文件。如果你发现某些文件已经被跟踪了需要先执行git rm --cached 文件将其从跟踪列表中移除。4.3 添加依赖或配置在项目的根目录创建README.md说明这个仓库的用途、目录结构、更新规范。这对团队协作非常重要# 移动端 App 设计资产仓库 本仓库用于管理 XX 移动端项目的设计源文件、切图和设计规范。 ## 目录说明 - source/设计源文件Figma/Sketch/PSD同一时间只允许一人修改 - exports/切图导出资源按 1x/2x/3x 命名 - docs/设计规范、标注文档 ## 提交规范 - 提交信息格式类型: 简述 - 示例feat: 新增首页空状态插图、fix: 修正登录页按钮切图尺寸4.4 创建第一次提交把项目文件加入暂存区并创建第一个提交# 查看当前仓库状态 git status # 将当前目录下所有文件加入暂存区 git add . # 创建提交 git commit -m feat: 初始化设计资产仓库添加目录结构与说明文档 # 查看提交历史 git log --oneline这里需要强调一下git status的作用它会告诉你当前工作区的状态包括哪些文件被修改、哪些文件已暂存、哪些文件未跟踪。养成随时查看状态的习惯可以避免很多误操作。4.5 编写核心操作流程一天的真实工作流假设现在是第二天的上班时间你完成了首页改版设计导出了新的切图。整个操作流程如下# 1. 先看一下当前仓库状态确保没有遗漏 git status # 2. 将修改的文件加入暂存区可以按文件精确添加 git add source/app-home.fig exports/ic-home2x.png exports/ic-home3x.png # 3. 创建提交 git commit -m feat: 完成首页改版设计更新 2x/3x 首页图标切图 # 4. 如果配置了远程仓库推送到远程 git remote add origin gitgithub.com:你的用户名/design-assets.git git push -u origin main这样一次完整的设计更新就通过 Git 记录并同步到了远程仓库。开发同学拉取代码后可以直接在指定目录下获取最新切图。4.6 创建分支尝试不同方案现在假设需要对“个人中心页”进行一次改版你有两套方案。使用分支可以安全地并行推进# 创建并切换到新分支 git checkout -b feature/profile-card # 在这个分支上修改文件、提交 git add source/profile-page.fig git commit -m feat: 个人中心页卡片式布局方案 # 切回主分支创建另一个分支 git checkout main git checkout -b feature/profile-list git add source/profile-page.fig git commit -m feat: 个人中心页列表式布局方案两个分支互不干扰。经过评审确定采用“卡片式布局”后把该分支合并回主分支# 切回主分支 git checkout main # 合并 feature/profile-card 分支 git merge feature/profile-card # 删除已合并的分支 git branch -d feature/profile-card4.7 回滚到历史版本如果发现最新的修改有问题需要回到之前的稳定版本。先使用git log查看提交历史git log --oneline输出类似a1b2c3d feat: 个人中心页卡片式布局方案 e4f5a6b feat: 完成首页改版设计更新切图 f6g7h8i feat: 初始化设计资产仓库如果需要完全回退到某个历史提交注意这会改变提交历史只推荐在本地分支未推送的情况下使用git reset --hard e4f5a6b如果只是临时查看历史版本的内容更安全的做法是切换到临时分支git checkout -b temp-branch e4f5a6b在确认是否需要恢复后再决定合并还是删除该临时分支。设计师在面对版本回退时要格外小心尤其是仓库已经推送到远程并多人协作时尽量不要使用git reset --hard操作已被推送的历史建议改用git revert生成一个新的反向提交。开发团队的通常做法是本地未推送使用git reset --hard回退。已经推送远程使用git revert commit产生一次反向提交保留完整历史。只是想查看旧版本使用git checkout commit或创建临时分支。4.8 运行与验证在完成上述操作后可以用一套组合命令来对比提交之间的差异确认修改是否正确# 查看工作区与暂存区之间的差异 git diff # 查看暂存区与上一次提交之间的差异 git diff --cached # 查看两个提交之间的差异 git diff 旧提交号 新提交号git diff对文本文件非常友好会精确到每一行的变化。对于二进制设计源文件diff 并不能看到具体内容变化只能看出文件是否被修改。这个限制设计师需要了解但不影响版本管理本身的价值。以下是一个简单的设计资产版本管理流程可视化用文字描述工作区修改 → git add → 暂存区 → git commit → 本地仓库 → git push → 远程仓库 ↑ git pull / git fetch从远程同步5. 面向设计师的常用 Git 命令速查日常设计资产管理并不需要掌握太多 Git 命令。下面是一份精简版速查表建议收藏。5.1 仓库操作操作命令初始化仓库git init克隆远程仓库git clone 远程地址查看远程仓库git remote -v添加远程仓库git remote add origin 远程地址5.2 提交操作操作命令查看状态git status添加单个文件git add 文件名添加所有文件git add .提交git commit -m 提交说明修改上一次提交说明git commit --amend -m 新的说明查看提交历史git log --oneline5.3 分支操作操作命令查看分支git branch创建并切换分支git checkout -b 分支名切换分支git checkout 分支名合并分支git merge 分支名删除分支git branch -d 分支名5.4 同步操作操作命令推送到远程git push origin 分支名拉取远程更新git pull origin 分支名抓取远程更新但不合并git fetch origin5.5 撤销与回退操作命令撤销工作区修改git restore 文件名撤销暂存区修改git restore --staged 文件名生成反向提交git revert 提交号回退到指定提交git reset --hard 提交号6. 常见问题与排查思路设计师在使用 Git 时会遇到一些典型问题。下面按问题现象、常见原因、解决思路列出。6.1 报错git 不是内部或外部命令 / 无法将“git”项识别为 cmdlet项目内容问题现象在 CMD 或 PowerShell 中输入git命令提示找不到该命令常见原因Git 安装时未加入系统 PATH 环境变量解决思路重新运行 Git 安装程序在 Adjusting your PATH environment 步骤选择 “Git from the command line and also from 3rd-party software”或者手动把 Git 安装目录下的cmd目录添加到系统环境变量 PATH 中预防方案Windows 安装时仔细阅读每个步骤不要一路默认。尽量使用 Git Bash 而不是 CMD6.2 报错fatal: not a git repository项目内容问题现象执行git status或git commit时提示当前目录不是 Git 仓库常见原因当前目录或上级目录中没有执行过git init解决思路先执行git init初始化仓库或者使用cd切换到正确的项目目录预防方案在执行任何 Git 命令前先确认当前所在目录是否符合预期6.3 提交时没有设置用户名和邮箱项目内容问题现象执行git commit时提示无法自动识别用户信息常见原因安装 Git 后没有执行git config --global user.name和user.email解决思路按前文全局配置步骤补齐配置预防方案新环境安装 Git 后的第一件事就是配置用户信息6.4 合并设计源文件时出现冲突项目内容问题现象合并分支时提示 CONFLICT文件无法自动合并常见原因两个分支中同一文件的不同修改同时存在设计源文件为二进制格式Git 无法自动合并解决思路手动选择保留某一个版本或者使用最新版本覆盖旧版本后重新提交预防方案对source/目录下的源文件约定“同一时间仅一人修改”的规则将可合并的文件JSON、SVG、Markdown与二进制文件分开管理6.5 误上传了大文件或敏感文件项目内容问题现象仓库体积急剧膨胀或不小心提交了包含账号密码的配置文件常见原因未提前配置.gitignore将不该提交的文件纳入了版本管理解决思路使用git rm --cached 文件从 Git 跟踪中移除如果敏感信息已经推送到远程需要立即修改密码/密钥并联系团队管理员清理远程历史可使用 BFG Repo-Cleaner 工具预防方案提交前一定执行git status确认将要添加的文件列表大文件使用 Git LFS 管理6.6 远程仓库连接失败或证书报错项目内容问题现象push/pull 时出现unable to access或证书相关的报错常见原因网络策略限制、代理设置错误、SSL 证书配置异常解决思路先检查网络连通性如果使用代理确认代理地址是否配置正确如果证书异常可联系管理员或临时使用 SSH 协议替代 HTTPS 协议预防方案在企业内网环境中优先使用 SSH 协议配合管理员分配的访问权限尽量避免个人修改全局证书配置6.7 设计文件版本过多导致仓库体积膨胀项目内容问题现象仓库体积迅速增长clone 和 push 都变慢常见原因设计源文件体积大且每次修改都产生新版本历史中积累了过多大文件解决思路将大体积源文件转移到 Git LFSLarge File Storage管理或者在依赖在线设计工具的团队中只把切图和文档放入 Git 仓库源文件保留在设计工具云端预防方案从一开始就明确仓库边界哪些文件进 Git哪些不进 Git写入 README7. 设计团队 Git 工作流最佳实践7.1 明确仓库边界不是所有设计文件都必须进 Git设计团队需要根据自己的工作流决定 Git 管理什么、不管理什么。以下是三种常见的仓库策略策略一全量资产仓库将源文件、切图、文档全部纳入 Git。适合本地工具为主PSD/AI/Sketch、文件体积可控的团队。策略二输出资产仓库依赖 Figma 等在线工具的团队源文件本身已经有云版本记录因此 Git 仓库只放切图、设计规范 JSON、Markdown 文档、图标 SVG。这种策略最轻量也最容易和前端协作。策略三设计系统仓库专门为 Design System 建立独立仓库包含颜色令牌、字体规范、组件切图、使用文档。前端、设计师都围绕这个仓库协作修改需要走分支评审流程。7.2 提交信息规范让历史记录可读提交信息是团队协作的“日志”。建议采用以下约定类型: 简述常见类型包括类型含义示例feat新增功能/资源feat: 新增支付成功页插图fix修复问题fix: 修正首页按钮禁用态颜色docs文档更新docs: 更新设计规范中的间距说明style格式或资源调整style: 图标统一改为圆角风格refactor重构不改变功能refactor: 调整切图目录层级提交粒度要适中。一次提交只做一件事不要把几十个无关改动混在一起。这样后续回溯时会非常方便。7.3 分支策略简单不等于低效设计团队不需要照搬复杂的 Git Flow。建议使用简约的模式main分支始终保留已确认可用的稳定版本。feature/xxx分支每个新功能或改版任务创建独立分支完成后合并回 main 并删除分支。release/xxx分支可选需要发布给开发时从 main 拉一个发布分支冻结修改。尽量不要在 main 上直接修改并提交。强制走“分支开发 → 合并回 main”的流程虽然刚开始觉得繁琐但习惯了之后会非常安全。7.4 与开发同学协作的正确姿势设计资产仓库最大的价值不在于“归档”而在于“打通”。推荐流程是设计团队在代码托管平台创建独立的design-assets仓库。前端项目通过 Git 依赖方式submodule 或包管理器引用设计资产仓库中的切图/规范文档。设计师更新切图后发起合并请求前端完成适配后拉取最新资源。这样整个流程就变成了“设计更新 → 提交 → 通知 → 前端拉取”不再需要手动传压缩包也避免了“你发我的还是旧版”这种尴尬。7.5 安全边界与权限管理设计资产同样是公司的重要知识产权建议在团队协作中做好权限控制设置仓库私有外部人员不可见。按角色分配权限设计师具备读写权限前端工程师可以只读或读写指定目录外包/实习人员使用只读权限。不要将机密设计稿、未发布的品牌物料提交到公开仓库。7.6 Git LFS设计师的大文件解决方案如果必须把 Sketch、PSD 这类大文件放进 Git 仓库强烈建议启用 Git LFS。Git LFS 将大文件替换为文本指针实际文件存储在 LFS 服务器上从而避免仓库无限膨胀。启用方式以 GitHub 为例# 安装 Git LFS git lfs install # 在仓库中指定大文件后缀 git lfs track *.psd git lfs track *.sketch git lfs track *.fig # 提交 .gitattributes 文件 git add .gitattributes git commit -m chore: 添加 Git LFS 跟踪规则注意Git LFS 有存储配额限制对于超大文件依然要谨慎。如果团队主要使用 Figma 这类在线工具源文件建议保留在云端Git 仓库只放轻量的切图和文档。8. 设计师学习 Git 的下一步路径对于设计师来说Git 是一个“入门容易、精通难”的工具。但好在日常设计中用到的高级操作并不多只要掌握了以下几件事就足以支撑绝大部分工作场景能够初始化仓库、添加文件、提交修改、推送到远程。能够创建分支、切换分支、合并分支。能够在需要时回退到历史版本。能够看懂提交历史和团队协作日志。能够使用.gitignore避免误提交无关文件。能够用图形化客户端完成以上操作命令行为辅助。下一步可以尝试的方向学习如何在 Figma 插件中调用 Git 能力把设计变量直接导出为代码仓库中的 JSON token。掌握 GitHub/GitLab 的 Pull Request / Merge Request 流程主动参与设计与开发之间的代码评审。尝试自己为团队搭建一套设计资产仓库把切图、规范、文档完整地管理起来。阅读 Git 官方文档中关于 reflog、cherry-pick、stash 等进阶命令的说明逐步提升“救场”能力。在实际项目中最优先关注的永远是提交前确认文件列表推送到远程前检查分支删除分支前确认是否合并。这三条习惯可以避免绝大多数事故。Git 本质上不是程序员的特权而是一种通用的协作规范。设计师掌握它并不意味着要转行写代码而是为自己的设计资产建立一套真正可靠的版本管理体系。当一个项目做了半年、一年之后你还能轻松找到半年前某个方案的设计稿并且知道它和现在的版本之间发生了什么变化你就会发现学 Git 的这点投入是值得的。如果本文对你有帮助可以收藏备用。下一步建议直接在你的电脑上试着创建一个仓库把自己的设计稿放进去体验一次完整的“提交-分支-合并-回退”流程。只有亲手操作过一遍才能真正理解 Git 的设计思路。