/ 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.