Git Clone 深度实践：从基础命令到认证与优化技巧

第一次从终端执行git clone的时候，我对着那行https://github.com/某开发者/demo-project.git犹豫了几秒，回车之后看着进度条走完，觉得这东西简单得有点不像话。真正让我改观的是后来进了团队项目：要同时维护好几个仓库、在几台设备之间切换认证方式、偶尔还要在不太稳定的网络条件下搬几十GB的大仓库。这时候才意识到，“clone”根本不是“把代码下载到本地”这么简单——它是你本地仓库和远程仓库所有后续协作关系的起点，remote 怎么配、认证走哪条链路、历史记录拉多少、子模块带不带，每一个细节都会被之后每天的pull、push、branch反复放大。

这篇文章把我这些年围绕“终端 git clone”踩过的坑、总结出的操作习惯和排查思路完整整理了一遍。从基础命令拆解、HTTPS 和 SSH 的认证选择，到大仓库和慢网络下的优化手段、克隆后的分支管理，再到几个实际遇到过的问题复盘。不管你刚接触 git 不久，还是已经用了一段时间但没系统梳理过其中的细节，应该都能找到能直接落到日常操作里的东西。

1. 终端克隆的基本盘：一条命令的前世今生

1.1 为什么几乎所有开发场景都绕不开 clone

很多人第一次接触git clone是在某个开源页面上看到一排绿色的“Code”按钮，按钮里有个复制链接的选项。复制、粘贴、回车，代码就“下来”了。这个印象没有错，但理解得太浅，后面会吃亏。

git clone不是单纯的下载工具，它在底层做了三件事：第一，把远程仓库的对象数据库完整复制到本地.git目录；第二，自动为你创建一个名为origin的远程仓库引用，并且把对应的 URL 写进配置；第三，根据远程仓库的默认分支，在本地创建一个同名分支并完成首次检出，让你直接得到一个可工作的目录。

这也是它和“Download ZIP”最本质的区别。下载压缩包只拿到某个时间点的文件快照，没有提交历史、没有分支引用、没有 remote 配置，你在这份代码上做任何修改都无法直接同步回远程。而git clone得到的是一套完整的 git 仓库，你随时可以git pull拉取更新、git push推回你的提交，甚至通过git log追溯项目从第一次提交至今的演变过程。

我给过不少新手同事一个直观的对比，他们听完基本就清楚了：

所以在一个团队里，只要是正经做协作开发，几乎没有人用 ZIP 的方式来交接代码。正确姿势永远是拿到 URL 之后在终端里执行git clone，然后在这个基础上展开工作。

1.2 克隆之前的三个环境确认

我是一个习惯“先花十秒钟确认环境，再执行命令”的人。这不是啰嗦，而是git clone这类网络操作一旦中途失败，留下的半成品目录收拾起来比想象中麻烦。所以建议你至少检查三件事。

第一，git 是否真的装好了。在终端里执行git --version，能输出版本号说明没问题。这里有个小陷阱：有些图形化工具自带了 git，但在系统终端里直接敲git却提示找不到命令，原因是工具没有把 git 的可执行文件加入 PATH。Windows 上尤其常见，安装 git 客户端的时候记得勾选“添加到 PATH”之类的选项，macOS 上可以看 /usr/bin/git 是否存在，Linux 则取决于包管理器安装是否完整。

第二，网络连通性。很多人在 clone 失败后才开始排查网络，其实有一种更轻量的探测方式：git ls-remote <仓库URL>。这个命令只读取远程仓库的引用信息，不会创建本地目录，速度很快。它能同时验证两件事：你的网络能不能到达远程主机、你的凭证有没有权限读取这个仓库。如果git ls-remote都能正常返回分支列表，那基本可以排除网络和权限问题，放心执行 clone。

第三，磁盘空间。du -sh .和df -h是检查当前目录和文件系统的常用命令。一个看起来“没多大”的仓库，克隆之后可能非常胖，因为.git里保存了所有历史版本的对象数据。尤其是那些长期维护的大型项目，历史里可能混入了被删除的大文件、二进制资源，clone 下来的总量往往是工作区文件的数倍。硬盘只剩几个 GB 就打算克隆一个大型仓库，大概率会在半路崩溃。

2. 从零开始的一次克隆：HTTPS、SSH 与认证细节

2.1 HTTPS 克隆 vs SSH 克隆怎么选

看到一条git clone命令，第一件要决定的事就是用 HTTPS 地址还是 SSH 地址。两者都能完成 clone，但后续的使用体验差异很明显。

