Git 最值得留下的能力在于让一次改动可以被解释、比较和恢复。工作流如果只关注“最后能不能合并”，很快就会失去中间的判断。
小提交应该围绕一个可以说清楚的变化。修复一个错误、补一条测试、更新一份文档，通常比把三件事混在一起更容易审查。提交信息写动词和范围，未来回看日志时不用打开全部文件猜意图。
分支解决的是并行变化，不是为了让仓库看起来更专业。短期分支应该尽量靠近主线，完成以后及时合并或删除；长期分支如果没有明确的发布策略，只会让冲突和依赖一起积累。分支名称可以说明主题，不能替代提交内容。
合并前的审查要看行为而不是只看格式。新增接口有没有错误路径，数据库变更能不能重复执行，配置是否带入了密钥，旧版本是否还能启动。自动化测试能挡住一部分问题，不能替人理解产品边界。审查意见也应该落在代码和证据上，而不是模糊地说“感觉不太好”。
回滚有两种常见方式：撤销一个逻辑变化，或者把部署指针退回到上一份已验证的构建。前者会产生新的提交，后者需要保留旧产物和数据兼容方案。git revert 通常比改写共享历史更适合团队协作；强制推送以前，先确认所有依赖这个分支的人都知道。
标签和发布说明让代码跨过仓库边界。一个版本应该能对应到源码、构建产物和配置变更，出现问题时才有可能复现。不要把“已经推到 main”写成“已经上线”，发布系统和线上读回仍然需要单独验收。
Git 工作流最终服务的是人的记忆。让改动变小、证据变多、回退路径存在，几个月以后重新打开项目时，仍能知道当时为什么这么做。
当仓库和部署系统相连以后，提交记录还要和发布记录对应起来。一次回滚应该能回答“退回了哪份代码、数据是否兼容、谁确认恢复”。Git 保存历史，运维记录保存影响，两者合在一起才是一条完整的时间线。
提交信息只是入口，可回看还需要测试、审查和发布记录配合。一个提交解决什么问题、改变了哪些边界、怎样验证，都应该能在仓库里找到；否则日志再整齐，也无法替代当时的判断。
我也会给回滚留出时间。先确认旧构建仍能启动、数据迁移可兼容，再决定是 revert 代码还是退回部署指针。回滚是在失败时把影响限制在可以解释的范围内，不代表承认失败。
我现在会把一次发布拆成一张很短的清单：提交是否可读，测试是否跑过，迁移是否可重复，构建产物对应哪个提交，回滚版本是否仍在。清单不负责替代审查，却能挡住“代码已经合并，部署材料还没准备”的断层。
对个人仓库来说，审查也可以很轻量。让改动保持一个主题，读一遍错误路径，再在干净目录跑一次最小命令，往往比堆更多自动化更有帮助。Git 保存历史，人的判断仍然要留在提交之间。