git 分支合并：什么时候用 merge，什么时候用 rebase

Tue, 16 Jun 2026 10:35:30 +0800

AI 编程工具让代码生成、重构和修复变得越来越快，但它也放大了另一个问题：改动来得越快，越需要清晰的版本历史来解释这些改动从哪里来、为什么发生、何时进入稳定版本。

作为版本管理工具，Git 在 AI 编程时代扮演着越来越重要的角色，它可以为工程协作提供的时间线、审计记录和回滚机制。越是在 AI 能快速生成大量代码的场景下，越需要理解标准工作流，避免把临时实验、半成品功能和稳定发布混在一起。

Git 命令本身往往不是难点，难点在于搞清何时用它们。

git merge [--no-ff|--squash]、git rebase 都能把改动带到另一个分支，但它们对提交历史的处理完全不同。什么时候应该用 merge，什么时候应该用 rebase？这就是本文要回答的问题。下面以一个虚构项目 world-cup-dashboard 为例，说明这两个命令的用法，最后推荐一种围绕 git 工具的项目开发流程。

1. 分支约定

通常，一个项目会有三类分支：

main       稳定发布分支
dev        日常集成分支
feature/*  单个功能分支

下面的命令，会初始化项目，并建立 dev 分支：

git init
git add .
git commit -m "Initial project"
git switch -c dev

项目开发流程：main 保持稳定，日常改动先进 dev，较大的任务从 dev 拉 feature/*。

2. 在 feature 分支开发功能

假设要做赛程页面，从 dev 分支上新建一个 feature/schedule-page 分支：

git switch dev
git switch -c feature/schedule-page

开发过程中可能产生几个有意义的提交：

Git Merge on 楠楠自瑜

git 分支合并：什么时候用 merge，什么时候用 rebase

1. 分支约定

2. 在 feature 分支开发功能