HTTPS 地址形如https://github.com/某组织/某项目.git，它的优点是配置门槛低，浏览器里复制下来就能直接用，首次 clone 时会让你提供凭证（用户名加访问令牌）。缺点是每次涉及到需要权限的操作时，认证信息往往要通过凭证管理器保存或重新交互，对自动化脚本不太友好。而且现在多数平台已经不支持用账户密码直接走 HTTPS 认证了，必须创建个人访问令牌（Personal Access Token），令牌有过期时间，需要定期维护。

SSH 地址形如git@github.com:某组织/某项目.git，它的核心是一对密钥。配置完成之后，后续所有 git 操作都是无感的，不需要反复输入凭证，也没有令牌过期的问题。缺点是首次配置步骤多一些：生成密钥对、把公钥添加到平台账户、测试连接。换个新电脑还得再来一遍。

我的选择逻辑很简单：长期使用的个人电脑，一律 SSH；临时容器、CI 环境、只打算看一眼代码的场景，用 HTTPS 加令牌。你可以按自己的实际情况来，但别两边混着用还给搞混了。

2.2 SSH 密钥的完整配置流程

SSH 的首次配置其实就那么几步，每一步都值得认真做，我来按实际操作的顺序拆开讲。

生成密钥对，我推荐 ed25519 算法，性能和安全性都很均衡：

ssh-keygen -t ed25519 -C "你的备注信息"

执行之后会问你要把密钥放在哪里（默认~/.ssh/id_ed25519）以及是否设置口令（passphrase）。如果你在多台设备上使用，建议加一个口令，防止私钥文件泄露后直接被滥用。注意输出内容中有个随机的 key fingerprint，那是给你的密钥一个“指纹标识”，一会儿测试连接时会用到。

接着把私钥加入 ssh-agent，让你当前的 shell 会话能使用这把密钥：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

然后查看公钥内容并复制到平台账户的 SSH Keys 设置页面里：

cat ~/.ssh/id_ed25519.pub

公钥是公开的，可以放心复制。私钥文件永远不要发给别人，也不要上传到任何代码仓库。

最后测试连接：

ssh -T git@github.com

如果配置正确，会收到一条类似“Hi 用户名！你已成功认证”的提示。注意这里认证的用户名是跟随你公钥在平台上注册的账户来的，并不以命令中的git为准。

还有两个容易被忽略的细节：一是~/.ssh目录和私钥文件的权限要收紧，目录是 700，私钥是 600，macOS 和 Linux 上如果权限过宽会直接报错。二是多把密钥同时存在时，ssh 可能选错身份文件，这时就需要在~/.ssh/config里按 Host 区分，这个后面踩坑部分会细说。

2.3 令牌认证与凭证存储的取舍

HTTPS clone 用令牌，像是我前面说的那样，先在平台设置页面生成一个 Personal Access Token，按需勾选权限范围，比如读取代码库内容只需要repo范围内的读权限，做自动化发版可能还需要 workflow 等权限。令牌生成后会显示一次，之后就不再显示，所以生成时就要复制保存好。

克隆的时候可以直接把令牌拼在 URL 里用，比如https://用户名:令牌@github.com/某组织/某项目.git，但我强烈不建议这么做，因为 URL 会被保存在.git/config文件里，一旦仓库目录被分享或者日志被截取，令牌就泄露了。正确的做法是让 git 使用凭证管理器帮你存储和回填认证信息。

git config --global credential.helper决定了凭证怎么存。每个平台都有默认的凭证管理器，通常不需要额外配置。如果你发现每次 clone 都要重新输入凭证、或者输入了一次错误的凭证之后一直被缓存挡住，可以手动清理凭证缓存，具体路径因操作系统而异，Windows 上一般在操作系统自带的“凭据管理器”里能找到对应条目，macOS 则存在“钥匙串访问”里。

此外还有一种更可控的临时方案：设置GIT_ASKPASS指向一个提供密码的脚本，适合在 CI 里用环境变量方式注入令牌，但日常开发没必要这么做。

2.4 认证失败时的排查顺序

认证类报错是最容易让人原地打转的，因为同一个现象背后可能有四五种原因。我给自己定了一个固定的排查顺序，强烈建议你也这么做。

第一步，确认 remote 地址本身没有错。很多“认证失败”其实是地址写错，比如仓库名大小写、组织名拼写、或者把 HTTPS 地址和 SSH 地址混用了。先看git remote -v。

