公司 Java 开发日常 Git 真实工作流（互联网 / 后端通用）

目录

一、分支模型（最常用：GitFlow / 简化版 GitFlow，绝大多数中小公司用简化版）

二、一天完整的 Git 操作流程（Java 开发真实日常）

1. 上班第一件事：拉最新代码，保证本地代码和远端同步

2. 新建自己的功能分支（从最新 dev 分支创建）

3. 开发过程：频繁小提交（不要一次性写几千行再提交！）

4. 开发完成，自测完毕 → 推送到远程仓库

5. CR 阶段，如果同事提了修改意见

6. CR 通过 → 合并 MR 到 dev 分支

7. 上线流程

线上紧急 bug（hotfix 流程）

三、日常高频 Git 命令（Java 后端最常用）

四、IDEA 里可视化操作（大多数 Java 开发不爱敲命令，直接用 IDEA）

五、Java 开发踩坑高频点（真实工作里最容易翻车）

六、不同团队差异

核心原则：永远不在主分支直接改代码；每个人基于最新分支拉自己的开发分支；提交规范；合并前 Code Review；上线分支单独管理不同公司略有差异（有的用 GitLab、Gitee、GitHub），底层操作一致，Java 后端一般配合 Maven/Gradle、IDEA、Jenkins 一起用。

一、分支模型（最常用：GitFlow / 简化版 GitFlow，绝大多数中小公司用简化版）

分支约定（团队提前定好命名规范）

1. main/master：生产环境代码，受保护，禁止直接 push，只能合并，需要 CR
2. dev：开发环境主分支，所有开发功能合并到这里，日常开发基准分支
3. feature/xxx：功能分支，每个人写新需求就从 dev 拉这个分支
   • 命名示例：feature/user-login、feature/charge-order（智慧充电项目类似命名）
4. bugfix/xxx：开发环境 bug 修复分支，从 dev 拉出
5. hotfix/xxx：线上紧急 bug，从 main/master 拉出，修复后合并回 main 和 dev
6. release/v1.2.0：版本预发布分支，准备上线打包用

小团队简化版：去掉 release，只用 main、dev、feature、bugfix、hotfix

二、一天完整的 Git 操作流程（Java 开发真实日常）

1. 上班第一件事：拉最新代码，保证本地代码和远端同步

bash

# 1. 切到dev分支 git checkout dev # 2. 拉取远端最新代码（别人昨天提交的代码） git pull origin dev

IDEA 里可以直接点底部 Git → Pull，不用敲命令。 ✅ 目的：防止你基于旧代码开发，后面合并大量冲突，Java 项目经常在实体类、Mapper、接口处冲突。

2. 新建自己的功能分支（从最新 dev 分支创建）

bash

git checkout -b feature/order-list # 等价于：先创建分支，再切换过去

之后所有写的 Java 代码、xml、yml 配置，都在这个 feature 分支上。

3. 开发过程：频繁小提交（不要一次性写几千行再提交！）

写一部分功能，本地自测跑通（单元测试、本地启动 SpringBoot 能跑）就提交。

bash

# 查看哪些文件改动 git status # 添加改动文件 . 代表所有改动（也可以指定单个java文件） git add . # 提交注释，规范格式很重要，团队一般规定：类型(模块):描述 # 类型：feat新增功能 / fix修复bug / refactor重构 / docs文档 / test单元测试 git commit -m "feat(order): 新增订单分页查询接口"

只是本地提交，还没推到远程仓库。 遇到写崩了，想撤销本地修改：git checkout -- 文件名丢弃本地改动。

小技巧：不要把 target/、.idea、.classpath、日志文件提交！靠.gitignore忽略，Java 项目必备。

gitignore

target/ .idea/ *.iml *.log

4. 开发完成，自测完毕 → 推送到远程仓库

bash

git push origin feature/order-list

推送后，在 GitLab/Gitee 页面新建合并请求 (MR/PR)：

• 源分支：feature/order-list
• 目标分支：dev
• 填写：需求简述、改动点、自测情况、是否影响数据库、注意事项
• 指定同事做 Code Review（CR），Java 后端重点看：空指针、事务、SQL、异常处理、参数校验。

5. CR 阶段，如果同事提了修改意见

在本地继续改代码，继续提交，然后push 到同一个远程 feature 分支，MR 会自动更新：

bash

git add . git commit -m "fix(order): 修改分页参数校验" git push origin feature/order-list

✅ 重要：如果这段时间 dev 有其他人合并了代码，远端 dev 已经更新，需要在本地把 dev 合并进自己 feature 分支，解决冲突

bash

# 先拉dev最新 git checkout dev git pull origin dev # 切回自己分支，合并dev git checkout feature/order-list git merge dev

这时如果出现冲突（比如同一个 Mapper 文件两个人改了），IDEA 会弹出冲突编辑器，手动解决冲突。 解决完冲突后：

bash

git add . git commit -m "merge: 合并dev最新代码，解决冲突" git push origin feature/order-list

MR 页面就能看到冲突已经解决，通知同事重新 CR。

6. CR 通过 → 合并 MR 到 dev 分支

由 ** 合并人（一般组长 / 负责人）** 在网页点合并，不要自己本地 merge dev 然后 push（规范团队会保护 dev 分支，禁止直接 push）。 合并完成后，远程 feature 分支可以删除（网页上勾选删除源分支）。

7. 上线流程

到版本提测，从 dev 拉出 release 分支给测试；测试通过后，release 合并进 main，打 tag 标记版本：

bash

# 打版本标签 git tag v1.2.0 git push origin v1.2.0

Jenkins 流水线会识别 tag，打包 Java jar 包，部署到生产环境。

线上紧急 bug（hotfix 流程）

1. 从 main 拉 hotfix 分支hotfix/order-timeout
2. 修改修复，提交、MR 合并回 main，同时也要合并回 dev（不然下版开发还带着这个 bug）
3. main 合并后打 tag，走紧急上线。

三、日常高频 Git 命令（Java 后端最常用）

bash

# 查看本地分支 git branch # 查看远程分支 git branch -r # 丢弃本地所有未提交改动 git reset --hard # 回退到上一个提交（本地） git reset --hard HEAD~1 # 查看提交记录 git log # 暂存临时改动（写一半要切分支，不想提交） git stash git stash pop

四、IDEA 里可视化操作（大多数 Java 开发不爱敲命令，直接用 IDEA）

1. 底部 Git 面板：Pull / Push / Commit
2. Branches：切换分支、新建分支、Merge 分支
3. Merge 冲突：IDEA 可视化三方对比工具，比命令行好解决 Java 代码冲突
4. 提交窗口：勾选文件，填写 commit message

五、Java 开发踩坑高频点（真实工作里最容易翻车）

1. ❌ 直接在 dev 分支写代码，写完直接 push：多人并行开发，很容易污染 dev
2. ❌ 不先 pull dev 最新代码就合并，大量冲突，甚至覆盖别人代码
3. ❌ commit 注释乱写：修复问题、改代码，后期查提交记录根本看不懂
4. ❌ 把 target、本地 yml 配置、数据库密码提交到 git，安全事故
5. ❌ 冲突时直接无脑接受我方改动，覆盖掉同事写好的逻辑
6. ❌ 一次提交几万行代码，CR 根本没法看，出问题不好回滚

六、不同团队差异

• 大厂：分支严格保护，强制 CR，CI 流水线自动编译 Java、跑单元测试，不通过不让合并；
• 中小公司：简化流程，有些团队不严格做 CR，但依然禁止直接往 main 提交；
• 部分团队用Gitlab Flow：没有单独 dev 分支，feature 合并到 main，用 tag 管理版本。