企业官网建设流程全解析

起初团队小的时候，Git 仓库放哪都无所谓，GitHub 免费版用着也挺顺手。可一旦规模上来，代码安全性、权限管控、分支保护、制品沉淀这些问题全来了。我见过不止一个团队，代码托管还停留在“网盘传压缩包”或者“谁电脑上有一份最新代码”的原始状态，等到线上出问题需要快速回滚时，发现根本找不到对应版本的制品包。

这篇文章把我在私有化版本控制工具上的选型和实践经验整理出来，重点解决三件事：能部署在自己服务器上、能把分支管明白、能把构建产物和应用版本对应起来。如果你正在做技术选型，或者觉得目前的版本管理方式已经拖累了发布效率，下面这些内容应该能帮到你。

1. 为什么要放弃公共托管平台，转向私有化部署

大家最常用的 GitHub、GitLab.com 这类公共平台确实方便，开箱即用，省去运维成本。但放到企业环境里，几个现实问题绕不开。

1.1 私有化部署解决的三个核心痛点

第一是合规与数据主权。有些项目的代码本身就涉及商业机密，或者客户合同里明确要求源码和数据不得离开指定网络环境。把代码放在别人的服务器上，哪怕签了保密协议，心理那关和合规那关都难过。私有化部署后，代码、数据库、备份全部落在我自己的机房或云服务器上，审计的时候也说得清。

第二是访问体验与稳定性。跨地域访问公共平台，网络延迟和偶发的服务不可用是常态。有一次 GitHub 大面积故障，我们整个研发团队干等了一个上午，什么事都做不了。私有化部署在内网或者专有云环境，代码克隆和推送的速度快得多，而且不受第三方服务状态影响。

第三是深度定制和系统集成。公共平台能提供的 Webhook、API 就那么多，真要和内部系统深度打通时，经常发现能力不够用。自托管以后，我可以随意改配置文件、定制钩子脚本、对接统一登录系统，甚至给某个团队单独开启一些特殊规则。

1.2 什么样的团队需要现在就切换

不是所有团队都非得私有化，我总结了几种典型场景：

• 团队规模在 10 人以上，且涉及商业项目或政务类、金融类项目。
• 有合规审计要求，需要记录所有代码访问和操作日志。
• 现有流程中已经需要频繁出制品包，希望代码和交付物能关联起来。
• 网络环境特殊，比如纯内网开发，无法访问外部的代码托管服务。

如果以上命中三条及以上，私有化部署基本是必然选择。

2. 主流私有化版本控制工具横向对比：GitLab、Gitea、Gerrit、Gogs、Bitbucket

工具圈子里讨论最多的是这几款，我基于实际使用体验和社区反馈，列了一个对比清单。

2.1 为什么 GitLab 目前仍是综合体验最稳的选择

如果团队没有特殊历史包袱，我一般建议先评估 GitLab。它把代码托管、CI/CD、制品库、安全扫描都揉进了一个平台里，部署一套就能替代好几套系统。尤其是 GitLab 自带的反向代理和 HTTPS 配置，比 Gitea 省心不少。

版本选择上建议直接上 GitLab Enterprise Edition 的免费版（CE 已经合并进 EE 了，现在下载的都是同一个包，只是 License 决定功能开关）。免费版里分支保护、Merge Request、Webhook、Container Registry 这些关键功能都在，足够支撑一个成熟团队的日常运作。

2.2 Gitea 低配服务器上的另类选择

如果你只有一台 2C4G 的小机器，又想跑起一个还算体面的版本控制服务，Gitea 是典型的高性价比选择。它用 Go 写的，单个二进制文件就能跑，部署难度低到基本是“解压即用”。功能上虽然没有 GitLab 那么全，但分支、标签、Issue、PR、Webhook 这些核心能力都不缺。

有团队把 Gitea 跟 Drone CI 搭配使用，效果出奇地好，轻量、快速、够用。缺点是制品管理这块基本是空白，需要自己额外搭一套。

2.3 Gerrit 适合评审文化特别重的团队

Gerrit 这套东西比较特别，它是把代码审查嵌入了 Git 操作流程里。开发者不能直接 push 到分支，所有提交都要经过 refs/for 评审，每个提交就是一条评审任务。这对很多团队来说过于繁琐，但如果你所在的团队追求严格的代码评审质量，它确实能提供这种控制力。

