分支
你的使用场景——“尝试一个功能的开发，测试的时候会保存，这些保存只是用于测试，并不一定会合并到最终的项目中”——正是Git的**“分支 (Branch)”**功能要解决的核心问题。
最佳实践：功能分支工作流 (Feature Branch Workflow)
永远不要直接在
master (或 main) 分支上进行实验性开发！master 分支应该始终保持稳定、可随时发布的状态。正确的流程如下：
第一步：创建并切换到一个新的“功能分支”
在开始开发新功能或实验前，基于最新的
master 分支创建一个新分支。分支名要有描述性。Bash
现在，你就进入了一个叫
feature/dynamic-buttons 的“沙盒”环境。第二步：在新分支上自由地工作和提交
在这个分支上，你可以随心所欲地工作。
- 写了一点代码，为了安全，马上提交：
git commit -m "WIP: initial button structure"(WIP = Work in Progress)
- 修复了一个bug，提交：
git commit -m "fix: button state bug"
- 加了个
console.log用于调试，也提交：git commit -m "temp: add logging for debug"
你的
feature/dynamic-buttons分支历史可能会变得很“乱”，包含很多临时的、测试性质的提交，但完全没关系！ 因为这一切都与 master 分支无关，master 分支的历史记录依然干净整洁。第三步：功能完成后，清理并合并
当你在这个分支上的功能开发完毕、测试通过后，不要直接把它合并回
master。因为那些临时的“脏”提交也会被一并带入 master。你需要先**“清理历史”**，把这个分支上所有相关的提交合并成一个或几个有意义的、干净的提交。这时，上面提到的
git rebase -i 就派上大用场了。Bash
在打开的编辑器里，保留第一个提交为
pick，把后面几个相关的提交都改成 squash 或 s。保存退出后，Git会把这几个
squash 的提交合并到第一个 pick 的提交里，并让你重新编辑一个最终的、完整的提交信息，例如：“feat: Implement dynamic button states for prompt optimization”。第四步：合并回主分支
现在你的功能分支
feature/dynamic-buttons 上只有一个干净的提交了。这时就可以放心地把它合并回 master。Bash
这样，
master 分支就只增加了一个清晰、完整的“功能”提交，而所有中间的实验过程都留在了功能分支里（或者说被清理掉了），主干历史非常优雅。