企业官网建设流程全解析

刚接手团队那阵子，我干过一件蠢事：花了一整天把仓库里所有分支全部清理干净，觉得"整洁"就是管理到位了。结果第二天，两个同事分别来找我——一个说他在一个我已经删掉的分支上做了一周的功能，另一个说我的清理动作让他本地环境直接没法跑。那次之后我才明白，带小团队的代码仓库，跟管理自己的私人仓库完全是两码事。你的每一个操作都会乘上团队人数，变成团队的摩擦成本。

这篇文章写给刚带小团队、或者对代码仓库管理还没有成体系的lead，讲一讲我在实际操盘中总结出来的东西：仓库怎么搭、分支怎么管、权限怎么放、Code Review怎么做、CI怎么接，以及在国内用得最多的Gitee上那些高频坑位怎么避开。不堆理论，只说按下过的操作。

1. 接手仓库的第一步：别急着翻新，先给仓库做一次体检

你刚到一个团队，或者新提为lead，最忌讳的就是"新官上任三把火"直接烧仓库。因为你还不知道这个仓库哪些乱七八糟的东西是垃圾、哪些是"带刺的但有用"的东西。我建议先花一天时间，把仓库的真实状态摸清楚，再决定动哪些地方。

1.1 用几个命令看清仓库的全貌

不要依赖大家口述，直接看数据。我每次接手新仓库，固定会跑这样几组命令：

# 1. 看全部分支，包括远端已删除但本地还存在的 git branch -a # 2. 看提交历史，图形化最直观 git log --oneline --graph --all -50 # 3. 看每个分支与主分支的分叉情况 git fetch origin git log --oneline origin/master..origin/develop

这里有个细节很多人忽略：git branch -a看的是本地缓存里的远端分支，不一定是最新的。一定要先git fetch origin --prune清理掉远端已删除的引用，再看真实状态。

看完之后，我会做一张表格，列清楚：

这张表就是你的"仓库体检报告"。我做过的几个团队，最多的一个仓库里躺着47个分支，真正活着的不超过5个。但重点不是那些废弃分支本身，而是它们背后的两个管理信号：一是没有人敢删分支，怕删错；二是分支策略没人定，大家都是凭习惯开分支。这两个问题不解决，你清理一次也会在一周内长回来。

1.2 体检的重点不是分支是"协作关系"

体检的第二层，是看提交记录和合并记录，摸清团队的人力分配：

# 查看每个人的提交统计 git shortlog -sn --all # 查看最近一个月的合并记录 git log --oneline --merges origin/master -20

看什么？第一，是否绝大多数工作都集中在某一个人身上。第二，合并记录是规律出现还是一起爆发。如果是前者，说明仓库的日常维护其实是某个骨干在扛，你后续定规则必须把这个人的工作负荷考虑进去；如果是后者，说明大家平时憋着不提交、到交付前集中合，这种节奏下仓库乱几乎是必然的。

我刚带团队时就没注意这层，直接照搬了大厂的git flow模板，什么feature分支、develop分支、release分支全套上。结果一周后，一个后端同事私下说："lead，我们团队就五个人，我推一次代码要在两个分支间切来切去，光合并就花半小时。"那句话点醒了我——小团队的仓库管理，最怕的就是搬大组织的制度。制度的成本会直接落在每一个人的日常操作上，人越少，人均分摊的成本越高。

2. 单仓库还是多仓库：这道题不答好，后面全是坑

很多小团队lead做的第一个重大决定，就是"我们到底用几个仓库"。这个决定非常难改，因为业务做到一半再拆仓库、合仓库，痛苦程度不亚于重写一次。我的建议是，在定这个之前，先把团队的"事实"拿出来对照，而不是凭感觉拍脑袋。

2.1 两种方案的取舍，别只看习惯

对照这个表，我的经验是：三点一线做判断——团队成员超过10人且模块间边界清晰、各模块发布频率差异很大、需要给外部合作方按模块分权限，这三条里命中两条以上，才值得拆多仓库。否则，小团队老老实实用单仓库，把精力放在"仓库内怎么把目录结构理清楚"，远比拆来拆去划算。

2.2 单仓库怎么减少"一颗老鼠屎坏一锅汤"的情况

有人担心单仓库的权限太粗，谁都能看全部代码。这个担忧在小团队里基本不成立——小团队本来就应该是全栈都在一个池子里，互相能看到代码反而是好事，代码审查和信息流动都简单。