第二步，测试底层运输层。SSH 连接执行ssh -T git@github.com，HTTPS 连接执行git ls-remote <URL>。这一步能告诉你网络通不通、凭证对不对。如果是 SSH 但提示Permission denied (publickey)，接着执行ssh-add -l看私钥是否被加载；如果列表是空的，说明 agent 里没有密钥，要么ssh-add添加，要么检查密钥路径是否对。

第三步，检查令牌或密钥的权限范围。HTTPS 场景注意令牌是否过期、scope 是否覆盖了目标仓库；SSH 场景检查公钥是否真的绑定了对应账户，以及该账户对你 clone 的仓库是否有访问权限。这里有个非常迷惑人的现象：当你对一个无权访问的私有仓库执行 clone，有些平台给的提示不是“没有权限”，而是“仓库不存在”。这不是骗你，是为了避免泄露私有仓库的存在性。所以看到 “Repository not found” 时，先想想当前凭证对应的账户是不是该仓库的成员。

最后如果需要看更详细的握手过程，可以临时开启 debug 输出：

GIT_SSH_COMMAND="ssh -v" git clone <SSH地址>

这一招能看到 ssh 加载了哪个密钥文件、走了哪个 Host、最后在哪一步被拒绝。平时藏着，排障的时候特别好用。

3. 大仓库和慢网络下的克隆优化实践

3.1 浅克隆：--depth 参数到底省了什么

并不是所有时候都需要把仓库的完整历史拉下来。很多时候你只是想看一眼代码、跑个测试、或者对某个开源项目做短期调研，完整历史只会拖慢一切。

浅克隆就是只拉取最近 N 次提交的内容，用法是git clone --depth=1 <URL>，表示只要最新的一次提交。做完之后git log里只有那一条记录，--depth=N就表示最近 N 条。对一个动辄几万次提交的大型项目来说，浅克隆能显著节省下载流量和本地磁盘占用，仓库 checkout 速度也快得多。

代价是什么呢？首先是历史的缺失，git blame、git log -S这类依赖历史的操作会受限；其次，当你后续想彻底变回完整仓库时，需要执行git fetch --unshallow，这一步会重新补全所有历史对象，网络和磁盘开销会反扑回来。

我给个实操建议：探索陌生项目时先用--depth=1进场，确认这个项目值得长期关注和修改之后，再用--unshallow补齐历史。不要一上来就把所有历史都拉完，这是在为一个“还没确认的需求”买单。

3.2 按需拉取：稀疏检出与文件过滤器

浅克隆控制的是“提交数量”，还有一种理念控制的是“文件范围”，就是部分克隆和稀疏检出。

部分克隆在执行 clone 时并不把仓库里所有文件的内容对象都拉下来，而是只拉取提交和目录树结构，具体文件等用到时再按需下载。命令很简单：

git clone --filter=blob:none <URL>

这里的blob就是 git 对象体系里真正保存文件内容的对象类型。blob:none表示暂时不下载任何文件内容，只下载提交对象和目录树对象。适合单体仓库（monorepo）里目录结构复杂、实际用到的路径有限的场景。

在此基础上，配合稀疏检出只检出部分目录到工作区：

git sparse-checkout init --cone git sparse-checkout set 项目目录A 项目目录B

它的原理是在.git/info/sparse-checkout里配置允许检出的路径规则，工作区只出现这些目录。对磁盘占用和每次 checkout 的速度都有明显改善。不过要记住，这只影响工作区文件，缺的文件在你真正需要时仍会触发网络下载，所以别指望它替代真正的模块拆分。

如果你确定一辈子只需要默认分支，也可以加上--single-branch：git clone --single-branch <URL>。这样不会为其他分支建立 remote-tracking 引用，本地引用更干净，fetch 更新时也更快。

3.3 克隆中断后的恢复策略

网络不稳的时候，大仓库 clone 很容易在中途断掉。这时你会在当前路径下看到半成品目录，直接再执行一次 clone 可能报 “directory exists and is not an empty directory”，很多人这时候就选择删掉重来。

删掉重来当然可行，但如果仓库很大、已经下了一大半，我更推荐把这次失败利用起来。进入半成品目录看.git是否已经存在。如果存在，先添加 remote 然后继续 fetch：

cd 半成品目录 git remote add origin <URL> git fetch origin HEAD git checkout -b main origin/HEAD

有些版本下 clone 中断后虽然.git不完整，但对象数据库里的东西还能用，git fetch会基于已有对象做增量补充，比重新下载省不少流量。

