DEV Community

Cover image for Practical Git & GitHub Setup for Real-World Projects
Shakil Alam
Shakil Alam

Posted on

Practical Git & GitHub Setup for Real-World Projects

#git #github

A lot of Git & GitHub guides look perfect on paper—but fail in real life. Either they are too complex (enterprise-level GitFlow) or too basic ("just push to main").

This guide focuses on a clean, realistic, and production-ready Git & GitHub setup that actually works for solo developers and teams.

Why This Setup Works

  • Easy for beginners
  • Scales for teams
  • Minimal rules, maximum clarity
  • Used in real production projects

1. Branching Strategy (Simple but Powerful) 

main        → production-ready code
develop     → active development
feature/*   → new features
bugfix/*    → bug fixes
hotfix/*    → urgent production fixes
Enter fullscreen mode Exit fullscreen mode

Examples 

feature/user-login
bugfix/cart-total
hotfix/payment-crash
Enter fullscreen mode Exit fullscreen mode

Why Not Complex GitFlow?

  • Fewer branches to manage
  • Faster onboarding
  • Less confusion

2. Commit Message Convention

Use a lightweight conventional format:

type(scope): short description
Enter fullscreen mode Exit fullscreen mode

Common Types

  • feat – new feature
  • fix – bug fix
  • refactor – internal improvement
  • docs – documentation
  • test – tests
  • chore – tooling / config

Examples 

feat(auth): add OTP login
fix(cart): correct total price
refactor(api): simplify serializer
Enter fullscreen mode Exit fullscreen mode

3. GitHub Labels (Minimal & Useful)

Type

  • type: bug
  • type: feature
  • type: enhancement
  • type: refactor

Priority

  • priority: high
  • priority: medium
  • priority: low

Status

  • status: ready
  • status: in-progress
  • status: blocked
  • status: needs-review

Severity (for bugs)

  • severity: critical
  • severity: major
  • severity: minor

4. Issue Templates

Bug Report 

## Description

## Steps to Reproduce

## Expected Behavior

## Actual Behavior

## Environment
Enter fullscreen mode Exit fullscreen mode

Feature Request 

## Problem

## Proposed Solution

## Alternatives

## Additional Context
Enter fullscreen mode Exit fullscreen mode

5. Pull Request Template 

## What does this PR do?

## Related Issue
Closes #123

## Changes Made

## How to Test

## Checklist
- [ ] Code follows standards
- [ ] Tests added/updated
- [ ] No breaking changes
Enter fullscreen mode Exit fullscreen mode

6. Code Review & Branch Protection

Rules

  • No direct push to main
  • PR required
  • At least 1 approval
  • Status checks must pass

This ensures quality without slowing development.

7. Automation with GitHub Actions

Basic CI Workflow

Create .github/workflows/ci.yml

name: CI

on:
  pull_request:
  push:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 18

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test
Enter fullscreen mode Exit fullscreen mode

What This Gives You

  • PRs fail automatically if tests break
  • No human needs to remember running tests
  • Cleaner main branch

8. Solo Developer vs Team Setup

Solo Developer (Recommended)

  • Branches: main, feature/*
  • Labels: type + priority
  • PRs: optional but recommended
  • CI: yes (non-negotiable)

Why?
Even solo devs forget context. This keeps history clean.

Small Team (2–5 Developers)

  • Full branching strategy
  • Mandatory PRs
  • Labels for status & severity
  • CI required before merge

Result:
Less confusion, fewer bugs, faster reviews.

Larger Teams

  • Add CODEOWNERS
  • Require 2 approvals
  • Add lint + security checks
  • Auto-release notes

9. README Structure 

# Project Name

## Description

## Tech Stack

## Setup

## Scripts

## Contributing

## License
Enter fullscreen mode Exit fullscreen mode

10. Common Mistakes to Avoid

  • Too many labels
  • Direct commits to main
  • Vague commit messages
  • No automation
  • No PR template

Final Thoughts

A good Git & GitHub setup should disappear into the background and let you focus on building.

This setup is:

  • Easy
  • Scalable
  • Production-proven

Top comments (0)