← Back to references

Git Down!.md

Download Raw

Branch Structure Workflow

Here's the recommended branching strategy for your Flask application:

Main Branch (main)

  • Purpose: Production-ready code that's currently live on comasome.com
  • Rule: Only merge tested, working features
  • Protection: Never develop directly on main

Development Branch (development)

  • Purpose: Integration branch where new features are tested together
  • Rule: All feature branches merge here first for testing
  • Protection: Should always be functional, but may have experimental features

Feature Branches (feature/branch-name)

  • Purpose: Individual features or fixes
  • Rule: Created from development, merged back to development
  • Examples: feature/new-tool, feature/markdown-reader, feature/ui-improvements

Complete Git Workflow

1. Starting a New Feature

# Make sure you're on development branch
git checkout development
git pull origin development  # If using remote repo

# Create and switch to new feature branch
git checkout -b feature/new-markdown-viewer

2. Development Work

# Make your changes to SecHome.py, templates, etc.
nvim SecHome.py

# Stage and commit changes regularly
git add .
git commit -m "Add markdown syntax highlighting support"

# Continue making commits as you work
git add templates/
git commit -m "Update templates for better mobile support"

3. Testing Your Feature

# Test your Flask app locally
python SecHome.py

# Test with gunicorn
source venv/bin/activate
gunicorn --workers 2 --bind 127.0.0.1:8090 SecHome:app

4. Merging Feature to Development

# Switch to development branch
git checkout development

# Merge your feature
git merge feature/new-markdown-viewer

# Test the integrated code
python SecHome.py

# If tests pass, you can delete the feature branch
git branch -d feature/new-markdown-viewer

5. Deploying to Production (Main)

# Only when development is stable and tested
git checkout main
git merge development

# Deploy to your production server
sudo systemctl restart gunicorn-sechome.service

Practical Workflow for Your DFIR Website

Example: Adding a New Tool Page

# Start from development
git checkout development

# Create feature branch
git checkout -b feature/volatility-cheatsheet

# Add your new tool/reference
nvim markdown_files/volatility-commands.md
nvim templates/tool_page.html

# Commit your work
git add .
git commit -m "Add Volatility memory analysis cheatsheet"

# Test locally
python SecHome.py

# Merge to development
git checkout development
git merge feature/volatility-cheatsheet

# Test integration
python SecHome.py
gunicorn --workers 2 --bind 127.0.0.1:8090 SecHome:app

# If everything works, merge to main and deploy
git checkout main
git merge development
sudo systemctl restart gunicorn-sechome.service

Advanced Git Commands for Your Workflow

Branch Management

# View all branches
git branch -a

# View branch history
git log --oneline --graph --all

# Switch branches
git checkout branch-name

# Create branch from specific commit
git checkout -b hotfix/urgent-fix abc1234

Backup and Recovery

# Create backup branch before major changes
git checkout -b backup-$(date +%Y%m%d)

# Restore from backup if something breaks
git checkout main
git reset --hard backup-20250809

Working with Remote Repository (Optional)

If you set up a remote repository (GitHub, GitLab, etc.):

# Add remote origin
git remote add origin git@github.com:yourusername/sechome.git

# Push branches to remote
git push -u origin main
git push -u origin development

# Pull latest changes
git pull origin development

Emergency Procedures

If You Break Production

# Quickly revert to last working commit
git checkout main
git log --oneline  # Find last working commit
git reset --hard abc1234

# Restart service with working code
sudo systemctl restart gunicorn-sechome.service

If Development Gets Messy

# Create clean development from main
git checkout main
git checkout -b development-clean
git branch -D development  # Delete messy branch
git checkout -b development  # Recreate clean development

Best Practices for Your DFIR Setup

  1. Commit frequently with descriptive messages
  2. Test in development before merging to main
  3. Backup before major changes using backup branches
  4. Keep main branch deployable at all times
  5. Use descriptive branch names like feature/malware-analysis-tools
  6. Document changes in commit messages for forensic purposes (fits your DFIR background!)