另外两个最实用的配置，第一个是让 git 不要因为网络短暂低速就直接放弃：

git config --global http.lowSpeedLimit 0 git config --global http.lowSpeedTime 999999

第二个是调大 HTTP 缓冲，避免大的 POST 请求被中间设备截断：

git config --global http.postBuffer 524288000

这里我把http.lowSpeedLimit设成 0，等于禁用了低速中止机制，代价是如果网络真的完全断了，你可能要等更久才收到失败提示。看你的场景权衡。

3.4 针对大仓库的 git 配置调优

除了上面的低网速配置，还有几个参数值得关注。core.compression控制 git 压缩对象时使用的压缩级别，默认值通常是 0 或 1（取决于版本和场景），把它调高可以减小传输体积，但会占用更多 CPU。老机器上压缩反而可能拖慢整体速度，新手不要盲目调。

还有一个和 clone 关系密切的配置是git config --global protocol.version 2。协议版本 2 让服务器可以更精确地响应 fetch 请求、减少冗余数据，新版 git 默认已经启用，但如果你用的是很旧的环境，手动确认一下没坏处。

对于直接可见的大仓库，还可以在 clone 时临时传入配置，而不污染全局设置：

git clone --config core.compression=9 --config http.postBuffer=524288000 <URL>

这样配置只对这次克隆出来的仓库生效，干净利落。

最后提醒一点：如果仓库里有大量小文件，clone 过程中最耗时的往往不是网络而是文件系统写入。在 Windows 上，安全软件的实时扫描会对每个新写入的文件做检查，明显拖慢 checkout 速度；临时把项目目录加入扫描白名单，能让 clone 时间大幅缩短。这个属于环境调优，我自己试过，效果立竿见影。

4. 克隆后的第一件事：从 remote 到分支管理

4.1 clone 自动带来的 remote 和分支关系

很多人 clone 完就立刻开始改代码，其实应该先花几秒确认 git 帮你生成了什么。执行git remote -v会看到名为origin的远程仓库，URL 就是克隆来源。执行git branch -vv会看到本地分支和远端分支的跟踪关系，显示类似：

* main 1a2b3c4 [origin/main] 初始化项目

这里的[origin/main]表示本地main分支跟踪的是origin/main。这一行信息包含了后面所有pull和push行为的默认行为逻辑，值得看懂。

再看一眼git remote show origin，它会列出远程仓库的 HEAD 指向哪个分支、本地跟踪分支有哪些、哪些远程分支已经过期。这些都是 clone 之后“免费”获得的信息，不看白不看。

4.2 上游同步与 pull 的常见误区

clone 完成后最常见的日常操作是git pull，但这个命令其实是个组合动作：先git fetch从远程拉取新提交，再把远程分支合并到当前分支。至于怎么合并，是生成一个合并提交（merge），还是在当前分支上“重放”你的本地提交（rebase），取决于你的配置和习惯。

新手最容易困惑的是看到这样一段提示：

Your branch and 'origin/main' have diverged, and have 1 and 2 different commits each, respectively.

意思是本地有 1 个远程没有的提交，远程有 2 个本地没有的提交。此时git pull默认会创建一个合并提交，把两边历史拧在一起。如果你希望历史更线性，可以执行git pull --rebase，本地提交会被逐个应用到远程分支最新提交之上。

一个被我反复安利的操作是，在全局配置里设置默认行为：

git config --global pull.rebase true

这样一来git pull默认走 rebase 模式，提交历史干净得多。当然，如果你在小团队里更喜欢保留真实的合并节点，按团队约定来就好，不要一刀切。

另外有个高频踩坑点：clone 后直接git checkout <某个提交号>会进入 detached HEAD 状态，此时你确实看到了代码，但不在任何分支上，提交会变成无家可归的游离提交。正确做法是先建一个分支再切换：git checkout -b 新分支名 <提交号>。

4.3 子模块的正确拉取姿势

包含子模块的仓库，clone 之后工作区里常常会出现一个空的子模块目录，这不算失败，只是子模块没有被初始化。克隆的时候就带上子模块，命令是：

git clone --recurse-submodules <URL>

如果 clone 的时候忘了，之后补上：

git submodule update --init --recursive

这里--recursive是为了处理嵌套的子模块，也就是子模块里还有子模块的情况，建议养成习惯直接带上。