真正要注意的反而是目录结构：把业务模块按边界拆好，用目录隔离，而不是等代码堆到十万行再来治理。

app/ modules/ user/ order/ payment/ common/ utils/ middlewares/ docs/ scripts/ tests/

单仓库有一个反向问题：仓库越来越大，git clone越来越慢。这个后面在讲大文件处理时会细说，这里先提一句：如果你的单仓库超过两三年仍在频繁迭代，一定要从一开始就注意不要把构建产物、依赖包、大资源文件提交进去。

2.3 真要拆多仓库，先想清楚"拆的成本"

我也拆过。拆之前只想着各模块独立发布爽，拆之后才意识到：一个跨模块的需求，背后是三个仓库的MR要串行合并、三个CI要依次通过、三拨人要协调上线窗口。本来团队就小，这一套流程走下去，人直接就被流程吃掉了。

所以我的结论很明确：小团队、代码量在可接受范围内、业务方向还在快速变化期的，优先单仓库。等哪天业务真的稳定了、模块真的能独立演进和独立对外提供服务了，再考虑拆。拆可以慢慢拆，但一开始就把团队拖进多仓库的沟通成本里，很难有回头路。

3. 分支策略和权限模型：小团队最容易矫枉过正的一块

分支策略是技术社区里最容易吵起来的话题。Git Flow、GitHub Flow、GitLab Flow、主干开发，各有拥趸。小团队lead最该做的事情不是选一个最"正统"的，而是选一个让团队成员每天少想事儿的。

3.1 三种常见模式，小团队该怎么选

先说我踩过的坑。最早我照搬了教科书版的 Git Flow，常驻分支有 master、develop、release、hotfix，每人干活再开 feature。一个五人团队，仓库里常驻六个活跃分支，每次提交都要想"我应该推到哪个分支"。一周后我自己的耐心先耗尽了。

后来我换成了 GitHub Flow 的简化版：只有 main 一个常驻分支，所有新功能开分支，做完合并回 main，合并即发布。这个模式对小团队极其友好，因为它大幅度减少了对"分支代码到底在哪个环境生效"的心智负担。

我的推荐是：如果你的团队做的是互联网类产品、可以接受随时发布，用 GitHub Flow；如果你必须跟着固定版本周期走，可以在 GitHub Flow 基础上，只在发版前拉一条 release 分支做收敛，发完即刻合并回主干并删除。

3.2 保护分支设置是底线，但别保护过头

选完策略之后，紧接着就是保护分支。Gitee 和 GitLab 都有"保护分支"功能，规则是：指定分支（通常是 main）不允许任何人直接 push，所有改动必须通过合并请求（MR/PR）合入。

这个保护必须开。我在带团队初期遇到过这样的场景：一个同事直接在 main 上修了个错别字，修完就 push 上去了，其他同事在自己本地以 main 为基线开发，直接陷入了"为什么我本地跟你不一样"的困惑。那之后我设定：main 一律开启分支保护，谁也不能绕过 MR 直接推代码，包括我自己。管理者的权力不应该体现在"能随便直接改 main"，而应该体现在"能把仓库规则定得好用"。

但保护过头也是坑。常见情况是：lead 把 develop、release、test 全部设成保护分支，还要求每个分支合入都要关联任务单号。结果整个团队的节奏被卡死在"我推一个临时改动，还得等审批"。我的经验是：保护分支原则上只保护发布主干和长期稳定分支，其他临时分支宁可乱也不设卡。团队小，靠口碑和文化约束，比靠全链路审批有效得多。

3.3 权限模型：谁负责合并，谁负责质量

Gitee 的成员角色分 Owner、Master、Developer、Reporter 等。小团队建议这样分权限：

• Owner/仓库管理员：1人，负责仓库设置、保护分支规则、权限分配
• Master：1人，通常由技术负责人承担，负责最终合并把关
• Developer：团队开发者，可以开分支、提MR，但推不到保护分支
• Reporter：非研发角色，比如产品经理，给只读权限

这个模型里有两条经验：

第一，整个仓库的"最终把关"必须是一个人。合并权分散会导致风格不一致，一会儿允许强制合并，一会儿要求全部检查通过，成员会很困惑。

第二，给产品经理开只读权限是性价比极高的事。他们能直接看到需求的进度、代码的活跃度，减少"你们到底做到哪了"这种低效沟通。

4. 把Code Review做成真正的质量闸门，而不是走形式

