Practical Git & GitHub Setup for Real-World Projects

Source: Dev.to

Why This Setup Works

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

Branching Strategy (Simple but Powerful)

main        → production‑ready code
develop     → active development
feature/*   → new features
bugfix/*   → bug fixes
hotfix/*   → urgent production fixes

Examples

feature/user-login
bugfix/cart-total
hotfix/payment-crash

Why Not Complex GitFlow?

• Fewer branches to manage
• Faster onboarding
• Less confusion

Commit Message Convention

Use a lightweight conventional format:

type(scope): short description

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

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

Issue Templates

Bug Report

## Description

## Steps to Reproduce

## Expected Behavior

## Actual Behavior

## Environment

Feature Request

## Problem

## Proposed Solution

## Alternatives

## Additional Context

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

Code Review & Branch Protection

Rules

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

These rules ensure quality without slowing development.

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

What This Gives You

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

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

README Structure

# Project Name

## Description

## Tech Stack

## Setup

## Scripts

## Contributing

## License

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