Skip to content

Git Workflow Guidelines

Jump to bottom
Sagi Evroni edited this page Dec 6, 2025 · 1 revision

Git Workflow Guidelines

This page describes our branch naming conventions and Pull Request (PR) guidelines to ensure a consistent and professional Git workflow across the team.

📑 Table of Contents

1️⃣ Branch Naming Convention

To keep our workflow clean, readable, and consistent, all developers must follow these branch naming rules.

General Rules

  1. Start branches with one of these categories:
    • feature — new functionality or UI
    • bugfix — fixing non-critical bugs
    • hotfix — urgent fix for production issues
    • chore — setup, cleanup, configs, folder structure, refactors
  2. Branch format:
type/domain/short-description
  1. Domain is either frontend or backend.
  2. Short-description should be lowercase, kebab-case (-), and descriptive.

Allowed Branch Structures

Chores (setup, configs, boilerplate):

chore/frontend/
chore/backend/

Features (user-facing functionality):

feature/frontend/
feature/backend/

Bug Fixes (non-critical fixes):

bugfix/frontend/
bugfix/backend/

Hotfixes (critical, urgent fixes):

hotfix/frontend/
hotfix/backend/

Summary Table

Type When to Use Pattern
chore Setup, configs, folder structure chore/{frontend|backend}/desc
feature New functionality feature/{frontend|backend}/name
bugfix Normal bug fix bugfix/{frontend|backend}/name
hotfix Production-critical fix hotfix/{frontend|backend}/name

Additional Rules

  • Never create branches directly named frontend or backend.
  • Avoid spaces, uppercase letters, or special characters.
  • Each branch must go through a Pull Request into main.
  • Avoid long-lived branches; keep changes small and frequent.

2️⃣ Pull Request Guidelines

All code changes must go through Pull Requests (PRs) before merging into the main branch.

General Rules

  1. All changes must be made in a feature/bugfix/chore/hotfix branch.
  2. One PR per task or feature — keep PRs small and focused.
  3. PRs must target the main branch (unless specified otherwise).
  4. Every PR must be reviewed and approved by at least one team member.
  5. Update your branch with main before merging.

PR Content

  • Title (clear and descriptive)
[feature/frontend] Add login page
[bugfix/backend] Fix email validation
[chore/frontend] Setup routing structure
  • Description:
    • What the PR does
    • Why it is needed
    • Screenshots or demos if applicable
    • Link to related issue or task
  • Checklist (Optional but Recommended):
    • Code builds without errors
    • Tests added / updated
    • Code follows project style guidelines
    • No sensitive data committed
    • PR reviewed and approved

Workflow Example

git checkout main
git pull origin main
git checkout -b feature/frontend/login-page

work on feature


git add .
git commit -m "feature/frontend: implement login page"
git push -u origin feature/frontend/login-page


open PR to main
  • Reviewer checks the code
  • Reviewer requests changes if needed
  • Author fixes issues → PR updates automatically
  • Once approved, PR is merged into main

Best Practices

  • Small, frequent PRs
  • Clear, descriptive commit messages
  • Include related issue/ticket references
  • Use code reviews effectively

Do Not

  • Merge without review
  • Commit secrets or sensitive data
  • Push directly to main without PR

Clone this wiki locally