不过说实话，现在用 Gerrit 的新项目越来越少了，GitLab 的 Merge Request 配合强制审批规则，已经能覆盖绝大多数评审需求。

3. 分支管理能力拆解：从热词里的场景说起

标题里专门强调了“管得住分支”，这个能力在日常协作中太关键了。我注意到最近搜索热词里大量都是关于分支切换、合并、清理、冲突处理的操作问题，这说明很多人在真实工作中被分支管理难住了。下面我把几个高频场景和工具的能力对应起来说。

3.1 分支保护规则：master 和 release 分支不是谁都能碰的

不管是 GitLab 还是 Gitea，都提供了分支保护规则。把 master、main、release 这类核心分支设为保护分支后，普通开发者不能直接 push，必须发起合并请求（Merge Request / Pull Request），由指定角色审批后合入。这样就把“直接改主干”的风险彻底堵住了。

我在配置分支保护时有个心得：不要只保护主干分支，像 develop、test、release/ 前缀的分支都应该纳入保护范围。具体规则可以设置成：

• 允许合并的角色：Maintainer / Owner
• 必须审批次数（Approvals Required）：至少 1-2 次
• 禁止强制推送（Force Push）：开启
• 删除分支时的限制：合并后允许删除，但保留历史记录

3.2 多人并发下的分支策略：git flow 还是 trunk-based

分支策略没有银弹，得看团队和发布节奏。Git Flow 适合版本迭代周期比较长、需要维护多个发布分支的传统项目；Trunk-Based 适合要求快速持续集成、主干一直保持可发布状态的互联网团队。

不管用哪种，在私有化工具里都建议做几件事：

• 在仓库说明文档里写清分支命名规范，比如 feature/xxx、bugfix/xxx、release/v1.2.3。
• 设置 CI 流水线，让每个新 push 的分支都自动跑一遍编译和测试，减少合并时的“惊喜”。
• 定期清理已经合并的分支，避免分支列表越来越长。VSCode 里清理分支的操作虽然方便，但服务端的垃圾分支还是要靠仓库规则配合。

3.3 从热词看常见分支操作误区

我翻了一下最近大家搜得最多的问题，几乎个个都是日常踩坑的高发点，这里集中说一下。

master 分支 revert 后，其他分支合并 master 冲突

这种情况非常典型。开发 A 在 master 上 revert 掉了一个提交，开发 B 在 feature 分支上继续开发旧功能，等 feature 合并回 master 时，发现“复活”了被 revert 的内容或者出现大量冲突。

根因在于 revert 本质是生成一个新的反向提交，它没有删除原提交的历史。feature 分支的合并基还是旧提交，Git 会认为 feature 上缺失了 revert 这个改动，于是把旧内容又带回来了。

处理办法有两个：

1. 在 feature 分支上重新基于最新的 master rebase，解决完冲突再合并。
2. 如果 feature 分支已经公开共享，不要用 revert 去撤销 master 提交，而应该用 revert 配合后续的手动修复，或者干脆用 revert 生成反向提交后，在合并时使用git merge --strategy ours这种策略去处理。

idea dev 分支代码合并到 test，合完之后发现少了好几个文件

这个和上面是同一个套路的多分支变体。本质上就是合并时解决冲突不够仔细，或者分支的基点太旧，导致一部分提交被“掩盖”了。

我的建议是每次合并前先做一次 diff 对比，工具类都支持分支间 diff 预览。GitLab 的 Merge Request 页面上能看到鲜活的改动列表；IDEA 里也可以通过 Git 工具栏直接 Compare Branches。别嫌麻烦，合并前多看两眼，比合并后排查节省十倍时间。

eclipse merge 分支、tortoisegit 切换分支

很多老牌桌面工具功能并不差，问题通常出在概念理解上。比如 TortoiseGit 切换分支时如果不勾选“Clean working tree”，本地未提交的改动会跟随切换，覆盖到目标分支的场景非常容易发生。

操作规范上建议：切换分支前先 commit 或 stash 当前改动，保证工作区是干净的。这个习惯养成后，分支混动导致的线上问题能减少一大半。

3.4 分支合规与审计

私有化部署最大的一个优势就是可以做操作审计。GitLab 的管理后台能查到谁在什么时间 push 了哪个分支、谁合并了什么 MR、谁改过仓库设置。对于通过等保测评或有内控要求的团队来说，这个功能是硬指标。

我习惯设置几个审计相关的最佳实践：

