Skip to content

Git workflow and GitHub Setup

Jump to bottom
Laxman Singh Rawat edited this page Feb 26, 2026 · 1 revision

Git & Repository Guidelines

1. Git Workflow Strategy

We follow a simplified Gitflow with main and develop as long-running branches.

Branch Roles

Branch Purpose
main Production-ready code only. Updated via releases.
develop Integration branch where all features come together. Day-to-day working branch.

The Rules

  • Create feature branches off develop, e.g. feature/swipe-ui or fix/auth-bug
  • When done, open a Pull Request (PR) into develop
  • At least one teammate reviews and approves before merging
  • When the team agrees a set of features is ready for release, develop is merged into main via a PR
  • Delete feature branches after merging

Reducing Merge Conflicts

  • Pull from develop frequently into your working branch: git pull origin develop
  • Keep feature branches short-lived — don't let them diverge for too long
  • Agree on who owns which areas (e.g., one person on backend auth, another on frontend)
  • Use .editorconfig and formatters to avoid style conflicts:
    • React: Prettier
    • Django: Black

2. Repo Directory Structure

repo-root/
├── backend/                  # Django project
│   ├── manage.py
│   ├── requirements.txt
│   ├── app/
│   └── ...
├── frontend/                 # React project
│   ├── package.json
│   ├── src/
│   └── ...
├── .github/                  # To be updated with TravisCI
│   └── workflows/
│       ├── backend.yml       # CI/CD pipeline for Django
│       └── frontend.yml      # CI/CD pipeline for React
├── .editorconfig
├── .gitignore
└── README.md

Path Filters for GitHub Actions

Each workflow file uses path filters so pipelines only trigger when relevant code changes:

# Example: backend.yml
on:
  push:
    paths:
      - 'backend/**'

This keeps frontend and backend deployments independent, even within the same repo.

3. Branch Protection Policies

Apply these rules to both main and develop via Settings → Branches → Branch Protection Rules on GitHub.

Policy Reason
Require PR before merging No one pushes directly to main or develop
Require at least 1 approval Ensures code is reviewed before integration
Require status checks to pass CI tests must be green before merging
Require branch to be up to date Forces pulling latest changes, reducing conflicts
Disallow force pushes Protects commit history on long-running branches

Clone this wiki locally