# 🏗️ WWJCloud 仓库管理策略 ## 📋 概述 本文档定义了 WWJCloud 项目的仓库管理策略,确保开发-发布分离,避免代码污染,保证用户获得稳定版本。 ## 🎯 核心原则 ### 1. 三层隔离架构 - **v0.1.1-branch**: 纯净底板,永不变更,AI开发安全回退点 - **主仓库**: 开发环境,高频推送,实时同步开发进度 - **子仓库**: 发布环境,低频推送,面向最终用户 ### 2. 严格的推送规则 - ❌ **禁止**: 主仓库直接推送到 wwjcloud.git - ❌ **禁止**: 从 v0.1.1-branch 推送任何更改 - ✅ **允许**: 子仓库推送稳定版本到 wwjcloud.git - ✅ **允许**: 主仓库推送开发进度到 wwjcloud-nsetjs.git ## 🏛️ 仓库架构 ``` wwjcloud-nsetjs (主仓库) ├── origin → https://gitee.com/wanwujie/wwjcloud-nsetjs.git └── wwjcloud-nest/ (子仓库) ├── origin → https://gitee.com/wanwujie/wwjcloud.git ├── master (开发分支) ├── v0.1.1-branch (纯净底板) └── v0.1.1-stable (保护标签) ``` ## 🔄 工作流程 ### 日常开发流程 ```bash # 1. 在主仓库进行开发 cd /path/to/wwjcloud-nsetjs # ... 进行开发工作 ... # 2. 推送开发进度(高频) ./push_dev.sh ``` ### 版本发布流程 ```bash # 1. 确保开发完成并测试通过 cd wwjcloud-nest # 2. 推送稳定版本给用户(低频) ../push_wwjcloud_nest.sh ``` ### 紧急重置流程 ```bash # 当AI开发出现错误污染时 cd wwjcloud-nest git checkout v0.1.1-branch git checkout -b fix-$(date +%Y%m%d) # 基于纯净版本重新开发 ``` ## 🛡️ 安全机制 ### 1. 自动检查 - ✅ 目录检查:确保在正确的仓库目录 - ✅ 远程检查:验证远程仓库配置正确性 - ✅ 分支检查:防止从保护分支推送 - ✅ 污染检查:自动移除危险的远程配置 ### 2. 保护措施 - 🔒 v0.1.1-branch 设为只读 - 🏷️ v0.1.1-stable 标签保护 - 🚫 主仓库禁止 wwjcloud 远程 - ⚠️ 推送前确认机制 ## 📜 脚本说明 ### push_dev.sh (开发推送) - **用途**: 日常开发推送到主仓库 - **频率**: 高频(随时) - **目标**: wwjcloud-nsetjs.git - **检查**: 自动移除危险远程配置 ### push_wwjcloud_nest.sh (发布推送) - **用途**: 稳定版本推送给用户 - **频率**: 低频(版本稳定时) - **目标**: wwjcloud.git - **检查**: 严格的安全验证 ## 🚨 常见问题 ### Q: 为什么主仓库不能有 wwjcloud 远程? **A**: 防止意外推送开发代码到用户仓库,造成代码污染。 ### Q: 如何确保 v0.1.1-branch 不被修改? **A**: 1. 创建了 v0.1.1-stable 保护标签 2. 脚本自动检查并阻止从该分支推送 3. 作为只读的安全回退点 ### Q: 如果推送脚本检测到问题怎么办? **A**: 脚本会: 1. 显示具体错误信息 2. 提供解决建议 3. 自动修复(如移除危险远程) 4. 阻止危险操作 ## 🎯 最佳实践 ### 开发阶段 1. 在主仓库进行所有开发工作 2. 使用 `./push_dev.sh` 频繁同步进度 3. 定期测试确保代码质量 ### 发布阶段 1. 确保所有功能完整且测试通过 2. 切换到 wwjcloud-nest 目录 3. 使用 `../push_wwjcloud_nest.sh` 发布稳定版本 4. 确认用户可以正常使用 ### 紧急情况 1. 发现代码污染时立即停止开发 2. 使用 v0.1.1-branch 作为安全回退点 3. 基于纯净版本重新开始开发 ## 📊 监控指标 - **开发推送频率**: 每日多次 - **发布推送频率**: 每周1-2次 - **代码污染事件**: 0次(目标) - **紧急重置次数**: 最小化 --- **⚠️ 重要提醒**: 严格遵循本策略,确保代码质量和用户体验!