Git 里的 remote 不一定指网络上的服务器，也可以是本机目录、共享文件夹或局域网里的裸仓库（bare repo，只有仓库数据没有工作区）。这篇讨论围绕“把 local 当作 remote”是否有意义：有人把它当成离线中转、加密存储、Dropbox/NAS 同步、容器内代理开发或多机器协作的工具。评论里还提到 `git clone --reference`、`worktree` 和 hardlink index 等机制，说明 Git 本身已经提供了多种共享对象和减少重复占用空间的方式。另一条支线则是 GitHub（代码托管平台）把很多人对 Git（版本控制系统）的理解带偏，导致有人以为离开 GitHub 就等于离开 Git。
不少评论把本地 remote 视为一种实用的中转层，而不是传统意义上的对外发布点。有人把仓库先推到加密的 sparse bundle 镜像里，再用 rsync 同步到别处，以避免把明文代码直接放到不受信任的远端。也有人用共享 Dropbox 文件夹、NAS、局域网目录或多沙箱/容器之间的临时仓库，让权限受限的协作者或自动化 agent 先把代码推到本地中继，再统一同步到 GitHub/GitLab。还有人提到在共享电脑上、开发流程受限或需要归档时，这种模式比直接依赖公网托管更顺手。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
另一派完全怀疑这种做法，认为如果真正的 remote 不可用，把分支留在本地、等恢复后再 push 就够了。按这个观点，所谓 local remote 只是多出一套 `local/` refs 和额外副本，本质上是在同一台机器上重复管理状态。反驳者则指出，local 并不一定指同一台机器，也可能是共享目录、网络文件系统或局域网内的仓库，因此它仍然可以充当团队共享点。讨论里还有人吐槽，提到 site-to-site VPN 之类的基础设施时，解释会显得居高临下。
评论区也延伸到 GitHub 带来的概念混淆。有人说 GitHub 的普及让不少半技术用户重新“发现”Git 本身是分布式的，甚至误以为 GitHub 发明了 Git。另一些人指出，很多人谈“离开 GitHub”时其实是把 GitHub 当成了 Git，这种混淆反映出托管平台已经强到足以覆盖工具本身的认知。还有更尖锐的说法，把这种命名和品牌效应上升到公司如何借通用词汇塑造“默认选项”的层面。
也有人把话题拉回 Git 自带的其他机制，认为不一定非要用 local remote 才能省空间或隔离工作。`git clone --reference` 可以复用已有对象库，避免重复存储大块历史；`worktree` 则能让同一仓库对应多个工作目录，适合并行开发。评论还提到 hardlink index、bare repo 以及把 Git mailing list 或 kernel 历史直接当仓库搜索的做法，显示大家在比较不同场景下到底该用哪一种原语。整体看，争论不只是“要不要 local remote”，而是“Git 已经有哪些更合适的拼装方式”。
bare repo: 不带工作区的 Git 仓库，常用作中央仓库、只读镜像或服务器端 remote。
worktree: 让同一个 Git 仓库共享对象库，却有多个独立工作目录的机制，适合并行检出。
git clone --reference: 克隆时引用已有对象库，减少重复下载和磁盘占用。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。