离职代码纠纷里，Git 记录最像证据，也最容易先倒

员工离职时带走代码，几乎每家公司都会做同一件事：导出代码仓库，把提交记录整理成册，摆在会议室桌上，然后觉得手里已经有了最有力的证据。等真正走进诉讼，才发现这些记录能回答的问题十分有限——它只说明某个账号在某时某刻往仓库里写入了内容，但回答不了真正定性的问题：这个操作是不是账号本人做的？这项开发任务是不是公司指派的？员工离职后写出的新版本，和公司代码是不是同一个东西？这篇文章要拆的，正是这些证据在法庭上最容易被攻破的几个口子。

账号是他的，键盘不一定是他

第一处容易失守的地方，发生在提交记录的身份认定。不少公司的代码仓库并不严格保证一个账号对应一个人。实习生来了用组长账号，外包团队成员共用一个服务账号，员工离职交接期间把账号暂时交给接替者——这些日常管理里很常见的事，到了诉讼里，每一处都可能被对方拿来回击一句：“那不是我的操作。”

比身份更难缠的是时间。Git 的提交者姓名、邮箱和日期，在技术上只是本地配置的一部分，提交历史也可以被人为改写或重新推送。公司导出仓库后看到的那条干净时间线，未必是原始时间线。这并非暗示员工一定会动手脚，而是提醒你：对方的律师只需要提出“账号可能共用”或“提交时间不是唯一”的合理质疑，整份导出的说服力就会大打折扣。

要补上这个缺口，靠的不是去员工个人电脑上翻文件，而是提前把服务端的审计日志留好。使用公司统一代码托管平台时，每一次推送都会在服务端记录来源 IP、密钥指纹，以及对应的统一身份认证登录状态。这些日志有留存时限，离职后拖上两个月再取，可能已经没了。所以真正要紧的动作只有一个：员工提出离职的那一刻，先冻结账号，再备份仓库，同时把近几个月的登录日志、构建记录、合并请求操作记录一并导出。整个过程必须发生在任何正式谈话之前。很多公司习惯先找员工谈，谈不拢了才回来取证，那时候能保存的痕迹已经少了一半。

仓库里只有“写了”，仓库外才有“为谁写”

操作者身份对上之后，第二道关卡登场。法律判断职务软件，真正看的是开发和职务之间的关系，而不只是代码恰好放在公司的服务器里。员工可以退一步承认“代码是我写的”，再补一句“这是我的个人项目，顺手推到了公司仓库”，之前准备的提交记录就很难接上话。

反过来看，能把这层关系钉牢的证据，多半不在版本库里。任务管理系统中分配过什么开发任务、需求评审时谁被列为负责人、测试报告的缺陷单上有没有他的名字、发布版本里是否包含该模块、客户交付材料里有没有对应功能描述——这些内容与 Git 提交记录拼在一起，才能构成一条完整的“任务—开发—上线”链。链条的两端尤其有力：任务分配证明开发动机来自公司，交付记录证明开发成果归属于公司。

做这件事时建议一次到位。把争议模块的提交信息中的任务编号提取出来，找到对应的任务卡片，将任务标题、负责人、状态变动时间、验收人截取存档；再调出代码合入主干的时间，对应发布记录中的版本号；最后找出该版本对外交付的证据。四个点对齐之后，“个人项目”的说法几乎没有落脚的缝隙——个人项目不会挂着公司的任务编号，也不会出现在公司的客户交付清单里。

这个环节还有一个容易被低估的反向操作：清理旧数据的习惯。不少团队为了系统整洁，定期关闭归档旧任务，离职纠纷发生时，最关键的分配记录恰恰已经没了。正确的归档策略是保留任务卡片的所有字段和状态流，只把它移出当前迭代，绝不删除删除。这样的历史平时看着无用，纠纷里就是决定性证据。

常被忽略的还有代码评审记录。如果该员工的代码合入前经历过同事的 review，留下过修改意见或打回记录，那就意味着他的工作从起点就不在“个人创作”的轨道上。评审中暴露出的协作痕迹，比单方面声称“我在做自己的项目”更能说明问题。

员工改口说后来重写了，拿什么破

前两关都守住后，更隐蔽的反击出现在另一个时间点：员工不再否认代码曾在公司仓库，而是称离职后写的新版本是自己从零设计的。这时候再争论权属意义不大了，必须正面回答“两套代码是不是同一个东西”。

很多公司在这里踩入陷阱，一心去鉴定整体代码相似度，相似度百分比一低，反被对方当成“独立开发”的佐证。正确的取证方向，不是找“像不像”，而是找“复制才会留下、重写不会出现”的痕迹。

哪些痕迹算数？两套代码在同样输入下犯同样的错误，出现同样的异常信息或边界条件处理失误；两套代码里出现同样的特殊命名，尤其是不普通的变量名、带怪癖拼写的函数名；两套代码的注释中出现同样的措辞习惯，包括错别字；两套代码在某一处同时选择了一种罕见且非必要的实现写法。功能可能源于需求，设计也许会被模仿，但错误和怪癖几乎必然指向同一来源。

操作上可以分两步走。先用代码克隆检测工具将两套代码按文件结构做一遍自动对应，把相似片段挑出来，但不要依赖工具给出的百分比。随后由技术人员人工核对核心算法，逐段比对上述特征。申请司法鉴定时，委托事项不要写“两套代码是否构成相同”，而要写明“两者是否出现相同的错误特征与非必要表达”。前者给结论留了太宽的余地，后者才是复制行为留下的硬痕迹。

这里的时机同样苛刻。员工的新版本一旦发布，代码会迅速被后续迭代覆盖，第三方构建平台上的早期版本也可能被清理。公司能做的，是在发现争议的第一时间把两套代码分别镜像保存，再启动比对。晚上一个月，数据库里就少一份中间版本。

说到底，离职代码纠纷的最后走向，不取决于谁打印的文档多，而取决于能否回答三个问题：这些代码究竟是谁推进的？为什么推进？离职后出现的代码是不是同一套？日复一日在代码仓库里留下这些答案的企业，不用等到纠纷发生才手忙脚乱。真正管用的防御，不是一份厚重的知识产权合同，而是每一次提交、每一次评审、每一次发布时顺便留下的那一条痕迹。