2021年，一个在蚂蚁做基础设施的工程师在GitHub上开源了一个他用业余时间写的量化交易框架。项目发布的那天他写了很长的README，其中有一段话我记得很清楚：“这个框架最开始只是我自己用来跑策略回测的小工具。过去三年里，我在这个框架上迭代了上百个版本，大部分版本的Sharpe Ratio最后都归于平庸，少部分版本在生产环境里跑过一段时间后也被我回滚了。如果没有Git，我根本记不住自己在哪个版本上赚了钱、在哪个版本上亏了钱、以及为什么把那个赚钱的版本改成了后来亏钱的版本。是Git的commit log，而不是我的记忆，保存了我这三年所有的认知迭代。”
他的这段话说出了投资中最容易被忽视的一个事实：你的投资策略是一个软件项目。它有需求变更、有功能迭代、有Bug修复、有性能优化，也必然有发布失败和紧急回滚。但绝大多数散户对待自己的投资策略的方式，和那些不写注释、不做版本管理、直接在服务器上改代码的“裸奔开发”完全一样——他们每一次拍脑袋做出的策略调整，都是一次没有commit message的强制推送，覆盖掉之前可能运行良好的逻辑，而且一旦发现新版本有问题，根本不知道怎么恢复到上一个能用的版本。
Commit规范：每一笔交易都应该有它的Hash值
Git的commit message有一个约定俗成的格式，你一定见过：第一行是简短的摘要，说明这次提交做了什么；空一行之后是详细的变更说明，解释为什么要做这个变更、变更的影响范围是什么、以及任何和这个变更相关的上下文信息。一个写得好的commit message，能让三个月后的你自己或者你的同事在翻阅提交历史时，不用重新看一遍代码就能明白当时发生了什么。
你的投资日志应该遵循完全相同的规范。
每次买入操作，就是一次commit。commit message的摘要可以简单到一行：“建仓XX公司，仓位5%，类型：长线，触发条件：季度财报营收超预期且估值处于历史低位。”摘要下面追加的详细说明里，写下你买入的具体依据——是哪一份财报的哪个数字让你做出了这个判断，你对它的未来预期是什么，你为它预设的止损条件和持有期限是什么。
每次卖出操作，也是一次commit。摘要写：“清仓XX公司，原因为触及15%止损线”或者“减仓XX公司，原因为季度再平衡，仓位从12%恢复至目标8%”。详细说明里写下这次卖出的复盘：你买入时的逻辑有没有被验证？如果亏损了，亏损的原因是逻辑错误还是随机性惩罚？如果是逻辑错误，你从这笔交易里学到了什么需要写入下一条断言规则的东西？
这些commit串起来，就是你投资生涯里最诚实的一部编年史。它不会骗你，因为每一个commit都是在交易发生的当天写下来的，它保留了你当时所有真实的判断和情绪，不会被后来的结果污染。
除了常规的commit，你还需要Tag。Git里的Tag是用来标记重要里程碑的——比如发布了一个稳定版本，或者完成了一次重大重构。你的投资Tag应该标记在那些你对自己的系统做了结构性变更的时刻。比如你第一次读完这个系列文章之后，按照第二章的架构重新设计了自己的资产配置体系，那次大改就应该打一个Tag：v2.0-微内核三层架构上线。半年后你在实盘中发现债券配置比例需要从20%调整到25%，这个调整经过完整的沙箱测试和季度评审后正式纳入体系，你可以打一个Tag：v2.1-债券比例调整至25%。再过一年你经历了一次完整的牛熊周期，从中学到了三条新的断言规则并写入了你的投资日志，打Tag：v3.0-完整牛熊迭代。
Tag的意义不是给你自己看的一个形式化的标签，而是当你未来某一天迷失在市场噪声里的时候，你可以沿着Tag列表快速回溯，看到自己是从哪里出发的，经过了哪些重要的转折点，以及当前这个版本是在哪个稳定版本的基础上一步步迭代过来的。
分支策略：Master是你的命，Dev是你的实验室
任何一个成熟的软件项目都不会直接在Master分支上开发新功能。Master分支只用来跑已经验证过的稳定版本，任何新的实验性功能都在Dev分支上进行，等充分测试、没有明显Bug之后，再合并回Master。
你的钱也应该分成Master和Dev两个分支来管理。
Master分支是你的核心仓位。它执行的是你经过季度架构评审确认的长期资产配置策略——沪深300、中证500、债券、QDII、黄金，每季度做一次再平衡，其他时间不动。Master分支上的资金占据你总资产的绝对主体，至少80%以上。它不接受任何临时的、冲动的、未经季度评审批准的变更。它不是用来让你证明自己有多聪明的，它是用来让你在市场中长期活下来的。Master分支上的策略不需要惊艳，它只需要稳定。
Dev分支是你的实验账户。就是我们在第二章第八节和第三章第六节反复提到过的那个沙箱。你在这个分支里尝试各种新想法——一个新的行业轮动策略、一套基于你自己技术背景挖掘出的科技股筛选逻辑、一个你从某篇论文里看来的波动率套利思路。Dev分支的资金上限是你总资产的5%到10%，亏完就砍掉重建，亏不完就继续跑，但永远不能因为你“觉得这次把握特别大”就突破上限。
Dev分支和Master分支之间有一个严格的合并流程。你在Dev上跑满至少四个季度之后，把它的业绩和Master做对比。如果Dev在四个季度里稳定跑赢了Master，并且你在运行这个策略期间的心理状态和操作纪律都满足自己的标准，那么你可以启动一次合并流程。合并不是简单地把Dev的策略全量替换Master，而是在一次正式的季度架构评审上，把Dev策略中经过验证的那些要素——比如某个选股因子、某个择时信号——以受控的方式集成进Master的配置里。合并之后立刻打一个Tag，记录下这次架构变更的完整决策链条。
如果Dev在四个季度里没有跑赢Master，或者虽然跑赢了但你在执行过程中发现自己频繁违反规则、情绪波动过大，那就不合并。把Dev清掉，重新在下一个季度开一个新的实验。
回滚机制：当你迷失的时候，回到上一个稳定版本
运维线上系统时最让人安心的是什么？不是你对自己的代码绝对有信心——任何有经验的工程师都不会对自己写的代码绝对有信心。最让人安心的是，你知道如果新版本出了问题，你只需要一条命令就能回滚到上一个稳定版本，服务恢复，用户无感知。这个回滚能力不是锦上添花，它是你必须在上线之前就准备好的保命绳索。
你的投资体系，也必须有回滚能力。
什么时候触发回滚？我给你一个明确的硬条件：当你在Dev分支上尝试的新策略连续三个月产生负收益，而且这个负收益不是因为市场整体下跌——你可以用Dev的收益率减去同期Master的收益率，看超额收益是否为负——那就触发回滚。
回滚操作不是去调试那个亏钱的策略。不要试图在亏损中进行策略优化。当你正处于连续亏损中的时候，你的心态已经不适合做任何技术性的判断了。你会想把止损调宽一点再试一次，你会想在参数上做微调然后重新上线，你会想“已经亏了这么多了说不定马上要反转了”。所有这些想法，都是你那台已经进入内核恐慌的大脑在给自己找继续留在赌桌上的借口。
回滚操作只有一步：把Dev分支的全部仓位清掉，把资金全部转回Master分支。Master分支上的策略是什么？是你已经被历史验证过、经历过至少一轮完整牛熊、在多个mock场景下通过单元测试的那套策略。在最坏的情况下，它可能是你刚开始做投资时用的那个最笨的策略——每个月定投沪深300，其他什么都不做。没关系。这个“最笨”的策略，只要它能让你在市场里活下去，它就是一个合格的稳定版本。
你回滚之后要做的事情不是立刻开始设计下一个新策略。回滚之后的第一件事，是给自己至少一个季度的冷静期。在这个季度里，你把Dev分支上的钱老老实实放在Master里，只做定期再平衡，不主动开任何新仓位。你利用这个季度的时间重新读一遍你的投资日志，重新审视你那三个月亏损期间写的commit记录，在心态完全恢复之后再做根因分析。
如果你发现自己每次尝试新策略都以连续亏损收场，那可能不是策略的问题，是你的Dev分支实验方法论有问题——你每次都是在市场最热的时候开新实验，在市场最冷的时候被迫关闭，你的实验时序本身就是反向的。这个发现本身，就是回滚机制给你带来的最有价值的认知。
你不需要永远在Master分支上苟着。你是一个工程师，你的天性就是探索、迭代、优化。回滚不是让你放弃探索，是让你在探索走进死胡同的时候，有一条安全的退路可以回到起点，整理好行囊再重新出发。Git从来不阻止你创建新的分支，它只是在你搞砸的时候，给你一个回到稳定版本的选择。
到这里，第四章全部结束。
从GDB模式的单步执行，到Crash Dump的内核转储，到堆栈回溯的四层调用栈，到断言机制的不可绕过性，到二分法排查的Bug定位，到单元测试的Mock注入和覆盖率，再到今天这一节的版本控制和回滚——我们用七节内容，把你从亏损后的茫然无措，武装成了一个拥有完整调试工具链的投资工程师。
你现在缺少的不是一个百战百胜的策略。你现在拥有的是更重要的东西：当你的策略失败的时候，你知道怎么复盘、怎么定位、怎么修复、以及怎么在修复不了的时候安全撤退。
下一章，我们要离开调试的世界，进入一个全新的维度。市场不是一台安静的服务器，它是一个巨大的噪声源。你每天接收到的价格波动，99%是噪声，只有1%是信号。怎么用你熟悉的信号处理理论，设计一个能把噪声滤掉、把信号留下的滤波器——这是第五章要给你的全部内容。
