资讯详情

资讯详情

git clone 指定路径全攻略:从落点控制到稀疏检出与浅克隆

简介围绕Git克隆代码时的目录管理痛点整理了一份以PDF文档形式呈现的操作指南面向需要灵活指定克隆路径的Git初、中级开发者。文档从最基本的git clone命令讲起说明默认会在当前目录生成同名仓库目录的规则进而介绍通过追加目标路径将仓库克隆至指定盘符或目录的方法并完整演示Sparse Checkout模式克隆子目录及单个文件的具体配置流程覆盖git init、core.sparsecheckout开关、sparse-checkout文件编写等关键细节。资源仅含1个PDF文件整体大小77KB内容紧凑、随查随用。目前已有5456人学习浏览适合在项目目录混乱、希望保持工作区整洁或只需拉取仓库部分内容时参考能帮助快速理清克隆去向并掌握自定义路径的多种思路。1. git clone 指定路径代码到底被下载到哪了身边不少同事第一次执行git clone的时候盯着刷完的进度条愣住代码下载完了但不知道落在了哪个文件夹。如果你也搜过“git clone 指定路径”这个词说明你和我当初一样站在一个很简单、但文档里很少直说的问题面前。默认情况下Git 会把仓库建在“当前工作目录”里也就是终端执行命令时所在的位置问题就出在很多人不清楚自己“当前”在哪。以 Windows 为例按 WinR 输入cmd打开命令行窗口显示的路径通常就是 clone 落点。实际开发中不少人的终端是从 IDE 带出来的工作目录可能是某个项目文件夹clone 完仓库直接套进这个项目里目录层级一下子变乱。下面从默认行为讲起依次覆盖整个仓库落到指定目录的直接写法、Sparse Checkout 子目录拉取、DownGit 单文件夹方案以及几个我实际踩过的参数坑。适合想精确控制仓库落点的开发者也适合只需要大仓库其中某一个模块的场景。2. 基本 clone 与指定目录路径参数的四种写法与选路逻辑2.1 默认落点当前工作目录与仓库名的隐式约定先看最基础的命令# 不带任何路径参数Git 会把仓库放在当前目录下 git clone https://github.com/yourname/yourrepo.git执行完成后Git 在当前 shell 的工作目录下新建一个名为yourrepo的文件夹把所有仓库文件、提交记录、分支引用都放进这个文件夹。这里的“当前工作目录”和你在终端里执行的pwdLinux/macOS或者cdWindows CMD看到的是同一个位置。比如终端当前在/home/zhangsan/work代码就会落到/home/zhangsan/work/yourrepo不会跑到别的地方去。有两个容易被忽略的细节。第一Git 取文件夹名用的是 URL 最后一段去掉.git之后的字符串比如https://github.com/user/my-project.git会生成my-projectSSH 格式的gitgithub.com:user/api-gateway.git也会生成api-gateway。第二Windows 系统如果你用 CMDcd不带任何参数是显示当前目录在 PowerShell 里pwd也可以直接使用。这里我想强调一个习惯clone 之前先敲一次pwd或cd确认终端到底在哪个目录。很多人用 IDE 内置终端内置终端默认的工作目录往往是项目根目录你以为自己在某个空目录里实际上 clone 会直接把仓库塞进你当前打开的项目文件夹里嵌套关系乱了之后处理起来非常麻烦。2.2 直接指定目标目录绝对路径的正确写法如果不想让仓库落在当前目录git clone的第二个参数就是目标路径。这是最直接的“指定路径”用法# 将 jQuery 仓库克隆到 E 盘的 myJQuery 目录 git clone https://github.com/jquery/jquery.git E:/myJQuery/执行后 jquery 仓库的全部内容会被拉到E:\myJQuery\目录下。关于这行命令有几点要注意目标目录不存在时Git 会自动逐级创建。目标目录存在但为空时Git 也可以正常使用。目标目录存在而且里面有内容时Git 会拒绝执行提示fatal: destination path xxx already exists and is not an empty directory。路径分隔符在 Windows 下使用正斜杠/更保险。反斜杠在 Git Bash 里可能会被当成转义字符导致路径解析出问题。如果你用的是 Windows CMD反斜杠本身没问题但为了在不同终端之间切换时不踩坑我一般统一写成正斜杠。还有一种更常见的需求把仓库直接克隆进当前目录不额外建文件夹。这时候目标路径写一个小数点# 把仓库内容直接克隆到当前目录不创建子文件夹 git clone https://github.com/user/repo.git .这个写法常用来初始化一个新项目。比如你在一块空目录里打算写代码发现 GitHub 上已经有一个脚手架仓库想直接把它作为当前项目的起点就在这个空目录里执行上面的命令。执行完成后仓库文件直接散落在当前目录不会多套一层repo。2.3 相对路径与自定义文件夹名第二个参数同样支持相对路径# 在当前目录的 third-party 子目录下生成 repo 文件夹 git clone https://github.com/user/repo.git ./third-party/repo这条命令会在当前目录的third-party子目录不存在则创建下生成repo文件夹。需要理解的是第二个参数指向“仓库根目录本身”不是它的上一级。你想把代码放到third-party目录里就直接写./third-party而./third-party/repo则会多套一层文件夹。如果你想换一个本地文件夹名但远程仓库名保持不变也是直接写在第二个参数的位置# 本地文件名叫 jquery-source而不是默认的 jquery git clone https://github.com/jquery/jquery.git jquery-source这条命令会把代码放到jquery-source文件夹里本地名和远程仓库名不再需要一致。它适用于一种实际场景远程仓库叫platform-core但你想在本地简写成core或者远程历史中曾经改过仓库名旧项目里到处引用的路径都是另一个名字你希望本地保持和之前一致。关于相对路径还有一个细节git clone url ./repo和git clone url repo两者行为基本一致。但如果你写的是~/repo这种带波浪号的路径部分 Windows 终端不会自动展开波浪号直接用绝对路径更省心。另外如果目标路径本身就是一个已经存在的符号链接Git 会按符号链接指向的实际位置落盘这在日常开发里不太会遇到但一旦遇到会让人一脸懵识别方式是在落盘前用ls -ld检查目标路径是否为链接。2.4 克隆前确认与克隆后验证我的固定流程把以上写法串成一个固定的操作流程我一般是这么做的# 第一步确认当前路径避免 clone 完不知道代码在哪 pwd # 第二步创建目标目录如果确实需要提前建好 mkdir -p /home/zhangsan/work/jquery-source # 第三步克隆到指定路径 git clone https://github.com/jquery/jquery.git /home/zhangsan/work/jquery-source克隆完成之后紧接着做两个验证动作cd /home/zhangsan/work/jquery-source # 查看远程地址确认是从哪个远程拉下来的 git remote -v # 查看最近三条提交确认历史完整 git log --oneline -3git remote -v输出远程仓库地址确认这个仓库的来源。曾经有同事把两个地址写串了等发现的时候已经在错误的仓库上做了一天改动。git log --oneline -3能快速确认提交历史是否完整拉取如果输出为空说明仓库可能还没有任何提交记录或者你克隆的是一个空仓库。这个固定流程看起来只多花十几秒但在多分支、多仓库的环境里非常值得。很多生产事故的根源其实就是落点搞错、仓库搞错验证这一步也算是一种低成本的事故预防手段。3. Sparse Checkout 实战只拉取仓库中指定子目录的完整流程3.1 Sparse Checkout 原理它到底省了什么没省什么某些场景下整个仓库 Clone 下来是浪费的。举个例子你在开发一个 monorepo 里的user-service模块仓库一共 20GB其中大部分是其他模块的历史镜像和构建产物。你只想把user-service目录拉到本地写代码这时候 Sparse Checkout 就有了用武之地。Sparse Checkout 是 Git 1.7.0 开始引入的功能它的作用是在初始化本地仓库后通过.git/info/sparse-checkout文件写你要检出的路径模式再执行 pull 或 checkout让 Git 只把匹配到的文件放到工作区。Git 1.7.0 以前这个功能不存在网上很多老教程提到“无法只克隆一个目录”基本都是在那个版本背景下说的。必须澄清一个常见误解Sparse Checkout 不会让 Git 只下载部分数据。在完整克隆full clone模式下git pull还是会把仓库里所有的 commit 对象和树对象拉取到.git目录里只是工作区里只出现你指定的那些文件。换句话说省的是磁盘上的工作区空间和日常 checkout 的时间省不了网络传输时间和.git目录的体积。很多第一次接触这个功能的人以为它能当“部分下载”用结果发现.git还是占了几个 GB这就是预期没对齐。想真正省网络流量需要把浅克隆shallow clone和 Sparse Checkout 结合起来使用。浅克隆的参数是--depth 1它只拉取最近的若干条提交记录.git目录会小很多。这部分的组合操作我放在最后一章单独说这里先聚焦 Sparse Checkout 本身。3.2 标准操作六步从 init 到 pull假设你想从https://github.com/mygithub/test仓库里只拉tt子目录。完整流程如下mkdir test cd test # 初始化本地仓库 git init # 开启 sparse checkout 开关 git config core.sparseCheckout true # 设置要克隆的子目录路径注意后面的斜杠 echo tt/ .git/info/sparse-checkout # 关联远程仓库这里换成你的实际仓库地址 git remote add origin gitgithub.com:mygithub/test.git # 拉取远程分支 git pull origin master逐条拆开解释。git init在test目录里创建空白仓库。必须先有.git目录后面一行git config才有地方写入配置。git config core.sparseCheckout true打开 sparse checkout 开关。注意这里不能加--global否则它会作用到你机器上的所有仓库你其他项目的 clone 行为都会受影响。这个配置是仓库级的只对当前仓库生效。echo tt/ .git/info/sparse-checkout把tt/写入配置文件。路径模式是相对于仓库根目录的如果远程仓库里目录路径是frontend/tt就要写frontend/tt/。这一步写错会表现为“什么文件都没有”后面我会在避坑章节详细展开。git remote add origin关联远程仓库。这里使用 SSH 地址的前提是本地已经配置好 SSH 密钥否则会出现权限认证错误。没配置密钥的直接用 HTTPS 地址git remote add origin https://github.com/mygithub/test.git。git pull origin master把远程分支拉到本地。如果你的仓库默认分支叫main请把master换成main。更稳妥的做法是直接执行git pull origin让 Git 自动使用远程仓库 HEAD 指向的默认分支这样就省去了手工分辨分支名的麻烦。执行完成之后用ls验证# 期望输出tt ls如果这里看到的不是tt检查一下配置文件里写的路径是否和仓库实际结构完全一致。还有一点需要提醒git pull在部分配置下可能因为没有设置branch.origin.HEAD而提示 detach这时候再执行一次git checkout通常就能把工作区文件正确拉出来。3.3 多目录与文件级稀疏检出sparse-checkout 文件的写法规则要同时检出多个目录就在 sparse-checkout 配置文件中逐行写入路径# 追加两个目录到配置 echo src/ .git/info/sparse-checkout echo docs/ .git/info/sparse-checkout # 刷新工作区让配置生效 git checkout执行git checkout后src和docs两个目录会同时出现在工作区。注意不需要重新执行git pull只需要git checkout就会让工作区跟随新的 sparse-checkout 配置刷新。这个机制理解之后后续想加目录就变得很轻量。如果要精确到单个文件写法同样简单直接在配置文件中写文件路径tt/file1.txt tt/file2.md配置文件里每一行代表一个路径模式。对于目录行尾加上/表示“这个目录下面的所有内容”对于文件直接写完整路径。传统的 Sparse Checkout非 cone 模式还支持*通配符比如tt/*.js这种写法可以只匹配tt下的 JS 文件。但要注意通配符的匹配范围是路径片段写src/*/test和正则表达式的逻辑并不完全一致。从 Git 2.26 开始官方引入了 cone 模式操作上手感更好# 初始化 cone 模式 git sparse-checkout init --cone # 直接指定要检出的目录写法更简洁 git sparse-checkout set ttgit sparse-checkout set tt会把tt/写入配置并且自动清理配置文件里之前存在的其他路径。这是“只检出指定目录”语义更清晰的写法。但 cone 模式的路径规则和传统写法有些差异比如 cone 模式下你写frontend/tt会生效但如果你写的是*这类通配符在 cone 模式下可能不会按预期工作。老版本还是手动写配置文件更直观。一个容易忽略的细节如果仓库里同时用到了 submoduleSparse Checkout 不会自动处理子模块目录。子模块有自己的.git目录和内部指针即使是 Sparse Checkout 命中了子模块路径仍然需要额外的git submodule update --init完成内容填充。我自己就遇到过这样一个仓库主仓库只包含文档和子模块引用Sparse Checkout 命中子模块目录后工作区看起来是空的最后查了二十分钟才发现是 submodule 没有被初始化。3.4 恢复全量检出的方法如果你后续想取消 Sparse Checkout 限制、恢复完整检出Git 2.26 以上可以这样# 关闭 sparse checkout工作区恢复为完整内容 git sparse-checkout disable低版本手动操作把配置文件内容替换成*再执行 checkout# 将配置改为匹配所有路径 echo * .git/info/sparse-checkout # 刷新工作区拉取全部文件 git checkout注意是单个*字符。它用来匹配仓库中的所有路径Git 会把全部文件都放到工作区。恢复全量检出后建议顺手做一次git status确认没有未跟踪的本地文件残留。之前我在一个项目里执行完git checkout发现工作区里有些文件显示为 deleted——那是原先在 Sparse Checkout 模式下被隐藏、现在又恢复的文件实际上内容并没有丢失只是文件系统层面的状态切换git status能帮你把这些变化看清楚。这个现象在恢复 Sparse Checkout 时很常见不是数据损坏。4. 单文件夹下载的另类方案DownGit 与在线打包工具4.1 DownGit 的出现背景与适用场景前两章讲的是 Git 命令行能力。但有一类用户根本不需要 Git 命令他想从别人的 GitHub 仓库里只下载某一个目录下载完解压直接用不在意仓库历史和版本控制。这类需求很常见。比如设计团队从开源的图标仓库里拉取某个主题的目录或者技术写作者从别人的博客仓库里下载docs文件夹借鉴格式。在这种场景下Sparse Checkout 还需要安装 Git、配置认证学习成本显然偏高。DownGit 这类工具把整个流程变成三步粘贴仓库地址、选中目录、点击下载。它通过 GitHub API 读取仓库文件树在服务端把对应目录压缩成 zip浏览器直接下载。整个过程不要求本地有 Git 环境也不用理解分支、远端这些概念。原项目曾经存在一些可用性问题也有人把资源改到国内 CDN 重新部署了一份访问速度会明显快一些。如果你打开原页面加载很慢或者点击下载没反应可以优先尝试这类分流版本。判断一个 DownGit 实例是否可用有一个很直接的办法打开页面后随便粘贴一个公开仓库地址看文件树能不能在三五秒内加载出来。如果一直转圈说明服务端 GitHub API 请求受到限流或网络阻塞直接换一个实例。4.2 使用流程与部署注意点DownGit 的标准使用流程我整理成一张表步骤操作说明1打开 DownGit 页面输入框在页面顶部2粘贴 GitHub 仓库 URL支持任意公开仓库3在文件树中选择目标目录也可以直接点目录进入后复制当前 URL4点击 Download 按钮服务端开始打包等待 zip 生成5解压 zip获得该目录内容实际操作中有一个提高成功率的技巧如果你只想下载某个子目录可以直接在仓库 URL 后面拼上目录路径比如https://github.com/user/repo/tree/main/src/utils然后再粘贴到 DownGit 里它通常能直接识别并定位到对应的目录。这样可以省掉在文件树里一路点击的步骤。如果你要自己部署一套 DownGit 给团队用有几个点需要提前处理。第一GitHub API 匿名请求有每小时 60 次的限流团队多人公用这个额度很快会耗尽需要在服务端配置一个带有适当权限的 GitHub token。第二如果团队用的是私有仓库token 还必须开启对私有仓库的读取权限。第三服务端打包这个动作对内存和带宽都有要求目录里几千个文件时打包时间会明显变长超时后会返回空白页面。还有一点DownGit 打包时对文件名的处理不一定兼容所有系统。遇到过 zip 里包含特殊字符比如#、?的情况Windows 解压时直接报错。遇到这种问题先用在线解压工具或者 Linux 环境解压然后把文件重命名成合规名字再拷回 Windows。这个坑比较冷门但真遇上还挺烦人的。4.3 三种方案的选择对比把这个系列的方法放在一起对比可以这样看对比项完整 clone 指定路径Sparse CheckoutDownGit本地是否需要 Git需要需要不需要是否需要认证取决于仓库权限取决于仓库权限仅限公开仓库是否保留提交历史是是对象完整否是快照是否保留 .git 目录是是否适合场景日常开发、需要历史大仓库中开发某个模块快速下载一个目录做参考从这张表能看到一个本质差异DownGit 拿到的是“静态快照”而 Git 系列方法拿到的是“可继续开发的工作副本”。如果你的目的是写代码、提交、合并必须用 Git 系列方法如果只是想把某个目录拿下来看看或参考DownGit 显然更快。我自己的判断标准是只要还在代码仓库里做编辑就用git clone指定路径只有一种情况例外——当仓库特别大而我只想拿一个目录里的几个文件做对照的时候DownGit 能节省大量等待时间。5. 避坑与排查git clone 指定路径的六个隐藏问题5.1 路径里有空格或中文字符命令直接报错现象在 Windows 命令行里执行下面的命令报错fatal: could not create work tree dir或者unable to find remote helpergit clone https://github.com/user/repo.git C:\My Projects\demo还有人在路径中带了中文字符比如E:\项目代码\demo执行时同样出现问题尤其是 Git Bash 环境。原因空格是命令行解析的天然分隔符。Git 程序接收到C:\My和Projects\demo两个参数第二个路径自然对不上。中文字符的问题则和终端编码有关Windows CMD 默认代码页和 Git 内部编码不一致时路径解析就乱了。解决给路径加双引号把整个路径作为一个参数传给 Gitgit clone https://github.com/user/repo.git C:\My Projects\demo中文字符路径仍然不推荐。虽然一些新版 Git 能正常处理但不同终端、不同插件组合下表现不稳定团队协作时也容易引发编码混乱。最省心的方式是把仓库目录挂到纯英文路径下比如E:\git-repos\demo。5.2 目标目录非空Git 拒绝克隆现象执行git clone url ./existing-dir提示fatal: destination path existing-dir already exists and is not an empty directory.原因第二个参数指向的目录已经存在文件Git 在 clone 时不希望在一个非空目录里覆盖既有内容所以直接拒绝。解决有两种处理方式。第一种最简单先用空目录作为目标或者把目录里的冲突文件挪走再重新执行克隆。第二种如果你确实想把远程内容合并到现有的非空目录里可以先在目录里执行git init再git remote add origin url最后git pull origin main。但这种方式要小心提交历史冲突两条分支如果没有共同祖先pull 会报refusing to merge unrelated histories需要加--allow-unrelated-histories参数而这个操作可能带来大量合并冲突。所以除非真的有合并诉求否则优先选择第一种方式。5.3 Git 版本太低Sparse Checkout 配置不生效现象手动配置了core.sparseCheckout true也在.git/info/sparse-checkout里写入了路径但执行git pull之后整个仓库的文件全都出现在工作区好像配置没有生效一样。原因Sparse Checkout 是 Git 1.7.0 引入的如果本地 Git 版本低于 1.7.0core.sparseCheckout配置就不会起作用。现在多数操作系统自带 Git 都高于 2.x但一些老旧的服务器或者 Windows 上古版本 Git 仍然可能是 1.8 甚至更早。解决先查版本git --version如果版本低于 1.7.0升级 Git 后重新配置。升级后原有仓库的自动配置不会有问题但保险起见还是重新走一遍 sparse checkout 流程。这里也提醒一句检查.git/info/sparse-checkout文件是不是存在某些情况下.git/info目录不会自动存在需要手动创建不然echo tt/ .git/info/sparse-checkout会直接写入失败。5.4 sparse-checkout 路径写错工作区一片空白现象执行完配置和 pull 之后工作区里什么都没有。你以为克隆失败了但git log能看到提交记录.git目录也正常存在只是没有工作区文件。原因Sparse Checkout 配置文件里写的路径和仓库实际目录不完全一致。比较典型的有几种情况漏了末尾的/只写了目录名但没有带上父目录大小写不匹配或者仓库里根本没有这个路径。Git 对这种“匹配不到”的情况不会给任何报错它是静默的这也是这个问题最难排查的原因。解决先用git ls-files查看索引中路径的准确写法git ls-files | head -50这条命令会列出 Git 索引里所有文件的路径。对照真实文件路径修改.git/info/sparse-checkout# 调整配置后刷新工作区 echo frontend/tt/ .git/info/sparse-checkout git checkout如果还不行查看一下配置文件内容cat .git/info/sparse-checkout确认每一行路径之间不要有多余的空格Git 的路径匹配是精确匹配。空格在配置文件里也算一个有效字符这类问题用眼睛很难发现。5.5 分支名不一致git pull 找不到远程引用现象按照教程执行git pull origin master报错fatal: couldnt find remote ref master原因远程仓库的默认分支是main而不是master。GitHub 在 2020 年之后新建仓库默认分支都是main很多教程还停留在 master 时代直接套用就出问题。解决执行git remote show origin查看远程默认分支或者直接用git pull origin main。更简单的是不写分支名git pull origin会让 Git 使用远程 HEAD 的默认分支。这条命令在不同 Git 版本下行为一致识别远程 HEAD 后自动拉取对应分支省去每次确认分支名的麻烦。如果你用的是 SSH 方式还可以在拉取后顺手执行git branch -vv确认本地分支和远程分支的跟踪关系是否正确。5.6 Windows “找不到指定的路径”不一定是仓库路径的问题现象在 Windows 下执行git clone或者打开 IDE 里的 Git 功能弹出“系统找不到指定的路径”有时候还会出现“visual studio无法启动程序找不到指定路径”这类完整提示。原因这类提示经常不是仓库路径的问题而是环境变量 PATH 中的 Git 安装路径已经失效。Git 安装在本地某个位置后如果后来把 Git 安装目录移动了位置PATH 里的旧路径就成了找不到的死路径。另外Windows 的长路径限制也会触发类似表现某些深层级路径超过 260 个字符时Git 的命令会失败。解决确认 Git 可执行文件的真实位置where git然后把输出路径更新到系统环境变量的 PATH 中。长路径问题可以通过在 windows 系统设置中开启长路径支持或者在 git config 中设置git config --global core.longpaths true这个配置解决的是 Windows 下 Git 对超过 260 字符路径的默认拒绝行为改完之后对已经存在的仓库可能还需要重新 clone 一次才能完整生效。如果where git输出的位置和你预期不一致还有一种可能系统里注册了多个版本的 Git顺序靠前的那个是旧版本导致命令总是执行到旧版。6. 进阶技巧浅克隆与稀疏检出的组合以及更稳的落点验证6.1 浅克隆 Sparse Checkout把仓库体量真正降下来前面提到过单独使用 Sparse Checkout 只能减少工作区文件数量不能减少 .git 目录大小。如果你的目标是“从大仓库里快速拉取最新版模块”把浅克隆和 Sparse Checkout 组合起来是最实用的做法mkdir mymodule cd mymodule # 初始化仓库 git init # 开启 sparse checkout git config core.sparseCheckout true # 指定要检出的目录 echo mymodule/ .git/info/sparse-checkout # 关联远程仓库 git remote add origin gitgithub.com:bigcorp/monorepo.git # 使用 --depth 1 只拉取最近一条提交 git pull --depth 1 origin main--depth 1让 Git 只下载最近 1 条提交的完整快照加上 Sparse Checkout 只检出指定目录两个机制叠加之后下载的数据量和磁盘占用都会明显下降。这组合是我处理超大仓库时的首选体验上比完整克隆快了十倍以上。组合之后要注意版本管理的边界浅克隆仓库里没有完整历史无法git log回溯太久也无法直接做基于旧提交的 diff。如果你只是开发某个模块且不关心历史这个边界可以接受如果你需要长期维护这个目录并提交代码建议去掉--depth 1。6.2 验证落点是否真的在指定路径下代码拉完之后我用一分钟做三件事确认落点完全符合预期# 显示当前所在路径 pwd # 显示 Git 仓库根目录的绝对路径 git rev-parse --show-toplevel # 查看工作区状态 git statusgit rev-parse --show-toplevel会输出当前仓库根目录的绝对路径它比pwd更准确即使你此时站在子目录里也能显出根路径。git status则能告诉你工作区当前的状态是否干净是否有未跟踪文件、是否处于 detached 状态。每次 clone 完我强制自己走一遍这三个命令早就养成了习惯——不管是从 GitHub 拉代码还是从公司内部 GitLab 仓库拉分支落点问题再也没有带来过惊讶。如果你用的是 Sparse Checkout 浅克隆组合还可以追加一个验证git count-objects -vH显示 size-pack 的数值时和完整克隆时的预期比一下如果明显小很多说明浅克隆生效了。这个命令输出的 .git 对象实际大小完全可以作为体积控制效果的直观验证。希望帮到你。本文还有配套的精品资源点击获取
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →