ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

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

2026/9/14 22:09:44 拓冰建站 浏览量
公司 Java 开发日常 Git 真实工作流(互联网 / 后端通用) 目录一、分支模型最常用GitFlow / 简化版 GitFlow绝大多数中小公司用简化版二、一天完整的 Git 操作流程Java 开发真实日常1. 上班第一件事拉最新代码保证本地代码和远端同步2. 新建自己的功能分支从最新 dev 分支创建3. 开发过程频繁小提交不要一次性写几千行再提交4. 开发完成自测完毕 → 推送到远程仓库5. CR 阶段如果同事提了修改意见6. CR 通过 → 合并 MR 到 dev 分支7. 上线流程线上紧急 bughotfix 流程三、日常高频 Git 命令Java 后端最常用四、IDEA 里可视化操作大多数 Java 开发不爱敲命令直接用 IDEA五、Java 开发踩坑高频点真实工作里最容易翻车六、不同团队差异核心原则永远不在主分支直接改代码每个人基于最新分支拉自己的开发分支提交规范合并前 Code Review上线分支单独管理不同公司略有差异有的用 GitLab、Gitee、GitHub底层操作一致Java 后端一般配合 Maven/Gradle、IDEA、Jenkins 一起用。一、分支模型最常用GitFlow / 简化版 GitFlow绝大多数中小公司用简化版分支约定团队提前定好命名规范main/master生产环境代码受保护禁止直接 push只能合并需要 CRdev开发环境主分支所有开发功能合并到这里日常开发基准分支feature/xxx功能分支每个人写新需求就从 dev 拉这个分支命名示例feature/user-login、feature/charge-order智慧充电项目类似命名bugfix/xxx开发环境 bug 修复分支从 dev 拉出hotfix/xxx线上紧急 bug从 main/master 拉出修复后合并回 main 和 devrelease/v1.2.0版本预发布分支准备上线打包用小团队简化版去掉 release只用 main、dev、feature、bugfix、hotfix二、一天完整的 Git 操作流程Java 开发真实日常1. 上班第一件事拉最新代码保证本地代码和远端同步bash# 1. 切到dev分支 git checkout dev # 2. 拉取远端最新代码别人昨天提交的代码 git pull origin devIDEA 里可以直接点底部 Git → Pull不用敲命令。 ✅ 目的防止你基于旧代码开发后面合并大量冲突Java 项目经常在实体类、Mapper、接口处冲突。2. 新建自己的功能分支从最新 dev 分支创建bashgit 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 项目必备。gitignoretarget/ .idea/ *.iml *.log4. 开发完成自测完毕 → 推送到远程仓库bashgit push origin feature/order-list推送后在 GitLab/Gitee 页面新建合并请求 (MR/PR)源分支feature/order-list目标分支dev填写需求简述、改动点、自测情况、是否影响数据库、注意事项指定同事做 Code ReviewCRJava 后端重点看空指针、事务、SQL、异常处理、参数校验。5. CR 阶段如果同事提了修改意见在本地继续改代码继续提交然后push 到同一个远程 feature 分支MR 会自动更新bashgit 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 会弹出冲突编辑器手动解决冲突。 解决完冲突后bashgit add . git commit -m merge: 合并dev最新代码解决冲突 git push origin feature/order-listMR 页面就能看到冲突已经解决通知同事重新 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.0Jenkins 流水线会识别 tag打包 Java jar 包部署到生产环境。线上紧急 bughotfix 流程从 main 拉 hotfix 分支hotfix/order-timeout修改修复提交、MR 合并回 main同时也要合并回 dev不然下版开发还带着这个 bugmain 合并后打 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底部 Git 面板Pull / Push / CommitBranches切换分支、新建分支、Merge 分支Merge 冲突IDEA 可视化三方对比工具比命令行好解决 Java 代码冲突提交窗口勾选文件填写 commit message五、Java 开发踩坑高频点真实工作里最容易翻车❌ 直接在 dev 分支写代码写完直接 push多人并行开发很容易污染 dev❌ 不先 pull dev 最新代码就合并大量冲突甚至覆盖别人代码❌ commit 注释乱写修复问题、改代码后期查提交记录根本看不懂❌ 把 target、本地 yml 配置、数据库密码提交到 git安全事故❌ 冲突时直接无脑接受我方改动覆盖掉同事写好的逻辑❌ 一次提交几万行代码CR 根本没法看出问题不好回滚六、不同团队差异大厂分支严格保护强制 CRCI 流水线自动编译 Java、跑单元测试不通过不让合并中小公司简化流程有些团队不严格做 CR但依然禁止直接往 main 提交部分团队用Gitlab Flow没有单独 dev 分支feature 合并到 main用 tag 管理版本。