Azure 开户代办 Azure微软云服务器搭建私有Git库

前言：Git 库也需要“房产证”

如果你做过团队协作，肯定遇到过这种场景：代码在本地开发机上是天选之子，一旦要给别人同步，就开始“靠微信发压缩包”“靠聊天记录存 patch”。久而久之，你会发现：不是大家不努力，是 Git 仓库这事儿没搭好。于是你想：既然都上云了，那就顺手在 Azure 上搭一套私有 Git 库，让代码走流程、走权限、走审计——大家都省心。

本文目标很明确：你将得到一个在 Azure 上运行的私有 Git 服务端（基于 SSH），支持团队成员用 Git 在外网安全访问，并能稳定推送/拉取。我们会尽量保持“可复用、可落地”，不搞玄学，尽量让你照着做就能跑。

总体方案：用“裸仓库 + SSH”当私有 Git 服务

关于私有 Git，常见路线有很多，比如用 GitLab、Gitea、纯 Web 方案、甚至直接用托管服务。可是在“快速、安全、可控”的平衡点上，裸仓库（bare repository）+ SSH 是最轻量、最省资源、也最容易入手的方式。

本方案特点：

• 轻量：不用搭复杂的 Web 服务，资源占用小。
• 安全：使用 SSH Key 验证，不用把密码到处飘。
• 通用：任何支持 Git+SSH 的客户端都能访问。
• 易维护：仓库结构简单，权限清晰。

你要做的事情基本是：买（或创建）一台 Azure 云服务器 → 配置系统基础环境 → 创建一个专用用户和裸仓库 → 开放 SSH 访问 → 本地 push 进来。

第一步：在 Azure 创建云服务器

1. 选哪种系统更合适？

我建议你用 Linux（Ubuntu 常见且文档多）。如果你团队对运维比较熟，Debian 也没问题。核心要求：

• 系统支持 apt（或等价包管理器）
• SSH 服务能正常运行
• 你能配置防火墙/网络规则

2. 规格怎么选？

搭私有 Git，通常不需要很夸张的规格。建议起步：

• CPU：1-2 核
• 内存：2GB 起
• 磁盘：至少 30GB（团队仓库大了再加）

如果你还准备上 CI/CD 或者以后再上 GitLab，那就另说；但单纯 Git 裸仓库，这个配置很够用。

3. 网络与端口：别把家门口开成自助餐

你只需要开放一个关键端口：22（SSH）。

在 Azure 门户中，确保网络安全组（NSG）或防火墙规则允许：

• 入站：TCP 22（建议限制来源 IP 到你的办公网/固定出口）
• 出站：一般默认即可

如果你只是学习/小范围内网访问，可以放宽；但真要生产，建议至少限制来源 IP。安全这东西，永远不是“看心情”，是“看事故发生没有”。

第二步：登录服务器并安装 Git

1. 登录

你会拿到服务器的公网 IP 和管理员账号。常见方式是 SSH：

ssh <用户名>@<公网IP>

如果你不想用密码登录，建议用 Azure 里配置好的 SSH Key。

2. 更新系统并安装 Git

进入服务器后，先更新包列表：

sudo apt update

安装 Git：

sudo apt install -y git

检查版本：

git --version

如果版本能正常输出，你已经成功跨过第一座“把时间浪费在版本号上的大山”。

第三步：创建专用 Git 用户与目录结构

为了让权限不乱，你最好不要用 root 来管理仓库。我们创建一个专用用户，例如 git。

1. 创建 git 用户

sudo adduser --disabled-password --gecos "" git

按照提示设置用户信息即可。关键是不用设置密码（或确保只能通过 SSH Key）。

2. 创建仓库根目录

sudo mkdir -p /var/git

sudo chown git:git /var/git

接下来，所有仓库都放在：

/var/git/<repoName>.git

第四步：配置 SSH 访问（重点中的重点）

