在 Windows 内网搭建 Git 仓库：共享普通仓库 vs 中心 bare 仓库

最近有这么一个内网分享本地项目的场景。背景就是，我自己对一个技术方案进行了预研，并使用公司的项目初步做了一些效果，这些成果对其他人可以提效不少，就想先分享给组内的一些同事用用看，他们也可以提提意见之类。

痛点就是：

• 想要快速分享，快速迭代，同事快速查看。不必每次改动一次就打包发压缩文件。
• 不想让同事编辑，只是允许自己 push，别人 clone/pull
• 现在这个体量较小，目前没有上传到云上 Git 仓库的打算（公司规定不能随便新建云上仓库，要走流程之类）

这样就非常适合用带权限的本地内网 Git 仓库了。我是自己进行了文档查阅，询问 AI 解决了不少问题，最终搞定了这个痛点。下面是我自己的实践和探索，全程真实，用 AI 帮我脱敏、总结和润色了一下，我自己后面也增增补补了一点。感觉比我自己全程独立写得质量要好哈哈哈。（PS:下文提供了两种方案，针对我的场景方案一够用，方案二更适合团队合作）

适用场景：小型团队、实验室或家庭开发环境，希望在局域网内共享 Git 仓库。本文将详细介绍两种方案的优缺点及具体操作步骤。

---

🎯 方案概述

当你需要在局域网中共享 Git 仓库时，通常有两种主要方式：

1. 方案一：直接共享普通工作仓库

   • 直接共享开发者本地的工作目录（包含 .git 文件夹和工作区文件）。

2. 方案二：使用中心 bare 仓库

   • 创建一个专门用于协作的 bare 仓库（无工作区），作为所有人的“中央枢纽”。

每种方案都有其适用场景和局限性，下面我们将详细探讨这两种方案的具体实现方法及其优缺点。

---

📌 方案一：直接共享普通工作仓库

✅ 工作原理

• 开发者 A 在 E:\projects\repo-name（普通 Git 仓库）中进行开发并提交。
• 将该目录设为网络共享（如 \\DESKTOP-A\repo-name）。
• 其他人通过 git clone "//DESKTOP-A/repo-name" 拉取代码。

🛠️ 实现步骤

1. 设置共享权限

# 右键点击 repo-name 文件夹 → 属性 → 共享 → 高级共享...
# 勾选“共享此文件夹”
# 点击“权限”按钮，设置 Everyone 仅读取权限

2. 允许克隆

其他机器上执行：

git clone "//DESKTOP-A/repo-name"

TIP: 这个//DESKTOP-A可以换成内网 IP 比如192.168.1.123，反正哪一种好记忆就选哪个，下文同理。还有就是//DESKTOP-A/repo-name 这个地址是可以在资源管理器中访问和查看的，可以用来验证能否访问

✅ 优点

• 简单快速：无需额外创建仓库，直接用现有目录。
• 适合一次性分享：如果只是临时分发代码，这种方式足够。

⚠️ 缺点

• 无法安全接收 push：Git 默认拒绝更新当前检出分支（refusing to update checked out branch）。
• 拉取可能失败：如果开发者 A 正在编辑文件，.git/index 或对象文件可能被锁，导致 clone 失败。
• 状态不一致：克隆者看到的是 A 的工作区状态 + 最新 commit，但如果 A 有未提交更改，这些不会被同步，容易造成混淆。
• 无权限隔离：要么全开放（可读可写），要么全禁止，无法精细控制。

🔧 临时缓解措施（不推荐长期使用）

如果非要允许 push，可在源仓库执行：

git config --local receive.denyCurrentBranch updateInstead

但依然存在文件锁、冲突、权限混乱等风险，仅适合单人偶尔分享。

---

📌 方案二：使用中心 bare 仓库

✅ 工作原理

• 创建一个 无工作区的 bare 仓库 作为“中央枢纽”。
• 所有人（包括原作者）都向它 push，从它 pull。
• 权限通过 Windows 文件系统精细控制。

🛠️ 实现步骤

1. 创建 bare 仓库

cd E:\projects\test
git init --bare repo-name.git

2. 设置 NTFS 权限

右键 repo-name.git → 属性 → 安全 → 编辑

用户/组	权限
git-readers	读取和执行、列出文件夹内容、读取
git-writers	完全控制（或至少包含“修改”+“写入”）

3. 共享权限

右键 repo-name.git → 属性 → 共享 → 高级共享...

• 勾选“共享此文件夹”
• 点击“权限”按钮，设置 Everyone 仅读取权限

4. 克隆与推送

其他机器上执行：

git clone "//DESKTOP-A/test/repo-name.git"

开发者可以 push 到这个 bare 仓库。

✅ 优点

• 天然支持 push/pull：Bare 仓库专为远程协作设计，无“当前分支”概念。
• 稳定可靠：无工作区文件锁，对象存储干净。
• 权限可控：通过 NTFS 精确分配读/写权限。
• 符合 Git 协作规范：与 GitHub/GitLab 工作流一致，团队迁移成本低。

⚠️ 缺点

• 需要额外创建仓库：必须 git init --bare 创建一个新的 bare 仓库。
• 初始配置稍复杂：需设置 NTFS 和共享权限。

---

🆚 对比总结

特性	方案一：共享普通仓库	方案二：中心 bare 仓库
是否需要额外创建仓库	❌ 否（直接用现有目录）	✅ 是（需 git init --bare）
是否支持多人 push	❌ 基本不支持（会报错）	✅ 完全支持
拉取稳定性	⚠️ 可能因文件锁失败	✅ 高度稳定
权限控制	❌ 仅能靠共享开关	✅ 可按用户/组精细控制
适用场景	临时分享、只读分发	正式协作、持续集成
推荐程度	⚠️ 仅限一次性使用	✅ 强烈推荐

---

💡 结论

方案一：直接共享普通工作仓库

• 适用场景：临时分享、只读分发。
• 注意：仅限于一次性使用，不适合多人协作或需要 push 的场景。

方案二：使用中心 bare 仓库

• 适用场景：正式协作、持续集成。
• 优势：天然支持 push/pull，稳定可靠，权限可控，符合 Git 协作规范。
• 推荐程度：强烈推荐！

无论你选择哪种方案，最重要的是根据实际需求选择合适的工具和方法，以确保团队协作顺畅高效。好的工程习惯，从第一天就值得投入。

---

作者：coding 消烦员
环境：Windows 10/11 + Git for Windows (Git Bash)