在单机环境下使用 Git 进行版本控制时,开发者可以在本地自由地进行代码提交和分支管理。然而,当多个开发者需要协作开发同一个项目时,就需要一个中央化的代码仓库来协调各方的更改。
在分布式协作场景中,如果每个开发者都在本地维护独立的版本历史,很快就会产生版本冲突和同步问题:不同开发者对同一文件的修改可能产生冲突,难以确定哪个版本是最终的有效版本,也无法追踪代码的完整变更历史。

为了解决协作中的版本管理问题,团队需要建立一个远程仓库 (Remote Repository)。远程仓库是所有协作者共同认可的、存放项目代码的中心枢纽。值得注意的是,远程仓库通常是一个"裸仓库" (Bare Repository)。
裸仓库只包含 Git 的版本历史数据,不包含工作目录。这意味着开发者无法在裸仓库中直接进行代码编辑或构建操作。这样设计的目的在于保持中央版本的纯净性和权威性,避免在服务器端直接修改代码,确保所有更改都通过标准的 Git 工作流程进行。
客户端与远程仓库进行数据交换时,需要使用双方都支持的传输协议。Git 支持四种主要的传输协议,每种协议都有其特定的应用场景和技术特点。

本地协议是最简单的传输方式,适用于同一台机器或局域网内的仓库访问。在这种模式下,远程仓库的路径可以是本地文件系统路径或网络共享路径(如 NFS、SMB 等)。
本地协议的优势在于配置简单,无需额外的网络服务。但其局限性也很明显:缺乏网络访问能力,无法支持远程协作;安全性较低,依赖文件系统的权限控制;不适合跨网络的分布式团队使用。
HTTP 协议是当前最流行的 Git 传输协议,基于标准的 HTTP/HTTPS 协议,具有出色的网络兼容性和安全性。Git 的 HTTP 协议支持两种工作模式:只读模式和读写模式。
只读 HTTP 模式(通常称为"哑巴"HTTP)仅支持从服务器获取数据,无法进行推送操作。这种模式适用于公开的代码仓库,用户可以通过标准的 Web 浏览器访问,但无法直接提交更改。其优势在于配置简单,无需特殊的服务器端 Git 支持。
读写 HTTP 模式(通常称为"智能"HTTP)是当前的主流选择,支持完整的 Git 操作,包括推送和拉取。它通过 HTTP Basic 认证或更现代的 OAuth、个人访问令牌等方式进行身份验证。这种模式的优势在于:
现代 Git 托管平台如 GitHub、GitLab、Bitbucket 等都主要使用智能 HTTP 模式,为用户提供了便捷且安全的代码协作体验。
SSH (Secure Shell) 协议是一种基于加密通道的传输方式,广泛应用于企业内部的私有代码仓库。SSH 协议使用公钥加密技术进行身份验证:开发者将公钥添加到服务器的授权列表中,服务器使用对应的私钥进行身份验证。
SSH 协议的优势包括:高度安全的加密传输、无需每次输入密码(通过密钥认证)、支持端口转发和隧道技术。其局限性在于:需要为每个用户配置 SSH 密钥,管理成本较高;不适合大规模公开访问的场景;需要开放 SSH 端口(22),可能受到防火墙限制。
SSH 协议更适合企业内部或小团队的私有项目,能够提供细粒度的访问控制和审计能力。
Git 协议是 Git 自带的专用传输协议,使用 TCP 端口 9418,具有极高的传输性能。Git 协议使用自定义的二进制协议,避免了 HTTP 协议的开销,能够实现更快的克隆和拉取操作。
由于 Git 协议不提供任何身份验证机制,因此它通常仅用于只读访问。任何人都可以通过 Git 协议快速获取公开仓库的代码,但无法通过该协议进行推送操作。这种设计使得 Git 协议特别适合需要被大量用户快速访问的大型开源项目,能够显著降低服务器的负载。
对于需要完全控制代码仓库的组织,可以选择自行搭建 Git 服务器。搭建过程主要包括创建裸仓库、配置访问协议和设置权限管理。

第一步是在服务器上创建一个裸仓库,这是存储项目权威版本的核心。使用 git init --bare 命令可以创建一个不包含工作目录的裸仓库,该仓库只包含版本历史数据,适合作为中央仓库使用。
最常见的访问方式是 SSH 协议。可以为团队创建一个共享的 git 系统用户,收集每个成员的 SSH 公钥,并将这些公钥添加到 ~/.ssh/authorized_keys 文件中。这样,团队成员就可以使用各自的私钥进行身份验证,安全地访问仓库。
为了增强安全性,可以将 git 用户的登录 shell 设置为 git-shell。git-shell 是一个受限的 shell,只允许执行 Git 相关操作,禁止用户登录到系统的交互式 shell,从而保护服务器系统的安全。
如果项目需要提供公开的只读访问,可以启动 Git 守护进程 (Git Daemon)。Git Daemon 监听 TCP 9418 端口,提供基于 Git 协议的只读访问服务。通过配置,可以指定哪些仓库允许通过 Git 协议访问,实现细粒度的访问控制。
对于需要同时支持读写和只读访问的场景,可以配置智能 HTTP 服务。这通常需要安装 Git 的 HTTP 后端(如 git-http-backend)和 Web 服务器(如 Apache 或 Nginx)。智能 HTTP 服务可以通过 HTTP Basic 认证支持读写操作,同时允许匿名用户进行只读访问,所有功能都通过统一的 HTTP/HTTPS 接口提供。
纯命令行的 Git 服务器虽然功能完整,但在代码浏览、历史查看和团队协作方面不够直观。为 Git 服务器添加 Web 界面可以显著提升用户体验和管理效率。
Git 自带了一个名为 GitWeb 的 Web 界面工具。GitWeb 提供了基础的代码浏览功能,包括文件查看、提交历史、分支和标签管理等。虽然功能相对简单,但对于小型项目或内部使用已经足够。
如果需要功能完整的代码托管平台,可以选择部署 GitLab 这样的开源解决方案。GitLab 不仅提供代码浏览功能,还集成了以下特性:
GitLab 将基础的 Git 服务器升级为功能完备的 DevOps 平台,适合需要完整开发工具链的团队使用。
自行搭建和维护 Git 服务器需要投入大量的时间和资源,包括服务器管理、安全维护、备份策略等。对于大多数开发者和团队,使用第三方托管服务是更高效的选择。
GitHub、GitLab.com、Bitbucket 等平台提供专业的代码托管服务。这些平台的优势包括:
对于绝大多数开发者和团队,尤其是开源项目,第三方托管服务是最佳选择,能够将精力专注于代码开发而非基础设施维护。
在服务器上管理 Git 项目可以选择自建服务器或利用第三方托管服务。自建服务器的优势在于可对服务器配置、安全和数据存储拥有完全控制权,数据私有且可高度定制,但需要投入较高的人力维护、安全更新和备份,并具备相关专业知识。 相比之下,第三方托管服务如 GitHub、GitLab 等则无需自行维护服务器,能够享受专业的安全保障和强大的开发协作工具,但代码托管在平台上,可能需要付费并且定制灵活性有限。
综合来看,小型团队或个人项目更适合选择第三方托管服务;企业内部项目或有合规与高安全需求时可考虑自建服务器或私有化部署。具体怎么选择还是需要结合团队规模、项目性质、安全和预算等因素,综合考虑选择最适合自身需求的 Git 服务器方案。