Git

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 开发过程中可能产生几个有意义的提交： ...