GitLab+IDEA 企业级项目团队多环境Git操作教程（后端新人版）

GitLab+IDEA 多环境Git操作教程（后端新人版）

你需要在原有教程基础上，补充适配dev（开发）、test（测试）、uat（预生产）、prod（生产） 多环境的Git分支管理和代码操作流程，本教程依然面向后端新人，以IDEA可视化+GitLab页面操作为核心，明确各环境对应的分支规范、代码发布流程、环境回滚等关键场景，贴合企业级多环境发布的实际业务。

一、多环境对应的分支规范（核心！必须严格遵守）

企业多环境的核心原则是「环境与分支一一对应，禁止跨环境直接提交代码」，后端新人需牢记各分支的用途和操作权限：

环境类型	对应分支名称	核心用途	操作权限	后端注意点
开发环境（dev）	dev	日常开发联调、接口自测，功能分支合并的第一站	仅通过MR合并，禁止直接提交	联调时使用application-dev.yml配置
测试环境（test）	test	测试人员功能测试、回归测试，从dev分支合并	测试/开发协作，仅MR合并	测试环境需配置测试数据库、第三方测试接口
预生产环境（uat）	uat	产品/客户验收测试，数据/配置与生产环境一致，从test分支合并	仅管理员/发布负责人合并	uat环境需模拟生产配置，禁止修改核心配置
生产环境（prod）	master/main	线上正式环境，仅从uat分支合并，发布后打Tag标记版本	仅运维/核心负责人操作	生产环境配置严格保密，需走发布审批流程
功能分支	feature/xxx	开发单个功能，从dev分支拉取，完成后合并回dev	新人主要操作分支	仅改动自己负责的模块，避免影响全局
热修复分支	hotfix/xxx	修复生产/uat bug，从master/uat分支拉取，修复后同步到对应环境分支	按需创建，需审批	热修复仅改bug，不新增功能，优先验证uat环境

补充：部分团队会用 release/版本号 作为test/uat的过渡分支（如release/v1.2.0），本质是test/uat分支的「临时发布分支」，操作逻辑和环境分支一致。

二、多环境核心业务场景（IDEA+GitLab操作）

场景1：完整的多环境代码发布流程（新人开发功能全链路）

这是后端新人最核心的流程，覆盖「功能开发→dev联调→test测试→uat验收→prod发布」全链路，所有环境分支的代码合并必须通过MR，禁止本地直接合并：

步骤1：从dev分支拉取功能分支（开发前准备）

1. IDEA右下角切换到 dev 分支 → 点击顶部Git→Pull，同步dev最新代码（避免和他人代码冲突）；
2. 点击分支名称→New Branch，按规范命名功能分支（如feature/order-创建订单接口-10090）→Create；
3. 开始开发代码（后端需编写接口、Service、Mapper，同时维护application-dev.yml配置）。

步骤2：功能完成后合并到dev分支（dev环境联调）

4. 本地提交代码（按规范写提交信息：feat(order): 新增创建订单接口）→ 推送功能分支到GitLab；
5. 登录GitLab→进入项目→Merge Requests→New merge request；
6. 「Source branch」选自己的功能分支，「Target branch」选dev；
7. 填写MR标题（和提交信息一致）、描述（如「创建订单接口，支持商品ID和数量参数，自测通过」）；
8. 选择审核人（团队leader/联调对接人）→Create merge request；
9. 审核通过后，由审核人合并代码到dev分支（新人无需自己合并）；
10. 合并完成后，后端新人可在dev环境部署代码，进行接口联调、自测。

步骤3：dev联调通过后合并到test分支（测试环境测试）

此步骤通常由测试负责人/发布负责人操作，新人需配合：

11. GitLab提MR：「Source branch」选dev，「Target branch」选test；
12. 附测试提测单链接、功能清单，通知测试人员开始测试；
13. 测试过程中发现bug：新人从dev分支重新拉feature/xxx-bugfix分支修复→合并回dev→再同步到test（禁止直接改test分支）。

步骤4：test测试通过后合并到uat分支（验收环境验收）

14. 由发布负责人提MR：「Source branch」选test，「Target branch」选uat；
15. 验收环境部署代码后，产品/客户验收；
16. 验收发现问题：修复流程同test环境（先修dev→同步test→同步uat）。

步骤5：uat验收通过后发布到prod环境（生产环境）

17. 发布前准备：在GitLab的master分支页面→Tags→New tag，打版本Tag（如v1.2.0），标注版本内容；
18. 提MR：「Source branch」选uat，「Target branch」选master，附发布审批单；
19. 审批通过后，由运维/发布负责人合并代码并部署到生产环境；
20. 发布完成后，新人需监控生产环境接口是否正常，如有问题走热修复流程。

场景2：多环境代码同步（新人配合操作）