• 开启仓库的 Audit Events 记录。
• 设置受保护分支的强制审批，并且审批记录可追踪。
• 不允许通过命令行强行跳过多人在线评审，所有变更都走 MR。

4. 制品管理：版本控制工具最容易被低估的一环

很多团队一直用的“笨办法”是：代码打 tag，然后手动去 CI 平台找对应构建产物。慢不说，还容易搞错关联。实际上，现代版本控制工具已经能把“代码版本”和“制品版本”统一起来。

4.1 制品仓库是什么，和代码仓库是什么关系

代码仓库管理的是源码文件和它们的变更历史；制品仓库管理的是构建产物，也就是编译出来的包、镜像、二进制文件。二者需要建立对应关系：某次构建的产物，是由哪个 commit 的源码产生的，必须可追溯。

以 GitLab 为例，它自带的 Package Registry 支持存 Maven、npm、PyPI、容器镜像等常见格式。当 CI 流水线跑完后，可以把生成的 jar 包或镜像直接推送到对应的 Project 的制品库里，并且和当前的 commit、tag 绑定。这样回滚时只需要找到目标 tag 对应的制品，拉下来部署就行。

4.2 制品管理的一个实战路径

我给出一个实操性强的配置套路，这套东西在 GitLab 上可以直接落地：

• 代码里维护version.txt或使用 Git tag 作为版本来源。
• .gitlab-ci.yml中定义构建产物路径，并配置artifacts关键字把关键产物上传到流水线。
• 发布阶段执行mvn deploy或docker push，把制品推送到 GitLab Package Registry。
• 使用rules限定只有 tag 触发的流水线才会执行发布流程。

下面是一段简化版的发布流水线配置，供参考：

stages: - build - release variables: MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository" cache: paths: - .m2/repository/ build: stage: build script: - mvn compile only: - branches release: stage: release script: - mvn package - mvn deploy artifacts: paths: - target/*.jar only: - tags

这样每次打 tag，流水线就会自动构建并发布制品，代码和制品之间的追溯链路就建立起来了。

4.3 制品保留策略与清理

制品库如果不设保留策略，很快就会被历史构建堆满磁盘。GitLab 里可以配置制品过期时间，比如默认保留 30 天，或者只保留每个项目最近 N 个制品。注意，发布到生产环境的稳定版本建议单独打 tag，并设置永久保留，不要随过期策略清理掉。

5. 私有化部署的落地实操：选型、部署、迁移与日常维护

这一节我打算把从零开始做私有化部署的关键步骤拆开讲，很多细节不亲自踩一遍真的不知道。

5.1 硬件与系统环境规划

内存是硬指标。GitLab 的 Omnibus 包建议至少 4GB 内存起步，8GB 比较舒服。如果同时跑的 CI Runner 数量多，建议内存再加大。Gitea 则只需要 1GB 内存就能顺畅跑。系统方面，Ubuntu 20.04 LTS / 22.04 LTS 和 Debian 11/12 都是稳妥的选择。

存储盘建议单独挂一块数据盘给代码仓库和制品库。原因很直接：系统和数据分离后，重装系统不会带走代码历史和制品，备份恢复也更方便。

部署前把域名规划好，比如 git.company.com，并提前准备好 SSL 证书。证书过期是很多团队忽略的隐患，内网用的自签证书每隔一年要换一次，经常出问题。我的经验是直接用内网 CA 或 Let's Encrypt 自动续期，省心很多。

5.2 安装 GitLab 的最小配置与常用优化

GitLab 的安装网上教程很多，我这里只列几个容易踩坑的点。

第一个坑是内存设置。改/etc/gitlab/gitlab.rb时，不要贪多，默认自带的功能很多，但对内存不友好。建议先显式关掉不用的组件。

# 关闭不需要的组件，节省内存 prometheus_monitoring['enable'] = false grafana['enable'] = false

第二个坑是外部 URL 配置。一定要把external_url配置成用户真正访问的地址，不然项目克隆链接里会出现localhost，所有人克隆时都得手动改。

external_url 'https://git.company.com'

第三个坑是统一登录。企业里一般已经有 AD 或 LDAP，GitLab 支持直接对接，这样人员入职和离职的账号管理就不用在多个系统里重复操作了。配置完记得用测试账号验证走一遍登录流程再广而告之。

5.3 从旧平台迁移到私有化 GitLab，如何降低痛苦