子模块有两个容易踩坑的地方：第一，子模块的远程地址如果对当前凭证不可见，初始化会失败，常见于私有子模块场景，需要先确保该地址对应的认证方式可用；第二，子模块不会跟着父仓库的pull自动更新，每次更新父仓库后，还需要执行git submodule update --remote或在配置里设置submodule.recurse true，让 git 在 fetch 和 checkout 时自动递归处理子模块。

5. 我踩过的坑与完整排查复盘

5.1 换电脑后 SSH 权限失败的排查链路

之前帮某位同事排查过一次 SSH clone 失败，他自己的账户在一个新电脑上怎么都拉不下来私有仓库，报错是git@github.com: Permission denied (publickey)。我带着他走了一遍完整的排查链路，这个过程非常有代表性，值得完整复盘一遍。

第一步，先测底层连接。执行ssh -T git@github.com，返回依然是 Permission denied，说明问题确实出在 SSH 层，而不是 git 配置层。第二步，检查私钥是否被加载。执行ssh-add -l，结果显示The agent has no identities，说明密钥根本没有被 ssh-agent 加载。第三步，手动添加私钥ssh-add ~/.ssh/id_ed25519，再测一次ssh -T git@github.com，成功了。

表面上看问题已经解决了，但这里有个更深层的隐患：每次重新开终端，ssh-agent 都会清空，每次都要手动ssh-add太烦了。所以我在他的~/.ssh/config里加了一段配置，让连接的时候自动加载指定私钥：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519 AddKeysToAgent yes

加完之后重启终端再测，不再需要手动添加密钥。这次排查里最关键的经验就是：SSH 认证报错时，不要先去翻 git 配置，而是先用ssh -T和ssh-add -l把 SSH 层的问题定位清楚，通常问题就藏在 agent 没加载密钥这个最不起眼的环节。

5.2 文件名过长导致克隆失败的处理

有次帮朋友处理一个 Windows 上的 clone 失败，报错信息是error: unable to create file ... Filename too long。仓库本身不大，但文件路径特别深，触犯了 Windows 传统上 260 字符的路径长度限制。

解决方案并不复杂，在 Windows 的 git 配置里开启长路径支持：

git config --global core.longpaths true

这个配置需要 git 客户端本身具备对长路径的支持模式，配合系统策略才能真正生效。如果改完仍然报错，还有一种临时方案是把仓库 clone 到一个更浅的路径下，比如直接放在C:\repos\而不是一层层嵌套的目录里，缩短绝对路径长度。

同类的边界问题还有 macOS 默认大小写不敏感文件系统。有些仓库里同时存在Model.ts和model.ts，在 Linux 上一切正常，在 macOS 上 clone 能完成，checkout 却会失败。这类问题普通用户基本无解，要么在大小写敏感的文件系统卷上操作，要么让仓库维护者修改文件名，我的建议是遇到就提工单，别硬扛。

5.3 符号链接和文件权限带来的麻烦

git 是支持符号链接的，它会把符号链接本身存入仓库，而不是链接指向的文件内容。这在 Linux 和 macOS 上通常没问题，但 Windows 上创建符号链接往往需要管理员权限或开发者模式，普通用户 clone 下来后发现链接变成了普通文本文件，内容是指向路径的字符串。

解决思路有两个层面：一是开启 Windows 的开发者模式，让当前用户具备创建符号链接的权限；二是通过git config core.symlinks true让 git 尝试按符号链接处理。需要注意的是，即使配置了，能否生效依然取决于系统权限。所以如果你管理一个跨平台团队仓库，尽量别依赖符号链接传递配置或共享代码。

文件权限方面也有个经典问题：在 Linux 上 clone 下来的仓库，有些文件带有执行权限位，如果你把它同步到 Windows 或某些 mac 挂载盘上，往往会看到一堆“文件被修改了”的假象。排除这种噪音的方法是配置：

git config core.filemode false

这个配置让 git 忽略文件权限位的变更。类似的，行尾符（CRLF vs LF）问题会让git status显示大量未被你改动的文件差异，解决办法是用.gitattributes明确规定各文件的换行符策略，而不是靠每个人的本地配置来碰运气。

5.4 切换账号凭证错乱的修复过程

另一个踩过的大坑是同一台机器上混用多个平台账户。当时某开发者的个人电脑上先 clone 了个人仓库，凭证管理器存了个人账户的令牌；后来要 clone 工作相关的私有仓库，一直提示认证失败。原因很简单：HTTPS 模式下 git 默认把凭证管理器里的第一份凭证拿出来试，试错之后又不会主动换下一份，于是永远卡在同一个失败上。

