Version Control and Deployment Workflow Across Development, Staging, and Production Environments.

1. Environment Overview

• Development (Dev):
  
  Used by developers for active feature development and debugging. Frequent commits and experimental branches are common here.

• Staging (Stg/UAT):
  
  A replica of the production environment used for testing, QA, and user acceptance. Only stable and reviewed code from development should be deployed here.

• Production (Prod):
  
  The live environment accessed by end users. Only thoroughly tested and approved code should reach this stage.

2. Git Branching Strategy

A common and effective branching model is Git Flow (or a simplified version of it):

3. Tagging for Releases

Use Git tags to mark stable points in history for deployment:

• Development tags: dev-v1.0.0

• Staging tags: stg-v1.0.0

• Production tags: v1.0.0

Tags make rollbacks and deployment tracking easier.

4. Deployment Workflow

Step-by-step pipeline:

1. Development Phase

   • Developers create or update feature branches.

   • After completion, feature branches are merged into develop.

   • Automated tests run (CI pipeline).

2. Staging Phase

   • When develop is stable, merge it into staging or create a release/* branch.

   • Apply a staging tag (stg-vX.X.X).

   • Deploy to staging environment for QA and UAT.

   • Fix bugs on the same branch and retag if needed.

3. Production Phase

   • Once approved, merge the release or staging branch into main.

   • Tag production release (vX.X.X).

   • Deploy to production environment using CI/CD.

4. Hotfix Handling

   • Create hotfix/* from main for urgent issues.

   • Merge back to both main and develop after deployment.

5. CI/CD Integration

Tools like GitHub Actions, GitLab CI, CircleCI, or Jenkins can automate:

• Build and test pipelines

• Environment-specific deployments

• Version tagging and release notes

Example:

# Example: GitHub Actions (simplified)
on:
  push:
    tags:
      - 'v*'  # Deploy only on version tags
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Production
        if: startsWith(github.ref, 'refs/tags/v')
        run: ./scripts/deploy-prod.sh

Difference Between GitHub Tags and Branches

In Simple Terms

• Branches = active workspaces.
  
  You build and update features or fixes here.

• Tags = version markers.
  
  You freeze and label code at a specific state — often for release, rollback, or audit purposes.

Example: Combined Use

# Developer workflow
git checkout -b feature/login
# ...work, commit, merge to develop...

# Merge develop → main after testing
git checkout main
git merge develop

# Create a production release tag
git tag -a v1.0.0 -m "Production release 1.0.0"
git push origin v1.0.0

This marks the exact commit that was deployed to production — making version tracking and rollback easy.

When to Use Branches vs Tags

1. Use Branches When…

Branches are for active, changeable work — anything that’s still being developed, tested, or reviewed.

✅ Typical Scenarios

💡 Tip:

Branches are living lines of development — they evolve and are meant to be merged or deleted after use.

2. Use Tags When…

Tags are for marking stable, completed states of your repository — snapshots that should never change.

✅ Typical Scenarios

💡 Tip:

Tags are immutable labels — perfect for releases, audits, and deployments.

3. Real-World Example: Development → Staging → Production

4. In Summary