Bitbucket代码仓库协作方案咨询：数据集存Sharepoint时的架构设计

核心目录划分 #

• src/：存放所有分析核心代码，按功能模块拆分文件夹（如src/cleaning/负责数据清洗、src/modeling/负责模型训练），脚本命名清晰易懂
• notebooks/：存放交互式分析笔记（如Jupyter Notebook），文件名带上时间和主题（比如20240520-user-retention-analysis.ipynb），便于追溯分析过程
• utils/：封装通用工具函数，重点实现统一的Sharepoint数据加载方法（比如sharepoint_loader.py），避免团队成员重复编写路径逻辑
• config/：存放配置文件，比如data_paths.yaml里仅记录数据集在Sharepoint的相对路径或团队约定的统一挂载路径（如raw_data: "project-datasets/raw"），禁止写个人本地绝对路径；同时可在这里管理模型参数、输出路径等配置
• docs/：
  • dataset_structure.md：记录每个数据集的字段含义、更新周期、在Sharepoint的具体位置
  • setup_guide.md：详细说明如何将Sharepoint挂载到本地、如何配置项目依赖环境
• environment.yml/requirements.txt：统一项目的依赖包版本，确保所有人运行环境一致

关键忽略规则 #

在.gitignore中添加以下规则，彻底杜绝误提交数据集：

# 本地缓存/临时数据
data/
*.csv
*.xlsx
*.parquet
# 虚拟环境目录
venv/
.env
# 笔记本临时文件
.ipynb_checkpoints/
# 系统临时文件
*.tmp

分支管理策略 #

• 采用简化分支模式：main为稳定分支，仅合并经过验证的成熟代码；dev为开发整合分支，所有成员的功能分支均基于dev创建
• 个人开发新任务时，从dev拉出专属分支，命名规则统一为feature/[任务描述]（比如feature/channel-conversion-analysis）
• 开发完成后提交PR到dev，至少1位团队成员完成代码审查后再合并，确保逻辑一致、无路径硬编码问题

数据协作约定 #

• 强制使用utils/中的加载函数读取数据，禁止在脚本中硬编码Sharepoint路径，避免因个人本地挂载差异导致报错
• 若Sharepoint上的数据集更新（如新增字段、版本迭代），更新人需同步修改docs/dataset_structure.md，并在团队沟通群或Bitbucket PR讨论区告知所有人
• 代码版本与数据集版本绑定：在CHANGELOG.md中记录对应关系，比如v1.1版本代码对应Sharepoint上的dataset-v1.1文件夹，避免版本不匹配导致分析结果偏差

验证与交付流程 #

• 个人开发完成后，必须用Sharepoint的真实数据集跑通完整流程，确认数据加载正常、分析结果符合预期，PR中附上运行日志或结果截图
• 每次将dev合并到main时，由仓库维护者进行全流程测试，确保稳定分支代码可正常运行
• 分析结果（如可视化图表、报告文档）上传到Sharepoint的指定结果文件夹，不提交到Bitbucket，仅在仓库的results.md中记录结果文件的Sharepoint路径

内容的提问来源于stack exchange，提问作者user3424575