我推荐的整理思路是这样。如果你决定继续用 HTTPS，先把过期的错误凭证从系统凭证管理器里清掉，再用正确账户的令牌重新 clone 一次。想主动清除某个仓库的缓存凭证，可以用：

git credential reject

输入 protocol 和 host 后提交，git 就会丢弃对应的缓存记录。

但从长期维护的角度，我建议这种多账户场景干脆全走 SSH，并且用~/.ssh/config给不同账户分配不同的 Host 别名：

Host 工作别名 HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work Host 个人别名 HostName github.com User git IdentityFile ~/.ssh/id_ed25519_personal

clone 时用git@工作别名:某组织/项目.git和git@个人别名:某人/项目.git，git 会根据 Host 别名自动选择对应的私钥，彻底告别凭证管理器混用的问题。这是我在多账户环境里最满意的一个整理思路，一份配置一劳永逸。

6. 更高效的克隆工作流：把日常操作沉淀成习惯

6.1 目录规划与批量克隆的脚本写法

时间久了，本地积累的仓库越来越多，最怕的就是目录命名混乱。我现在的目录规划固定为~/code/<所属者>/<仓库名>，这样既能按组织或个人归档，又方便脚本批量处理。

如果某段时间要一次性把某人的多个项目都拉下来，我会写一个简单的循环脚本：

repos=("某团队/demo-api" "某团队/demo-web" "某团队/demo-admin") for r in "${repos[@]}"; do folder="${r%%/*}" repo="${r##*/}" if [ -d "$folder/$repo/.git" ]; then echo "跳过已存在的 $folder/$repo" else git clone --filter=blob:none "git@github.com:$r.git" "$folder/$repo" fi done

脚本里做了三个值得注意的处理：一是用%%/*和##*/拆分出组织名和仓库名；二是先判断.git目录是否存在，避免重复 clone 或者 clone 到已有目录里报错；三是统一使用 SSH 地址并带上--filter=blob:none，对大多数项目来说这个组合既快又省空间。这套逻辑扩展成读取文件列表的方式也很容易，适合团队内部分发“必拉仓库清单”。

6.2 克隆后的标准检查清单

我每次 clone 完一个之前没见过的新仓库，都会固定跑一遍下面的检查，总共花不到半分钟，但能避免不少后续的意外。

执行git remote -v确认 origin 地址正确，防止复制了错误的地址而不自知。执行git branch -vv确认当前分支和远端分支的跟踪关系已经建立。执行git status确认工作区是干净的，没有出现一 clone 下来就“满是修改”的诡异状态，如果出现了，多半是行尾符或权限位问题，先解决再写代码。如果仓库本身声明了子模块，看一眼git submodule status，检查子模块是否已经初始化。

如果接下来你要在这个仓库里提交代码，还需要确认当前仓库的本地身份信息：

git config user.name git config user.email

有的团队默认要求每个仓库单独设置提交身份，防止个人和工作身份混在同一个仓库里。检查一下总比提交完发现作者不对再返工强。

6.3 零散心得：几个值得长期养成的操作习惯

日常和git clone打交道多了，我攒了几个小习惯，都是那种“当年早该知道”的类型。

习惯一，永远不要把凭证写进远程 URL。即使本地仓库不打算分享，.git/config里一旦出现明文令牌，你就等于把一个钥匙挂在了门口。用凭证管理器或者 SSH 都能避免这个问题，不值得冒这个险。

习惯二，对不熟悉的大型项目，第一轮永远用--depth=1和--single-branch。先看代码、跑测例、判断这个项目值不值得投入，那些远程分支和全量历史，等确认了再补也不迟。

习惯三，善用git ls-remote这个“预览命令”。在决定 clone 一个仓库之前，先用它看一下远程分支和标签列表，能帮你判断这个仓库的活跃程度、默认分支是什么、有没有你需要的 release 标签。它不产生任何本地数据，相当于购物前先看一眼货架。

习惯四，保持本地目录名和仓库名一致。随性乱起的目录名会在一段时间后让你找不到东西，也会让脚本无法自动判断仓库是否已存在。机器是给人省时间的，尽量别给它添乱。

真要说哪一个最重要，我觉得是在每次执行git clone之前多花十秒钟确认一下 remote 地址和认证方式。这个习惯帮我挡掉了不少“克隆完发现地址是别人的旧仓库”或者“认证了半天发现令牌过期”的无谓消耗。操作本身不复杂，但把这些细节提前想清楚，后续的开发节奏就会顺很多。