- Move all docs to docs/ directory for clean repo structure - Create LLM-optimized versions (*-LLM.MD) for AI tool consumption - Update cross-references and links for new paths - Maintain both human-readable and machine-optimized versions - Complete documentation system with worklog tracking
5.9 KiB
5.9 KiB
Git Workflow
This document outlines the git workflow for this repository, designed for use with Gitea.
Branch Structure
Main Branches
main
- The primary stable branch. Direct work should NOT be done on this branch.RELEASE
- Production-ready code. Only accepts pull requests that have been manually reviewed and approved.INTEGRATION-WIP
- Integration branch where all feature branches are automatically merged for testing and integration.
Feature Branches
LLMBOOTSTRAP
- Initial bootstrap feature branch for LLM-assisted development setup.- Additional feature branches should follow naming conventions like
feature/description
ortask/description
.
Workflow Rules
-
Never work directly on
main
- All work must be done on feature branches. -
Feature Development Flow:
- Create feature branches from
main
- Develop features in isolation on these branches
- Feature branches automatically merge to
INTEGRATION-WIP
for continuous integration testing
- Create feature branches from
-
Integration Testing:
INTEGRATION-WIP
branch serves as the integration environment- All feature branches are automatically merged here
- Used for testing compatibility between different features
-
Release Process:
- Only manually reviewed pull requests are merged to
RELEASE
RELEASE
branch represents production-ready code- Requires explicit approval before merging
- Only manually reviewed pull requests are merged to
Branch Protection
main
- Protected, no direct commits allowedRELEASE
- Protected, only manual PR merges allowedINTEGRATION-WIP
- Accepts automatic merges from feature branches
Feature Branch Management
CRITICAL: Branch Preservation
- NEVER automatically delete feature branches under any circumstances
- Feature branches must be preserved for historical reference and potential future work
- Branch deletion should only occur through explicit manual action after careful consideration
Commit and Push Frequency
- Commit frequently - Make small, logical commits as you work
- Push every 10 commits maximum - Don't let local commits accumulate
- ALWAYS push before switching branches - Ensure work is backed up remotely
- Push immediately before any branch operations (merge, rebase, etc.)
Tagging for Milestones
- Create tags when interim stages or milestones are completed
- Push tags immediately after creation to preserve milestone markers
- Tag naming conventions:
- Date-based:
milestone-YYYY-MM-DD
orstage-YYYY-MM-DD-HHMM
- Stage-based:
bootstrap-complete
,auth-module-done
,integration-ready
- Plan-based: Use milestone names from planning documents
- Date-based:
- Always annotate tags with meaningful descriptions of what was accomplished
Best Practices
- Keep feature branches focused and small
- Use descriptive branch names
- Regularly sync feature branches with
main
- Test thoroughly in
INTEGRATION-WIP
before requesting merge toRELEASE
- Write clear commit messages and PR descriptions
- Follow the commit/push frequency rules above
Examples: DO and DON'T
✅ DO Examples
# DO: Create feature branch from main
git checkout main
git pull origin main
git checkout -b feature/user-authentication
# DO: Commit frequently with descriptive messages
git add .
git commit -m "Add user login form validation"
git commit -m "Implement password hashing utility"
git commit -m "Add user session management"
# DO: Push after every 10 commits or before switching branches
git push origin feature/user-authentication
# DO: Push before switching to another branch
git push origin feature/user-authentication
git checkout feature/payment-system
# DO: Sync feature branch with main regularly
git checkout main
git pull origin main
git checkout feature/user-authentication
git merge main
# DO: Tag milestones with descriptive annotations
git tag -a bootstrap-complete -m "Initial project structure and workflow setup completed"
git push origin bootstrap-complete
# DO: Use date-based tags for interim stages
git tag -a stage-2025-09-05-1430 -m "Authentication module implementation complete"
git push origin stage-2025-09-05-1430
❌ DON'T Examples
# DON'T: Work directly on main
git checkout main
git add .
git commit -m "Fix user auth bug" # ❌ NEVER DO THIS
# DON'T: Delete feature branches automatically
git branch -d feature/user-authentication # ❌ NEVER DO THIS
git push origin --delete feature/user-authentication # ❌ NEVER DO THIS
# DON'T: Let commits accumulate without pushing
git log --oneline # Shows 15+ unpushed commits # ❌ Should have pushed earlier
# DON'T: Switch branches without pushing current work
git checkout feature/payment-system # ❌ Without pushing current branch first
# DON'T: Make massive commits
git add .
git commit -m "Complete entire user system" # ❌ Too broad, break it down
# DON'T: Create tags without annotations
git tag milestone-1 # ❌ No description of what was accomplished
git push origin milestone-1
# DON'T: Forget to push tags
git tag -a bootstrap-complete -m "Setup complete"
# ❌ Missing: git push origin bootstrap-complete
🔧 Workflow Examples
Starting new feature:
git checkout main
git pull origin main
git checkout -b feature/shopping-cart
# Work, commit frequently, push every ~10 commits
Switching between features:
# Currently on feature/shopping-cart
git add .
git commit -m "Add item quantity validation"
git push origin feature/shopping-cart # ✅ Push before switching
git checkout feature/user-profile
Preparing for integration:
git checkout feature/shopping-cart
git push origin feature/shopping-cart
# Feature automatically merges to INTEGRATION-WIP
Gitea Integration
This workflow is optimized for Gitea and utilizes:
- Branch protection rules
- Automatic merge capabilities for integration testing
- Manual review processes for production releases