git手册

常用命令

切换到newBranch分支
git switch newBranch

对比两个分支
git diff Branch1 Branch2 --stat

对比某个文件在两文分支中的区别

git diff Branch1 Branch2 -- src/main/java/cn/bugstack/springframework/beans/factory/BeanFactory.java

添加到暂存区

git add .

提交到本地仓库

git commit -m "commit message"

第一次推送到远程仓库

git push git@github.com:UserName/repository.git main

推送到远程仓库

git push origin main

git push

创建新分支，提起Pull Request请求远程仓库主干管理员合并分支

切换到主分支 main

git checkout main

拉取远程主分支

git pull origin main

在当前分支拉取新分支

git checkout -b feature/step-02-bean-definition-registry

首次推送到远程关联分支

git add .
git commit -m "feat: 引入BeanDefinition与注册表机制，完成Bean容器的抽象"
git push -u origin feature/step-02-bean-definition

# 切回主干并同步最新的代码
git checkout main
git pull origin main

# 给这个完美的里程碑打上 Tag
git tag -a v0.2 -m "完成 BeanDefinition 抽象与注册"

# 将 Tag 推送到云端
git push origin v0.2

# 删掉已经完成使命的本地特性分支，保持整洁（可选）
git branch -d feature/step-02-bean-definition

commit 规范

核心公式

标准的 Commit Message 应该遵循以下格式：

[任务号] <type>(<scope>): <subject>

(注：如果企业没有硬性要求将任务号放在最前面，也可以放在主体内容中，但前置任务号在企业级协同中最利于追踪。)

1. <type>：改动类型（核心）

这是最关键的部分，直接说明了这次提交的性质。建议团队只保留以下 8 个高频核心类型，避免选择困难：

类型 (Type) 含义 Java 后端典型场景
feat 新功能 (Feature) 新增接口、引入新的中间件、实现新业务逻辑
fix 修复 (Bug Fix) 修复测试缺陷、修复线上 NPE、修复死锁等
refactor 重构 提取公共方法、设计模式改造（不改变外在行为）
perf 性能优化 SQL 慢查询优化、加入 Redis 缓存、优化并发逻辑
test 测试 新增 JUnit 单元测试、Mockito 补充、集成测试
chore 杂项/构建 修改 pom.xml/build.gradle、更新 CI/CD 脚本
docs 文档 修改 README.md、更新 Swagger 注释或接口文档
style 代码格式 消除 Checkstyle 警告、格式化代码（不影响逻辑）

2. <scope>：影响范围（Java 特色）

在 Java 后端开发中，<scope> 用于快速定位改动发生的模块或架构分层。通常有两种划分维度（选其一即可）：

  • 按微服务/多模块划分（推荐）：order-api, user-service, common-utils
  • 按架构分层划分：controller, service, mapper, config

3. <subject>：简短描述

对本次修改的简要说明，遵守以下精简原则：

  • 动宾结构：以动词开头（如：新增、修改、修复、优化）。
  • 精简明了：限制在 50 个字符以内。
  • 结尾无句号：不需要以句号结尾。

💡 企业级实战示例

1. 日常业务开发（带 Jira 任务号）：

[ORD-1024] feat(order-service): 新增创建订单的分布式事务处理

2. 紧急 Bug 修复：

[BUG-9527] fix(user-mapper): 修复按手机号查询用户时的 SQL 语法错误

3. 代码重构：

[TEC-001] refactor(pay-core): 提取微信和支付宝支付的公共策略接口

4. 依赖项升级 (杂项)：

[SEC-404] chore(pom): 升级 fastjson 版本至 1.2.83 以修复安全漏洞

🛠️ 注意

  1. 原子性提交（Atomic Commits）：一个 Commit 只做一件事。千万不要把“写新接口”和“格式化整个项目代码”混在一个 Commit 里，否则 Code Review 将是灾难。
  2. 强制校验：人为约定不如工具约束。建议在项目中接入 Git Hooks（例如使用 Husky 结合 commitlint，或者使用 Maven 插件 git-commit-id-plugin / commitlinter-maven-plugin）在提交时自动拦截不合规的 Commit。
  3. IDEA 插件辅助：推荐团队全员安装 IntelliJ IDEA 的 Git Commit Template 插件，可以直接通过 UI 界面填表生成标准规范，零学习成本。

分支命名规范

📌 核心规则

格式：<类型>/<任务号>-<描述>

🔧 五大类型

feature/  # 新功能开发
bugfix/   # 问题修复  
hotfix/   # 紧急修复
release/  # 版本发布
refactor/ # 代码重构

✅ 实用示例

feature/ORD-101-add-payment
bugfix/AUTH-202-fix-login
hotfix/v1.0.1-security-patch
release/v2.0.0

⚡ 工作流示例

# 1. 从最新 develop 创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/TASK-123-add-user-api

# 2. 开发并提交代码
git add .
git commit -m "[TASK-123] feat(user): add user registration API"

# 3. 推送到远程
git push origin feature/TASK-123-add-user-api

# 4. 创建 Pull Request 到 develop
# （在 GitLab/GitHub 界面操作）

💡 核心价值

  • 清晰识别：一看即懂分支用途
  • 高效协作：团队沟通成本降低
  • 自动化友好：CI/CD 精准触发

核心价值

  • 清晰识别：一看即懂分支用途
  • 高效协作：团队沟通成本降低
  • 自动化友好：CI/CD 精准触发

💡自动化

分支命名校验

# 使用 pre-commit hook 校验分支名
# .git/hooks/pre-commit 示例：
#!/bin/bash
current_branch=$(git symbolic-ref --short HEAD)
if [[ ! $current_branch =~ ^(feature|bugfix|hotfix|release)/[A-Z]+-[0-9]+-.+$ ]]; then
    echo "❌ 分支命名不符合规范"
    echo "格式应为：<类型>/<项目>-<编号>-<描述>"
    exit 1
fi
posted @ 2026-03-02 12:06  Nickey103  阅读(0)  评论(0)    收藏  举报