3、GitHub与GitLab平台：仓库管理、Webhook配置、Pull Request与Merge Request流程、Code Review最佳实践

3.1 两个平台，一个道理

GitHub和GitLab，说白了就是代码托管界的「可口可乐」和「百事可乐」。核心功能差不多，但细节上各有脾气。

我个人习惯：开源项目放GitHub，企业内部项目用GitLab。为什么？GitHub的社区生态太强了，Pull Request的讨论氛围特别好。而GitLab的自托管能力，对安全要求高的团队来说，简直是救命稻草。

我在项目中遇到过一家金融公司，代码绝对不能出内网。GitLab自部署，完美解决。你想想看，要是用GitHub，光合规审查就能让你崩溃。

3.2 仓库管理：别让代码变成垃圾场

仓库管理看似简单，其实坑不少。我见过太多团队，一个仓库里塞了十几个项目，分支乱得像蜘蛛网。

我的建议：

• 仓库粒度要细：一个微服务一个仓库，别搞「大仓模式」
• 分支命名规范：feature/xxx、bugfix/xxx、release/xxx
• 保护主干分支：master/main分支必须保护，禁止直接推送

3.3 Webhook配置：自动化的大门

Webhook这东西，说白了就是「当仓库发生某件事时，自动通知某个服务」。比如代码推送后自动触发CI构建。

配置要点：

平台	配置路径	常用事件
GitHub	Settings → Webhooks → Add webhook	push、pull_request、issues
GitLab	Settings → Webhooks → Add webhook	push、merge_request、tag_push

我曾经踩过一个坑：Webhook的Secret Token没配好，结果Jenkins收到了伪造的请求，差点把生产环境搞崩了。嗯，这里要注意：Secret Token一定要配，而且要用强随机字符串。

3.4 Pull Request与Merge Request流程

GitHub叫Pull Request（PR），GitLab叫Merge Request（MR）。名字不同，本质一样：让代码合并前经过审核。

标准流程：

1. 从主干分支拉出功能分支
2. 开发完成后，创建PR/MR
3. 指定Reviewer进行代码审查
4. 通过后合并到主干分支
5. 删除已合并的功能分支

我个人习惯在PR描述里写清楚三点：改了啥、为啥改、怎么测。别小看这个习惯，有一次我接手一个老项目，翻PR记录就能知道每个改动的前因后果，省了大把时间。

3.5 Code Review最佳实践

Code Review不是走过场，也不是找茬大会。它是团队知识传递和技术质量保障的关键环节。

我的经验：

• PR不要太大：200行以内最合适。超过500行的PR，Reviewer看着就想吐
• Reviewer要指定：别用「随机分配」，让最熟悉这块代码的人来审
• 评论要对事不对人：说「这段逻辑有隐患」，别说「你写的代码真烂」
• 及时响应：Reviewer提了意见，作者要在24小时内回复

我曾经在一个团队推行「四眼原则」：每个PR至少两个人Review通过才能合并。刚开始大家觉得麻烦，后来发现线上bug减少了60%。你想想看，多花10分钟Review，省下后面几小时的排查时间，这笔账划算得很。

3.6 平台差异与选择建议

GitHub和GitLab各有千秋，我列个对比表给你看：

维度	GitHub	GitLab
社区生态	★★★★★	★★★☆☆
自托管能力	★★☆☆☆	★★★★★
CI/CD集成	GitHub Actions	内置CI/CD
免费私有仓库	有限制	无限制

说白了，选哪个平台不重要，重要的是流程规范要落地。我见过用GitHub但流程一团糟的团队，也见过用GitLab但效率极高的团队。工具只是工具，人才是关键。