说起 Code Review，小团队最常见的声音是："这么点代码，我们都是熟人，review啥呀""来不及了，先合上后面再补""这个改动太大了，我不想浪费时间看"。但我做了这么多年团队，越来越确定一件事：Code Review 不是为了审查彼此，而是为了让代码质量不再是"某一个人的个人习惯"。它应该是仓库质量的第一道闸门。

4.1 为什么你们的Review会在"形式"这一步卡住

Review 变成形式，几乎都是同一个原因：MR/PR 太大。一个 MR 里改了 30 个文件、横跨 6 个功能点，reviewer 打开看三眼就放弃治疗，顺手点通过。你去看，这个 MR 就是一个拆开的"乱炖"，结构上就不可能被有效审。

所以要让 Review 真正发生，第一步不是定什么规范，而是强制拆小 MR。我的习惯是一条原则：一个 MR 只做一件事，平均改动文件数控制在 5 个以内。这不是什么硬性标准，是一个"如果超过就要给出合理解释"的软约束。

拆小 MR 有双重的收益：reviewer 愿意看、看得明白，同时出现问题时的回滚也更精准。如果某次发布出问题，你可以精确回滚某一个 MR，而不是在一坨改动里大海捞针。

4.2 提交信息规范是最低成本的代码仓库规范

在拆小 MR 的基础上，下一步是统一提交信息。很多团队完全不规范，提交信息写"update""fix bug""改好了"的比比皆是。这带来的最直接问题就是：上线出问题时，你根本不知道哪个提交对应哪次改动。

我常用的规范是 Conventional Commits 的简化版：

<type>(<scope>): <subject> # 示例 feat(user): 增加用户头像上传能力 fix(order): 修复订单列表重复展示问题 chore(ci): 升级构建镜像版本 docs(readme): 补充本地开发环境说明

type 一般只需要 feat、fix、chore、docs、refactor 五种，scope 是模块名，subject 用中文简述改动意图。这套规范最大的好处不是"好看"，而是后续生成 changelog 和回溯问题时，可以直接用git log --grep按类型、按模块筛提交记录，效率提升非常明显。

4.3 合并方式的选择：squash 还是 merge

Gitee 的 MR 合并提供三种方式：合并（merge commit）、压平合并（squash）、变基合并（rebase）。我给小团队的建议是：默认用压平合并。

为什么？因为一个功能分支上通常会有十几个琐碎的提交（"加了一个空格""临时调试下""改回来"），这些过程性提交对整个仓库的历史来说是噪音。压平合并把整个分支的改动压成一个提交，历史干净，git log一目了然，回滚时也更简洁。

# 压平合并后，历史是这样的 * abc1234 feat(user): 增加用户头像上传能力 * def5678 fix(order): 修复订单列表重复展示问题 # 而不是这样 * xyz123 改回来 * xyz124 临时调试下 * xyz125 加了个空格 * xyz126 feat(user): 增加用户头像上传能力

配合这条规则，MR 的标题就必须写成一句完整的提交信息，因为压平合并后 MR 标题就是那条提交信息。这也反过来倒逼大家把 MR 标题写清楚。

4.4 让Review可以在小团队持续运转的三个机制

小团队的人都知道：大家都很忙，Review靠自觉基本会崩。我的做法是三个机制：

第一，建立"谁合并谁负责"的规则，但reviewer 必须轮值。每两个星期轮换一次，确保每个成员都有机会从"审查者"的视角看代码。这个视角对新人成长帮助极大。

第二，MR 描述里强制附上检查清单，例如：

- [ ] 本地构建通过 - [ ] 相关单测通过 - [ ] 已手动验证主要场景 - [ ] 无多余调试代码/日志

清单的意义在于降低成员"不知道审什么"的压力，也给 review 提供了一个最低可执行的标准线。

第三，Review 不只看代码逻辑，也要看"这个 MR 是否太小/太大""提交信息是否规范""是否有不相关的文件改动"。这些看似边角料的问题，恰恰是最容易被发现也最容易影响仓库健康的问题。

5. CI和自动化：让仓库自己守住底线，少靠人盯

小团队的最大软肋是：人少，活急，大家记性都不太好。一个团队五个人，总有人忘记跑测试、忘记格式化、忘记检查 lint。所以我才说，小团队是最需要 CI 的团队——自动化规则不是大厂的专属，它是把人从重复劳动里解放出来的工具。

5.1 最有性价比的几条自动检查规则

