1.6 项目管理与协作

本节目标

读完本节后，你能建立团队共用的项目目录，区分 Git、远程仓库、OSF 注册与机构存储的职责，并用版本、权限、决策记录和交付清单让研究过程可以追踪与复核。

1.6.1 管理的是状态与责任，不只是文件

科研项目最常见的混乱不是少了一个软件，而是同一文件有多个“最终版”、原始数据被覆盖、分析步骤只存在于某个人的电脑里，或者一项决定没有负责人和截止时间。

开始时先为四件事指定唯一入口：文件放哪里、任务在哪里跟踪、决定在哪里记录、谁有权限。聊天工具适合提醒，不适合充当永久档案；文件名里的 final_final2 也不是版本控制。

任何关键产物都应能回答：它从哪里来、由谁改过、为什么改、怎样重新生成。

1.6.2 建立一套可迁移的目录

下面是通用起点，不必机械照搬；关键是团队只有一套约定，并写进 README.md。

text

project-name/
├─ README.md              # 研究问题、负责人、状态和复现入口
├─ docs/                  # 方案、伦理、预注册、会议与决策记录
├─ materials/             # 问卷、刺激、实验程序和材料清单
├─ data/
│  ├─ raw/                # 原始导出，只读保存
│  ├─ interim/            # 去标识、清洗中的受控数据
│  └─ derived/            # 可由脚本重新生成的分析数据
├─ analysis/              # 清洗、分析和检查脚本
├─ outputs/               # 由脚本生成的表、图和日志
├─ manuscript/            # 稿件、补充材料和投稿文件
└─ environment/           # 依赖、软件版本和运行说明

遵守三条规则：

原始数据不可覆盖：导入后保存只读副本；修正值写进清洗脚本或更正日志。
派生结果可重建：图、表和分析数据尽量由代码从明确输入生成，不靠手工复制。
路径可迁移：使用项目内相对路径，不把个人用户名、桌面路径或盘符写死在脚本里。

每份表格配数据字典，说明变量名、类型、单位、取值、缺失编码、观测单位和去标识处理。参与者、波次、试次、材料和二元关系使用稳定且不含身份信息的 ID；不要靠姓名或行号连接文件。

1.6.3 各工具各管一层

工具	适合管理	不应误当作
本地项目目录	当前工作副本与可运行结构	唯一备份
Git	文本、代码、配置与变更历史	敏感数据保险箱或大文件同步盘
GitHub / GitLab 等远程仓库	代码协作、审阅、议题与异地副本	默认公开的参与者数据仓库
OSF Registrations / 既有 Projects	预注册、不可编辑的时间戳记录，以及既有项目的过渡与只读归档	面向 2027 年仍可持续编辑的长期协作空间，或 Git 的逐行合并替代品
机构批准的存储	受控原始数据、访问权限与备份	面向公众的开放材料页面

OSF 官方已宣布逐步停用 Projects 工作流：2026-11-16 起不能新建 Project 或 Component，2027-02-19 起现有 Projects 全部转为只读；Registrations、Preregistrations 和 Preprints 不受这次调整影响。仍在用 OSF Project 协作的团队，应按官方过渡说明决定保留静态公开内容还是迁出活跃材料，并在只读前确认权限、外部存储连接和 DOI / URL。OSF Registration 是提交后不可编辑的冻结记录，不是日常文件工作区。

OSF、Git 远程仓库和云盘都不等于完整备份。至少保留相互独立的副本，并定期做恢复测试；没有试过恢复的备份，只是一个愿望。

本页工具入口与 OSF 过渡时间表核查于 2026-08-20。平台权限、免费额度和功能会变化，团队应在数据管理计划中记录使用的服务、账户所有者、存储位置与退出方案。

1.6.4 用 Git 保存可解释的变化

Git 最适合纯文本文件。入门协作流程可以保持简单：

开始任务前同步远程仓库，确认自己在正确分支；
一次提交只完成一个可描述的改动，例如“补充排除规则”，而不是“update”；
提交前查看差异，排除临时文件、密钥、原始数据和无关输出；
推送后通过 pull request / merge request 让另一人检查关键代码和材料；
合并前运行数据检查、分析或构建命令，并把结果写进审阅记录；
在预注册、收数开始、冻结分析和投稿时记录提交 ID；需要长期引用时，再创建有版本号的归档并保留 DOI。普通 Git 标签可以移动或删除，不能单独充当不可变记录。