我们要确保：客户端用自己的 SSH Key 访问服务器时，能把操作限制在特定目录。

1. 确保 SSH 服务已启用

一般系统默认是开启的。你可以确认：

sudo systemctl status ssh

如果没有启动：

sudo systemctl enable --now ssh

2. 生成 SSH Key（在客户端）

Azure 开户代办 每个团队成员在自己的电脑上生成密钥对（如果还没有）：

ssh-keygen -t ed25519 -C "[email protected]"

一路回车即可，生成后你会得到：

• 私钥：~/.ssh/id_ed25519
• 公钥：~/.ssh/id_ed25519.pub

3. 把公钥添加到服务器

把每个人的公钥内容追加到服务器的：

/home/git/.ssh/authorized_keys

先创建目录并设置权限：

sudo -u git mkdir -p /home/git/.ssh

sudo chmod 700 /home/git/.ssh

然后追加公钥。假设你把公钥内容复制好了：

sudo sh -c 'cat >> /home/git/.ssh/authorized_keys'

粘贴公钥后保存即可。

最后设置权限：

sudo chmod 600 /home/git/.ssh/authorized_keys

4. 追加一个“防止别人乱写”的约束（可选但很香）

更严格的做法是为每个公钥配置命令限制，但这会增加管理复杂度。对于入门私有仓库，通常只要：

• 使用专用 git 用户
• 仓库根目录权限正确
• SSH Key 不泄露

就足够了。

如果你以后想进一步加强，我也建议你加上按用户映射权限（比如限制只能对某些仓库写入）。后文我会讲到权限策略。

第五步：创建裸仓库并初始化（让 Git “有地方放代码”）

现在我们可以在服务器端创建一个私有仓库。比如你要建一个名为 myapp 的仓库。

1. 创建裸仓库

cd /var/git

sudo -u git git init --bare myapp.git

裸仓库创建完成后，你会看到目录 /var/git/myapp.git。

2. 设置仓库所有权（确认权限没问题）

sudo chown -R git:git /var/git/myapp.git

3. 设置默认分支（可选但推荐）

有些情况下，你希望仓库默认分支是 main：

cd /var/git/myapp.git

sudo -u git git symbolic-ref HEAD refs/heads/main

当然，最终分支名还是以你首次 push 的分支为准，但提前设置能减少一些“为什么拉下来是 master”的烦躁。

第六步：在本地添加远程并首次推送

到这一步，你已经有服务器仓库了。接下来，在本地项目目录里添加 remote 并推送。

1. 本地准备一个仓库

如果你已有项目 Git 初始化过，可以跳过。

git init

Azure 开户代办 把代码提交起来：

git add .

git commit -m "init"

Azure 开户代办 2. 添加远程地址

远程地址格式（SSH）通常是：

git@<公网IP或域名>:/var/git/myapp.git

在本地执行：

git remote add origin git@<公网IP或域名>:/var/git/myapp.git

检查 remote：

git remote -v

3. 推送到服务器

首次推送建议显式指定分支：

git push -u origin main

如果你的分支叫 master，就用 master。

推送成功后，你的私有 Git 库就算搭起来了。此时你可以：

• 团队成员 clone：

  git clone git@<公网IP或域名>:/var/git/myapp.git

• 本地继续推送：

  git push

第七步：权限与多人协作策略（不然就会变成“谁都能写谁都不改”）

裸仓库配 SSH 时，默认所有能登录 git 用户的人，只要仓库权限允许，就能推送。你可能希望做到：

• 某些成员只读
• 某些成员可以写入
• 不同仓库分不同角色

下面给你几种常用策略。

策略 A：用不同 Unix 用户分别映射权限（推荐进阶版）

思路是：为每个开发者创建一个系统用户（或至少为写入组创建用户），然后每个用户的 SSH Key 绑定到对应账号。再把对应仓库目录的所有权和权限设置好。

这套方案比“全部用 git 用户”更稳，也更容易审计。但管理成本略高。