后端新人常遇到「dev分支代码需同步到自己的功能分支」「test分支bug修复后同步到dev」等场景，核心操作是「拉取目标环境分支代码到本地功能分支」：

示例：将dev最新代码同步到自己的feature分支（避免联调冲突）

21. IDEA右下角切换到自己的feature/xxx分支；
22. 点击顶部Git→Pull；
23. 在弹出的窗口中，「Remote」选origin，「Branch to pull」选dev→点击Pull；
24. 若出现冲突（如多人改了同一个接口类），按下方「冲突解决」步骤处理；
25. 解决冲突后，重新提交并推送功能分支。

场景3：多环境下的bug修复（分2类场景）

场景A：test/uat环境bug（未发布到生产）

26. 从dev分支拉取bug修复分支：bugfix/order-订单金额显示错误-10091；
27. 修复代码后，先合并到dev分支（MR），联调验证；
28. 验证通过后，提MR将bugfix/xxx合并到test（或uat）分支，测试/验收验证；
29. 所有环境验证通过后，删除bugfix分支。

场景B：生产环境bug（紧急热修复）

30. 从master分支拉取热修复分支：hotfix/order-支付失败-10092；

31. 修复代码后，先提MR合并到uat分支，验收环境验证（必须！避免修复引入新问题）；

32. uat验证通过后，提2个MR：

    1. 源分支hotfix/xxx→目标分支master（生产环境修复）；
    2. 源分支hotfix/xxx→目标分支dev（同步修复到开发分支，避免后续发布重复出现）；

33. 合并完成后，运维部署生产环境，新人监控修复效果。

场景4：多环境配置文件管理（后端重点）

后端多环境的核心是「配置隔离」，新人需避免改混不同环境的配置文件：

34. 项目中配置文件命名规范：application-dev.yml（dev）、application-test.yml（test）、application-uat.yml（uat）、application-prod.yml（生产）；

35. IDEA中开发时，通过「运行配置」选择对应环境：

    1. 点击IDEA顶部「Run/Debug Configurations」→ 选择后端启动类；
    2. 在「VM options」中添加：-Dspring.profiles.active=dev（指定dev环境）；

36. 提交配置文件时，务必确认只修改当前开发环境的配置（如dev），禁止直接修改prod配置；

37. 生产环境配置通常由运维通过配置中心管理，新人无需提交prod配置到代码仓库。

场景5：多环境代码回滚（发布后发现问题）

场景A：dev/test环境回滚（新人可操作）

38. 登录GitLab→进入对应环境分支（如test）→Repository→Commits；
39. 找到发布前的最后一个正常提交（如版本Tagv1.1.9对应的Commit ID）；
40. 通知管理员/发布负责人提MR：将分支回滚到该Commit ID（GitLab页面可直接操作「Revert」）；
41. IDEA中拉取回滚后的分支代码，验证环境是否恢复正常。

场景B：uat/prod环境回滚（需审批）

42. 禁止新人直接操作！需提交回滚审批单，由运维/发布负责人执行；
43. 核心逻辑：通过GitLab的「Tag」回滚到上一个稳定版本（如从v1.2.0回滚到v1.1.9）；
44. 回滚后，新人需在dev分支修复问题，重新走发布流程。

场景6：GitLab页面查看多环境分支状态（新人必知）

45. 登录GitLab→项目→Repository→Branches；
46. 可筛选查看dev/test/uat/master分支的最新提交、最后更新人；
47. 点击分支名称→Compare，可对比不同环境分支的代码差异（如dev和test的差异）；
48. 新人可通过此功能，确认自己的功能代码是否已合并到对应环境分支。

三、多环境操作禁忌（新人必须规避）

49. 禁止直接在dev/test/uat/master分支上开发、提交代码，所有修改必须通过功能/bugfix分支+MR；
50. 禁止跨环境合并代码（如直接将feature分支合并到test），必须按「dev→test→uat→prod」流程；
51. 禁止强制推送dev/test/uat/master分支（即使是自己的误操作，需联系管理员处理）；
52. 禁止修改其他环境的配置文件（如在dev分支改application-uat.yml）；
53. 热修复分支合并后，必须同步到所有下游环境（如修复prod后同步到dev），避免后续发布重复出问题。

总结

54. 核心流程：功能分支从dev拉取→合并到dev（联调）→合并到test（测试）→合并到uat（验收）→合并到master（生产），全程通过MR操作；
55. 环境隔离：配置文件按环境拆分，分支与环境一一对应，禁止跨环境操作；
56. 风险控制：uat/prod环境的修改/回滚需审批，热修复需先验证uat再发布生产，所有操作留痕（Commit/Tag/MR）。

新人初期可先聚焦「dev环境的功能开发和MR提交」，熟悉后再配合测试/uat环境的同步操作，遇到多环境相关问题优先咨询团队发布负责人，避免因操作失误影响其他环境的正常运行。