.gitignore 能减少误提交，但不是访问控制。API 密钥、密码、令牌和可识别数据一旦进入历史，即使从当前文件删除，旧提交里仍可能存在。若泄露的是凭据，先立即撤销或轮换，再按机构流程报告并评估是否重写历史；重写历史需要协调所有协作者，也不能清除已经存在的克隆、分叉或其他副本。

大型二进制材料频繁改动会让仓库迅速膨胀。先决定它们属于机构存储、研究数据仓储、对象存储还是 Git LFS；Git LFS 在 Git 中保存文本指针、把文件内容放在远程存储，因此还要记录配额、权限、备份和退出方案。仓库中应保留材料清单、校验值和获取说明。

1.6.5 把协作变成可见工作流

一个任务条目至少写清：负责人、交付物、截止时间、依赖、验收标准和当前状态。会议结束后把决定写入短日志，而不是只发聊天摘要：

text

日期：2026-08-19
决定：正式分析使用 Welch t 检验，不以方差检验结果切换方法。
依据：设计为两独立组；预先选择对异方差更合适的估计方案。
影响：更新预注册、分析脚本和结果模板。
负责人 / 截止：姓名 / 日期

讨论与决定要分开。Issue 可以保留方案比较，决策日志保存最终选择与理由；二者都应链接到受影响的材料或提交。

权限和责任

按最小权限授权：只给完成任务所需的读取、编辑或管理权限。
使用个人账户和多因素认证，不共享一个团队密码；成员离组时及时回收权限。
指定至少两名能恢复关键服务的负责人，避免项目绑在即将毕业者的个人账户上。
在项目早期讨论贡献和署名，持续记录贡献；CRediT 的 14 类角色用于描述贡献，不能决定谁满足作者资格，也不能自动决定作者顺序。
对数据清洗、主要模型和排除清单实行第二人复核，并记录问题如何处理。

涉及参与者数据时，先服从伦理审批、知情同意、数据使用协议和机构政策。开放代码不等于必须开放原始数据；可以共享变量字典、模拟数据、元数据、分析脚本和访问申请流程。

1.6.6 做到另一台电脑可以复核

交付前请一位没有参与日常分析的人，从一个干净目录按 README 操作。最小交付包应包含：

研究问题、样本与观测结构、主要结果和当前状态；
原始数据来源及其访问条件，或可公开的模拟 / 去标识样例；
从原始输入到分析数据、图表和模型的运行顺序；
软件、包、操作系统和关键依赖版本；
随机种子及适用步骤，非确定过程的重复策略；
预注册、伦理批准、偏离记录、材料版本和数据字典；
已知失败、人工步骤、运行时间与预期输出位置；
输入文件校验值、代码提交 ID 与归档版本 / DOI，用于确认复核的是同一份材料。

“代码公开”不等于“结果可复现”

缺少输入、依赖、执行顺序和预期输出时，代码库仍可能无法运行。反过来，可运行也不代表分析选择正确；复核者还需检查研究问题、变量定义、观测结构、假设、效应量、不确定性和诊断。

1.6.7 每个里程碑的检查单

收数前：材料、程序、预注册、伦理版本和权限已冻结并可追踪。
收数中：只做预先定义的数据质量监测；任何程序或字段变化都有时间与影响记录。
分析前：原始数据只读，数据字典完整，排除和派生变量可由脚本生成。
投稿前：正文数字与当前输出一致，图表可重建，贡献、利益冲突和数据可用性声明已确认。
归档前：公开版与受限版分开，链接和 DOI 可用，账户与权限已移交，恢复测试通过。

资源与工具

1.6 项目管理与协作 ​

1.6.1 管理的是状态与责任，不只是文件 ​

1.6.2 建立一套可迁移的目录 ​

1.6.3 各工具各管一层 ​

1.6.4 用 Git 保存可解释的变化 ​

1.6.5 把协作变成可见工作流 ​

权限和责任 ​

1.6.6 做到另一台电脑可以复核 ​

1.6.7 每个里程碑的检查单 ​

资源与工具 ​

延伸阅读 ​