策略 B：用组权限控制写入（折中）

你可以给仓库设置 group，比如：

• 把需要写入的用户加入某个组，如 git-writers
• 仓库目录设置 group 并控制写权限

注意：Git push 是否成功还取决于仓库是否具备必要写入能力。你要确保写入路径权限没问题。

策略 C：简单粗暴（适合小团队临时用）

如果你只有 2-3 个人，且都很靠谱，直接让所有人能写可能也能接受。但要在心里默念：“能不能写，不重要；重要的是别手滑 force push。”

第八步：常见坑位排查（省你 3 小时“怀疑人生”）

坑 1：连接不上服务器（timeout）

• 检查 Azure NSG 是否放行 TCP 22
• 检查服务器本地防火墙（如果有启用 UFW 等）
• 检查你是否用对了 IP（有时是内网/公网混淆）

坑 2：权限问题（Permission denied (publickey)）

• 确认客户端公钥是否正确加入 authorized_keys
• 确认 /home/git/.ssh 权限是 700，authorized_keys 是 600
• 确认 ssh 用的用户名是 git（或你实际配置的用户）

Azure 开户代办 坑 3：push 报错（无法写入仓库）

• Azure 开户代办 检查仓库目录所有权是不是 git
• 检查仓库目录权限：至少要让 git 用户有写权限
• 检查磁盘是否满了（磁盘满会导致写入失败）

磁盘检查：

df -h

坑 4：clone 成功，但看不到某些分支

• 确认你 push 的分支名称
• 确认你首次 push 用的是 main/master（和你设置的 HEAD 不一定一致）
• 如果历史重写过，可能需要重新 fetch

第九步：安全加固建议（把“能用”升级成“敢用”）

搭完能用只是第一关，接下来是把它做成“抗揍”的服务。

1. 强制 SSH Key，不要开密码登录

编辑 SSH 配置（一般在 /etc/ssh/sshd_config），将：

PasswordAuthentication no

同时确保：

PubkeyAuthentication yes

修改后重启 SSH：

sudo systemctl restart ssh

2. 限制来源 IP（强烈建议）

在 Azure NSG 或防火墙层面，只允许办公网/固定出口访问 22。这样你就不会成为“公开可爆破靶场”。

3. 做定期备份

仓库在 /var/git。你需要定期备份目录。

• 可以用 tar 打包
• 可以配合对象存储（Azure Blob）
• 至少保留最近几次快照

备份脚本示例思路（这里给你方向，别照抄就上生产）：定期对 /var/git 做压缩归档并上传到安全位置。

4. 监控磁盘与 CPU

Git 服务是稳定型选手，但仓库增长不可预测。你需要关注磁盘空间和负载。

Azure 开户代办 基本查看：

top

df -h

第十步：升级玩法（当你想再进一步）

当团队规模上来，你可能会想要更多功能：

• Web 界面
• 权限管理更细
• Issues / Pull Requests
• CI/CD

这时你可以考虑：

• 引入 Gitea（轻量 Web Git 服务）
• 上 GitLab（功能强但更重）

但在你还没走到那一步之前，这套裸仓库方案完全能满足“私有、安全、快速落地”的需求。

结语：你搭的不是服务器，是团队的代码秩序

Azure 上搭私有 Git 库这件事，表面上看是命令行和权限设置，实际上它解决的是团队协作的秩序问题：代码归档、权限边界、推送流程、备份意识。你会发现，当仓库安定下来，沟通也会少很多“那个文件你发我一下”的戏码。

最后送你一句“运维人常说但不常写”的话：能拉就证明网络通了，能推就证明权限对了，能备份就证明你成熟了。

希望你照着这篇文章做完，Git 服务端顺利上线。你要是愿意，我也可以根据你的具体情况（系统版本、团队人数、仓库数量、是否要只读/可写权限）把权限策略继续细化到可以直接照做的程度。