迁移迁移，看似简单，做起来细节很多。GitLab 自带项目导入功能，可以从 GitHub、Bitbucket 和另一套 GitLab 直接导入。但要注意几点：

• 导入前先检查旧仓库的 LFS 对象、大文件、子模块是否完整，否则克隆下来缺文件会非常麻烦。
• 如果是历史全部要保留的，用git clone --mirror或者 GitLab 后台的导入都行。只迁移最新代码的话，建议把新旧仓库的关联断开，避免后续误操作。
• 迁移完成后，全局搜索一下代码里写死的旧仓库地址，特别是 CI 配置、文档、脚本里的 clone 链接，全部替换成新地址。
• 旧平台不要急着关停，并行运行两到四周，给团队缓冲和适应的时间。

5.4 CI/CD 集成与 Runner 配置

版本控制工具搭完之后，接 CI/CD 是顺理成章的下一步。GitLab Runner 的安装类型要选对，Kubernetes 环境用 Kubernetes Executor，普通服务器用 Shell 或 Docker Executor 即可。

Runner 注册的时候有一个 token 概念，不同版本的 GitLab 获取路径不同，但都在管理区域的 Runner 页面里。注册完成之后，在项目里新建.gitlab-ci.yml，GitLab 就会根据配置自动创建流水线并匹配 Runner。

一个小建议：Runner 和 GitLab 主服务尽可能放在同一内网，避免公网传输代码和制品时的带宽瓶颈。如果是跨地域团队，可以考虑为单一代码仓库配置镜像克隆地址，把 fetch 压力分散到就近节点。

6. 几个容易忽视但影响很大的维护细节

很多团队部署完版本控制工具就放着不管了，等出了事故才想起来。这几个维护维度的坑我全部踩过，属于“平时看不见，出事就要命”的类型。

6.1 备份与恢复永远要提前演练

GitLab 的备份命令很简单：

gitlab-backup create

但恢复正常吗？建议每季度做一次“备份恢复演练”，在测试服务器上把备份文件恢复起来，验证数据和权限是否完整。如果这个动作从来没做过，等于你在裸奔。备份文件不要只放在本机磁盘，复制一份到异地存储或对象存储里，防止单机房事故。

6.2 大文件的处理策略

Git 本身不适合存大文件。如果你发现仓库克隆速度越来越慢、仓库体积膨胀异常，按这个顺序去排查：

• git count-objects -vH看仓库对象体积。
• 检查是否有二进制文件、日志文件被误提交进仓库。
• 考虑使用 Git LFS 管理大文件，或者把大的静态资源挪到制品仓库/对象存储里，代码仓库只保留引用。

6.3 安全配置与账号管理

改默认端口这件事见仁见智，但对外开放的服务建议至少做好三件事：

• 开启防火墙，只暴露 80/443，管控 SSH 端口来源 IP。
• 全员开启两步验证（2FA），对管理员账号强制要求。
• 定期审查管理员权限，权限最小化，离开项目的成员及时移除，这个最重要。

版本控制工具的权限模型一般分 Owner、Maintainer、Developer、Reporter、Guest 几类。实际设置时不要图省事全给 GitLab 权限，按角色分好，既保护代码也保护发布流程。

7. 我的最终推荐与真实心得

作为一个从 GitHub 公共仓库起步、踩过私有化部署各种坑的人，我给不同阶段的团队一个明确的选型建议：

• 10 人以内、服务器资源有限、不想折腾太多：直接用 Gitea，半小时就能搭完，维护成本几乎为零。
• 20 人以上、或者需要 CI/CD、制品库、安全扫描一站式解决：直接上 GitLab，按企业级标准来配置。
• 对评审流程有特殊要求的团队：可以考虑 Gerrit，但也要接受它的学习成本。

我个人的真实使用体会是：工具好不好用，不完全看功能列表，更要看它能不能顺着团队已经习惯的流程走。GitLab 之所以适合大多数团队，是因为它的 Merge Request 工作流和分支保护做得足够顺滑，团队成员几乎只需要改变“从直接 push 改成发 MR”这一个习惯。而 Gitea 胜在轻巧，适合希望基础设施极简的小团队。

最后给一个建议：不管选哪套工具，先在测试环境把数据备份、灾难恢复、权限审计这些“不常用但保命”的功能全部验证一遍，再正式启用。等出问题了才临时研究，那个时候越着急越容易犯错。