Downloads

GitHub Processes

Pull Request Template
Bug Report Template
Feature Request Template

Branching Strategy (clean, professional, simple)

Keep branching rules simple. We don’t want a small team getting lost in GitFlow complexity.

We use a lightweight GitFlow Hybrid:

Branch
  • Main
  • develop
  • feature/*
  • release/x.y.z
  • hotfix/*
Purpose
  • production
  • integration for next release
  • one task, one PR
  • stabilizing next release
  • emergency production fixes
Lifetime
  • forever
  • forever
  • short-lived
  • short-lived
  • short-lived

This Git strategy ensures:

  • Clean and predictable release flow
  • Fast onboarding of new developers
  • Safe integration of features
  • Clear testing stages
  • Zero long-lived personal branches
  • Automatic cleanup of merged branches

The 10 point strategy is intentionally simple, avoiding unnecessary complexity.

Permanent Branches

Main:

  • Always production-ready
  • Only updated via PR from:
    • release/x.y.z
    • hotfix/*

develop:

  • Integration branch
  • All features are merged here
  • Forms basis of future release candidates

Temporary Branch Types

feature/[summary]

For individual tasks, e.g:

  • feature/add_vessel_notes
  • feature/update_engine_form_validation
  • feature/new_pdf_renderer

Rules:

  • Created from develop
  • PR must target develop
  • Auto-deleted after merge

release/x.y.z

Example: release/3.5.0

Created when: develop is frozen → ready for testing

Rules:

  • Only bug fixes / polish
  • Devs create fix/* branches from this release branch
  • Testing team validates itMerged into main
  • Merged back into develop (to keep fixes)
  • Deleted afterward

hotfix/<summary>

Intent: Used only when production has a critical issue.

Flow: branch off main → implement fix → PR to main → merge → tag → merge into develop → delete

Branch Naming Rules

Rules

  • Lowercase
  • Words separated by underscores
  • Prefix dictates branch type

Examples:

feature/vessel_editor_redesign

fix/engine_form_validation

hotfix/login_failure_fix

release/3.6.0

Workflow

Developer Workflow (Step-by-Step)

  1. Pull develop
  2. Create a feature branch:

git checkout develop

git pull

git checkout -b feature/new_component

  1. Commit & push
  2. Open PR → base = develop
  3. Senior dev reviews & merges
  4. Branch is auto-deleted

Release Workflow

  1. Senior dev freezes develop
  2. Create a release branch:

git checkout develop

git checkout -b release/3.5.0

  1. Testing team validates
  2. Bug fixes made via branches like: fix/3.5.0_date_picker_crash → PR to release/3.5.0

when ready:

release/3.5.0 → main (via PR)

main is tagged: v3.5.0

  1. Merge release back into develop: release/3.5.0 → develop
  2. Delete release branch

HotFix Workflow

Branch from main: hotfix/vessel_edit_crash

  1. Apply fix
  2. PR to main
  3. Merge + tag
  4. Merge back to develop
  5. Delete hotfix branch

Cleanup & Repo Hygiene

  • Delete merged branches automatically
  • GitHub setting: “Automatically delete head branches” = ON
  • No long-lived dev branches dan_develop, jeff_dev, etc. are forbidden.
  • No feature branches older than 30 days
  • You can enforce this with a GitHub action if needed.

Access Control

  • Only Senior Dev / Munster merges:
    • Release branches
    • Hotfix branches
    • Develop through PRs only
  • No direct commits to main or develop

GitHub Settings

Protect main

  • Require PR
  • Require 1–2 reviewers
  • Require CI to pass
  • No force pushes
  • Signed commits optional

Protect develop

  • Require PR
  • Require 1 reviewer
  • No force pushes

Visual Structure (Final)

  main

    └── release/3.5.0

      ├── fix/date_picker_crash

      └── fix/api_retries

  develop

    └── feature/add_maintenance_log

    └── feature/vessel_editor_redesign

    └── feature/improve_search

Everything else is deleted once merged.

Conclusion

Old System: 

  • Nested dev branches
  • Personal dev branches
  • Very long-lived stale branches
  • Confusing release candidate naming
  • No clear QA stage separation

New System: 

  • Fast onboarding
  • Clean repo
  • Clear release stages
  • Reproducible process
  • Senior dev controls quality

Branch Naming Validator

  • DAN: to setup GitHub Action

Ensures all team developers follow our feature/*, fix/*, hotfix/*, release/* pattern.

  .github/workflows/branch-name-check.yml

  name: Validate Branch Name

  on:

    pull_request:

      types: [opened, synchronize, reopened]

  jobs:

    validate-branch-name:

      runs-on: ubuntu-latest

      steps:

        – name: Check branch name

          run: |

            BRANCH_NAME=”${{ github.head_ref }}”

            if [[ ! “$BRANCH_NAME” =~^(feature|fix|hotfix|release)\/[a-z0-9._-]+$ ]]; then

              echo “Invalid branch name: $BRANCH_NAME”

              echo “Use one of: feature/*, fix/*, hotfix/*, release/*”

              exit 1

            fi

          – name: Branch name is valid

            run: echo “Branch name OK”