Skip to content

Git governance - canonical rules

Governance intent

These rules protect the baseline branch (main) and the long-term health of the project.

They do not restrict who may contribute or how contributors work in their own forks.

All contributions are welcome via Pull Requests.

Scope

  • local development environments
  • personal GitHub forks
  • safe contribution to the upstream repository

Repository roles

upstream : authoritative repository (read-only via git) personal : contributor fork (integration, testing, CI) local : developer working copy

Reference baselines

When you sync, make sure main matches upstream.

Baseline protection

main is the long-term reference branch.

Any change reaching a baseline branch is considered high-impact and therefore requires explicit human validation.

  • main represents a production-quality state

Action branches

When used, action/* branches are the canonical location for GitHub Actions changes:

  • action/* branches should contain only .github/ content
  • Work branches may be created from action/*
  • Direct commits are discouraged to keep changes reviewable
  • Promotion to main happens via Pull Request

Review and merge policy

How many people must have read a change before it is merged is set by each repository, in its CONTRIBUTING.md. For xymon every change to main or devel lands through a Pull Request, and whether it also needs a review by someone other than its author depends on the kind of change — see CONTRIBUTING.md. Repositories that do not say otherwise may be pushed to directly.

If an exception is needed, it must be clearly explained in the Pull Request.

Allowed merge modes are set per repository as well, in the same place.

Hard rules

  • Upstream is fetch-only; make all changes in personal or local
  • Branch from main and avoid direct commits on it
  • Use work branches for non-trivial changes
  • Any divergence from baselines must be intentional

Document authority

This document is the authoritative reference for Git governance in this project.

All other Git-related documents (processes, workflows, CI flows) must align with these rules and must not redefine them.

If something conflicts with this document, this document takes precedence.