一开始不要追求全套质量门禁，那样配置成本高、失败频繁，会被团队抵触。从这四条起步就够了：

第五件值得做的是"构建产物禁止入库"检查，也就是防止有人把node_modules、target、dist、*.class这类目录或文件推上来。这类文件进仓库之后会持续污染仓库、拖慢 clone，非常难清理，检查的成本很低，收益极高。

5.2 在Gitee上搭一条能跑通的流水线

Gitee 提供 Gitee GO 这个 CI/CD 服务平台，可以在仓库的"流水线"菜单里直接配置，也可以绑定 Jenkins、Gitee Go 等外部工具。以 Gitee GO 为例，最小可用的配置是这样：

pipeline: name: 检查与测试 trigger: - event: merge_request stages: - stage: 构建 jobs: - job: 编译 run: | npm install --registry=https://registry.npmmirror.com npm run build - stage: 测试 jobs: - job: 单测 run: | npm run test:unit - stage: 代码检查 jobs: - job: lint run: | npm run lint

配置好之后，在仓库的"分支保护"规则里开启"合并前必须通过流水线检查"，这样成员提 MR 时，流水线会自动跑，不通过就没法合并。这比任何口头提醒都管用。

我在实际推动 CI 时遇到过一个很现实的阻力：流水线刚开始频繁失败，成员们怨声载道。这时候千万别硬扛，我当时的做法是降级标准——把失败率最高的检查项先设为"非阻塞"，跑一周，让团队先适应"提交后有一台机器帮我们查"这个模式，再把标准逐步收严。循序渐进的推行效果，远好过一步到位。

5.3 仓库自身的自动化细节：分支清理、标签与变更记录

除了 CI，仓库管理还有几个独立的自动化习惯：

第一，合入 MR 后自动删除源分支。Gitee 在合并 MR 时有个选项"合入后自动删除源分支"，建议默认勾选。这能从根本上防止"仓库里躺着一堆死分支"的问题。

第二，版本标签与发布记录挂钩。每次正式发布，在 main 分支打一个vX.Y.Z的 tag，并写明变更说明。长期做下来，回滚历史、排查线上问题都有据可查。

git tag -a v1.4.0 -m "v1.4.0：新增用户头像、修复订单重复支付问题" git push origin v1.4.0

第三，仓库根目录放一份清晰的 CONTRIBUTING.md。把分支命名方式、MR 要求、提交信息规范、本地如何跑检查和测试全部写进去。新成员入职第一天读这个文件，比 lead 口述十遍都有效。很多团队负责人忽略这个文档，其实它就是仓库的"宪法"。

6. Gitee上高频翻车点：上传、权限和大文件，我都排过坑

既然聊到国内团队的代码仓库，Gitee 的场景绕不开。我见过不少团队在 Gitee 上因为上传代码、配置权限这样的基本操作反复卡壳，这里集中写几个高频坑位和对应的排查方法。

6.1 上传代码到仓库时的最常见失败原因和排查顺序

"gitee上传代码到仓库"这个场景出问题的频率远高于想象。我的排查顺序永远是固定的：

第一，确认你推的分支是不是保护分支。如果你直接往 main 推，而 main 已被设置为保护分支，远端会直接拒绝，报protected branch错误。解决办法不是去找管理员放开权限，而是新建分支、提 MR。

第二，确认远端是否已经有人推过代码、产生了你没有的提交。这时候git push会被拒绝，提示你先 pull。正确操作是：

git pull --rebase origin main git push origin 你的分支

第三，确认用户名和邮箱是配置正确。很多新人换电脑后忘配 Git 身份，提交信息变成root@DESKTOP-xxx，仓库历史里就会出现一堆像乱码一样的提交人。建议在团队内推行下面的命令：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

顺带一提，Gitee 的登录密码和 Git push 的密码是两回事。如果你遇到remote: error: authentication require这类报错，优先检查是不是 Credentials 缓存里存的旧账号，或者项目是否已经切换到 SSH 方式。

6.2 密钥配置与.gitignore：两个最容易被忽略的基础项

SSH 密钥的配置，我这里把关键步骤写一遍，省得大家再去找：

# 1. 生成密钥，邮箱换成你自己的Gitee邮箱 ssh-keygen -t ed25519 -C "youremail@example.com" # 2. 查看公钥并复制到Gitee https://gitee.com/profile/sshkeys cat ~/.ssh/id_ed25519.pub # 3. 验证是否连通 ssh -T git@gitee.com

