STD-PROC-002 · Strategia branchy¶

1. Cel¶

Ujednolicić model pracy z gałęziami git tak, by historia głównej linii była liniowa, zmiany trafiały na środowiska chronione wyłącznie z zweryfikowanego źródła, a każdy deploy był powtarzalny i identyfikowalny.

2. Zakres¶

Dotyczy wszystkich repozytoriów z kodem aplikacji i infrastruktury zarządzanych w grupie dev.rachuna. Nie dotyczy repozytoriów wyłącznie dokumentacyjnych (archiwa, wikis bez pipeline'ów).

3. Wymagania (normatywne)¶

R1. Domyślnym branchem projektu (default branch) MUSI być main.
R2. Branch main MUSI być chroniony (protected branch).
R3. Branch main MUSI mieć ustawione "Allowed to merge" dla roli Developer lub wyższej.
R4. Branch main MUSI mieć ustawione "Allowed to push" dla roli Maintainer — umożliwia procesom CI bezpośrednie commity niefunkcjonalne (dokumentacja, parametryzacja).
R5. Branch main MUSI mieć wyłączony force push.
R6. Merge Request MUSI być przejrzany przez co najmniej jedną osobę inną niż autor przed scaleniem — weryfikowane przez atestację zespołową (GitLab CE nie wymusza tego systemowo).
R7. Historia main POWINNA być liniowa — preferowany squash merge lub fast-forward.
R8. Gałęzie robocze POWINNY być usuwane po scaleniu.
R9. Konfiguracja ochrony branchy MUSI być zarządzana przez projekt Opentofu iac-gitlab — ręczne zmiany przez UI GitLab są niedozwolone.
R10. Gałęzie robocze MUSZĄ być tworzone zgodnie z poniższą konwencją nazewniczą i pełnić zdefiniowane role:
feat/<nazwa> lub feature/<nazwa> — nowa funkcjonalność; krótkożyjący branch scalany przez MR do main
epic/<nazwa> lub epicfeature/<nazwa> — duży epik skupiający wiele gałęzi feat/; scalany do main po domknięciu epiku
develop — branch integracyjny dla projektów stosujących Gitflow; nie jest wymagany w modelu trunk-based
hotfix/<nazwa> — pilna poprawka błędu produkcyjnego; bazuje na main, scalany z powrotem do main
release/<wersja> — stabilizacja i przygotowanie wydania (np. release/1.2.0); tylko poprawki błędów, bez nowych funkcjonalności
alpha/<nazwa> — wczesny eksperyment lub proof-of-concept; nie jest scalany bezpośrednio do main
docs/<nazwa> — zmiany wyłącznie dokumentacyjne
R11. Wdrożenia produkcyjne MOGĄ być wykonywane wyłącznie z gałęzi main, release/* lub hotfix/*. Wdrożenia z innych gałęzi na środowisko produkcyjne są niedozwolone.

4. Minimum of Done¶

Weryfikacja: bash standards/proces/STD-PROC-002/bin/checks.sh

5. Implementacja — dobra praktyka (informacyjne, niewiążące)¶

Konfiguracja przez Opentofu (iac-gitlab):

Poniżej przykładowa konfiguracja spełniająca wymagania R2–R5. Docelowe miejsce deklaracji: repozytorium iac-gitlab (zgodnie z R9).

{
  "module": {
    "iac-gitlab": {
      "source": "git::https://gitlab.com/dev.rachuna/artifacts/opentofu/gitlab-project.git?ref=1.0.0",
      "name": "iac-gitlab",
      "description": "IAC do zarządzania obiektami GitLab (gitlab.com).",
      "visibility": "public",
      "parent_group": "${local.parent_name}",
      "avatar": "images/opentofu.png",
      "default_branch": "main",
      "gitlab_ci_path": ".gitlab-ci.yml@dev.rachuna/pipelines/gitlab/gitlab-ci:develop",
      "tags": [
        "opentofu",
        "opentofu-iac"
      ],
      "ci_variables": {
        "TERRAFORM_DOCS_AUTOFIX": {
          "value": "true",
          "description": "Włączenie autofix przez proces CI/CD"
        }
      },
      "protected_branches": {
        "main": {
          "push_access_level": "maintainer",
          "merge_access_level": "developer",
          "allow_force_push": false
        }
      },
      "protected_tags": {},
      "environments": {
        "production": {
          "external_url": "https://gitlab.com/dev.rachuna/infrastructure/gitlab-com/iac-gitlab/-/terraform"
        }
      }
    }
  }
}

Model trunk-based: main jest zawsze gotowy do wdrożenia. Gałęzie robocze żyją krótko (feat/login-oidc, fix/api-timeout, chore/deps-update). Brak długożyjących gałęzi integracyjnych.

Strategia merge: squash dla MR z wieloma roboczymi commitami (historia main liniowa); fast-forward dla MR z jednym finalnym commitem zgodnym z Conventional Commits (STD-PROC-003).

6. Referencje¶

STD-PROC-003 Conventional Commits · STD-PROC-004 Zarządzanie wydaniami · GitLab — Protected Branches · Trunk-based development.