/ memory-bank / git_workflow.md
git_workflow.md
1 # Git Workflow for ICP Management Project 2 3 ## Current Branch Structure 4 5 The ICP Management project uses the following branch structure: 6 7 - **master**: Contains only the README.md with project overview and roadmap 8 - **develop**: Integration branch for testing and release preparation 9 - **feature/bridge-0.9.0**: Implementation branch for the bridge pattern v0.9.0 10 11 ## Branch Roles and Responsibilities 12 13 ### master 14 - Contains only the project README.md 15 - Provides high-level project overview and roadmap 16 - Should always be in a clean state 17 - Updates to this branch should be limited to README.md changes only 18 19 ### develop 20 - Main integration branch 21 - Receives completed features from feature branches 22 - Used for integration testing 23 - Preparation for releases 24 - Should be kept in a relatively stable state 25 26 ### feature/bridge-0.9.0 27 - Active development branch for bridge pattern implementation 28 - Contains all bridge pattern related code: 29 - Interface definitions 30 - Adapter implementations 31 - Error handling system 32 - Testing framework 33 - Feature flag system 34 - CLI migration utilities 35 - Work continues here until bridge pattern v0.9.0 is complete 36 37 ## Development Workflow 38 39 1. **Bridge Pattern Development** 40 - Work on `feature/bridge-0.9.0` branch 41 - Complete remaining adapter implementations 42 - Implement comprehensive tests 43 - Set up benchmarking system 44 - Apply standardized error handling 45 - Develop feature flags 46 47 2. **Integration Process** 48 - When features are stable on `feature/bridge-0.9.0`, merge to `develop` 49 - Run integration tests on `develop` 50 - Fix any integration issues on `develop` 51 52 3. **Updating Project Overview** 53 - When significant milestones are reached, update README.md on `master` 54 - Keep README.md roadmap updated with current progress and timeline changes 55 56 ## Version Progression 57 58 As the project advances through the roadmap versions, follow this approach: 59 60 1. **For v0.9.0 to v1.0.0 Transition** 61 - Complete all v0.9.0 tasks on `feature/bridge-0.9.0` 62 - Merge `feature/bridge-0.9.0` into `develop` 63 - Create a new `feature/bridge-1.0.0` branch from `develop` 64 - Continue work toward v1.0.0 on the new feature branch 65 66 2. **For Each Subsequent Version** 67 - Create a dedicated feature branch (e.g., `feature/bridge-1.5.0`) 68 - Implement version-specific features 69 - Merge to `develop` when stable 70 - Update roadmap on `master` as needed 71 72 ## Branch Management Guidelines 73 74 1. **Feature Branches** 75 - Create feature branches from `develop` for new functionality 76 - Use naming convention: `feature/feature-name` 77 - Keep feature branches focused on specific functionality 78 79 2. **Hotfix Approach** 80 - For urgent fixes, create a `hotfix/issue-description` branch from `develop` 81 - Fix the issue and merge back to `develop` 82 83 3. **Release Process** 84 - When ready for a release, create a `release/version-number` branch from `develop` 85 - Perform final testing and version bumping on release branch 86 - Merge to `develop` and record release notes 87 88 ## Clean Branch Process 89 90 The repository periodically undergoes cleanup to maintain a clean structure: 91 92 1. **Master Cleanliness** 93 - `master` branch should only contain README.md 94 - Use `scripts/clean_master_branch.sh` to clean if needed 95 96 2. **Feature Branch Cleanup** 97 - After successfully merging a feature branch to `develop`, consider archiving old feature branches 98 - Use tag system to mark significant branch points before deletion 99 100 This workflow provides flexibility while maintaining clarity about where different types of work should happen at each stage of the project.