DEV Community

Satish
Satish

Posted on

Common Git Branching Strategies

#beginners #git #softwaredevelopment #tutorial

1. Simple Projects / Personal Repos

  • Just use main(or master) as your default branch.
  • Push code directly there.
  • Ideal for solo projects, experiments, or small utilities where you don’t need complex environments.

2. Team Projects / Professional Setup

Use multiple branches to separate environments:

  • main(or master): always stable, production-ready code.
  • develop(or qa): integration branch where features are merged and tested.
  • staging: optional, mirrors production but used for pre-release testing.
  • feature/*: short-lived branches for individual features or bug fixes.
  • hotfix/*: for urgent fixes applied directly to production.

Note: This way, you can test in QA, validate in staging, and only merge into main when the code is truly production-ready.

3. GitFlow Model (Popular in Enterprises)

  • main → production releases.
  • develop→ ongoing development.
  • feature/*, release/*, hotfix/* → specialized branches for workflow control.

🔄 Workflow Steps
1. Clone and Setup

git clone <repo-url>
cd <repo-name>
git checkout -b develop
Enter fullscreen mode Exit fullscreen mode

2. Create Feature Branch

git checkout develop
git checkout -b feature/login-auth
Enter fullscreen mode Exit fullscreen mode

3. Work and Commit

git add .
git commit -m "Add login authentication"
Enter fullscreen mode Exit fullscreen mode

4. Push Feature Branch

git push origin feature/login-auth
Enter fullscreen mode Exit fullscreen mode

5. Merge to Develop (QA)

git checkout develop
git merge feature/login-auth
git push origin develop
Enter fullscreen mode Exit fullscreen mode

6. Promote to Staging

git checkout staging
git merge develop
git push origin staging
Enter fullscreen mode Exit fullscreen mode

7. Release to Production

git checkout main
git merge staging
git push origin main
Enter fullscreen mode Exit fullscreen mode

📌 Notes

  • Always keep main clean and stable.
  • Use Pull Requests (PRs) for merging — this ensures code review.
  • Delete feature branches after merging to keep repo tidy.
  • Hotfixes go directly into main and then back-merge into develop

⚙️ GitHub Actions CI/CD Pipeline
Yaml

name: CI/CD Pipeline

on:
  push:
    branches:
      - develop
      - staging
      - main

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

  deploy:
    needs: build-test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Deploy to QA (Develop branch)
        if: github.ref == 'refs/heads/develop'
        run: echo "Deploying to QA environment..."
        # Replace with actual deploy script, e.g.:
        # run: ./scripts/deploy-qa.sh

      - name: Deploy to Staging
        if: github.ref == 'refs/heads/staging'
        run: echo "Deploying to Staging environment..."
        # run: ./scripts/deploy-staging.sh

      - name: Deploy to Production
        if: github.ref == 'refs/heads/main'
        run: echo "Deploying to Production..."
        # run: ./scripts/deploy-prod.sh
Enter fullscreen mode Exit fullscreen mode

🔑 How It Works

  • Push to develop→ runs tests, then deploys to QA.
  • Push to staging→ runs tests, then deploys to Staging.
  • Push to main→ runs tests, then deploys to Production.
  • Each environment can have its own deployment script (deploy-qa.sh, deploy-staging.sh, deploy-prod.sh).

🛠️ Next Steps

  • Create deployment scripts for each environment (can be SSH, Docker, Kubernetes, or cloud CLI).
  • Add environment secrets in GitHub (Settings → Secrets and variables → Actions).
  • Example: QA_SERVER, STAGING_SERVER, PROD_SERVER.
  • Replace the echolines with real deployment commands.

Top comments (0)