看到输出里有你的用户名，就说明密钥生效了。如果ssh -T提示 Host key verification failed，执行ssh-keyscan -t rsa gitee.com >> ~/.ssh/known_hosts后再重试。

.gitignore 的问题更阴间。最常见的坑是：某成员把本地依赖目录直接提交了，整个仓库多了上万个文件，所有人 clone 瞬间变慢。这事的处理顺序是：

第一步，加 .gitignore，把node_modules/、target/、dist/、.idea/、.vscode/、*.log、*.class等写进去。第二，要清理已提交的文件：

# 从仓库移除但保留本地文件 git rm -r --cached node_modules git commit -m "chore: 移除误提交的依赖目录" git push

这里有个操作安全的点：不要直接用git rm -r node_modules，加了--cached才会"从仓库删、本地留"，不加的话你本地文件都会没，别问我是怎么知道的。

6.3 大文件与仓库体积膨胀：LFS和仓库瘦身

小团队的项目跑着跑着，仓库 clone 越来越慢，十有八九是有人提交了二进制大文件——设计稿压缩包、安装包、数据集、模型文件。Git 的设计初衷是管理文本，不是当网盘。

处理方案首选 Git LFS（Large File Storage）。Gitee 也支持 LFS，官方有指引。安装后这样用：

git lfs install # 把需要走LFS的文件类型写进去 git lfs track "*.psd" "*.zip" "*.tar.gz" "*.model" # 提交 .gitattributes 让限制生效 git add .gitattributes git commit -m "chore: 配置LFS跟踪大文件类型"

已经推到历史里的大文件，单纯加 LFS track 并不会让历史瘦身。那个需要用到git filter-repo之类的重写历史工具，操作风险较高，大概率需要全员重新 clone。我的建议是：小团队不要轻易在项目进行到一半的时候重写历史。实在要清理，先把团队拉个会说——所有人都提交手头代码，然后约定一个时间点统一重写，全员强制换新克隆。

LFS 也有一个隐性坑：它的免费额度有限有总量限制，超了之后 push 会失败。所以最省心的大文件策略不是"用 LFS 扛"，而是"从源头不把大文件放进代码仓库"，能放对象存储的、放团队网盘的，就不要塞进仓库。

6.4 作为lead，如何从机制上减少团队在这类问题上的时间

把上面这些东西都碰到一遍之后，我现在的做法是五件事一起做，把很多问题扼杀在发生之前：

1. 团队仓库内统一放 .gitignore，并落实到初始化项目的脚手架里。
2. 在 README 或 CONTRIBUTING.md 里写清楚 SSH 密钥配置、如何 clone、如何提 MR。
3. 开启分支保护，main 不能直接 push，从机制上杜绝绕过流程的改动。
4. CI 流水线里加一项"仓库健康检查"，发现有大文件或者生成物入库就告警。
5. 新人入职第一天，安排一个"提交第一个 MR"的小任务，路径走通一遍，后面所有协作才有基础。

这些机制做到位之后，lead 基本就不需要每天去盯"谁又乱推了""谁没写提交信息"这些鸡毛蒜皮的事了。仓库的管理成本会大幅度下降。

7. 最后讲几句我踩完坑之后的体会

代码仓库这个东西很有意思，在代码之外，它其实是一个团队的协作镜子。你看到仓库里分支乱，背后多半是没人敢删、没人负责；你看到提交信息都写"update"，背后多半是大家赶进度、不习惯说清楚改动意图；你看到 Code Review 全是秒过，背后多半是 MR 太大、没人看得进去。所以管理代码仓库，表面上是在定规则，实际上是在帮团队培养一种透明的、可追踪的、低内耗的合作方式。

我的建议是，小团队的 lead 不必追求一步到位的豪华配置，从最基础的三件事开始：把 main 保护起来，把 MR 流程跑起来，把 CI 基础检查开起来。这三件事做完，仓库的基本秩序就有了。然后再慢慢把提交规范、自动化门禁、大文件治理一层层加上去。每条规矩都应该有一个目的——帮你少操一份心，帮团队成员少踩一个坑，而不是为了显得专业而增加繁琐流程。

仓库治理这件事做得好的团队，成员不会觉得"流程真多"，而是觉得"在这儿干活挺踏实"。你不会经常半夜被拉去处理合并冲突，也不会在发布前突然发现 main 上多了一个来路不明的提交。这种感觉，比任何漂亮的管理制度都值钱。