git cicd gitversion - ghdrako/doc_snipets GitHub Wiki
- https://medium.com/@pkjackson466/unlock-efficiency-automated-version-management-using-gitversion-f1c8e4343108
- https://gitversion.net/docs/
Z czego składa się GitVersion i jak działa?
- Semantyczne wersjonowanie (Semantic Versioning)
GitVersion generuje numery wersji zgodnie ze specyfikacją MAJOR.MINOR.PATCH:
MAJOR – zmiana niekompatybilna wstecz,
MINOR – nowa funkcjonalność, kompatybilna wstecz,
PATCH – poprawki błędów lub drobne ulepszenia.
- Strategia gałęzi – GitHub Flow (czyli tzw. mainline)
Artykuł koncentruje się na prostym przepływie pracy GitHub Flow:
Stworzenie krótkiej gałęzi dla zmian (np. „feature-xyz”),
Zmiany, commit i utworzenie PR/MR,
Po akceptacji – merge do main, a gałąź jest usuwana.
Dzięki temu main jest zawsze gotowy do produkcji.
- Wypychanie tagów wersji
Po każdym scalenia do gałęzi main, GitVersion:
Oblicza nową wersję na podstawie commitów,
Wypycha odpowiedni tag w formacie MAJOR.MINOR.PATCH.
- Wzorce w commit message
GitVersion automatycznie zwiększa wersję na podstawie wzorców w wiadomościach commitów:
Major: +semver: breaking lub +semver: major
Minor: +semver: feature lub +semver: minor
Patch: +semver: fix lub +semver: patch
Można też pominąć bump używając +semver: none lub skip.
- Tryb Mainline (ciągły rozwój)
GitVersion oferuje tryb pracy Mainline Development, idealny dla GitHub Flow. Polega on na:
Bazowaniu na ostatnim tagu,
Przejściu przez commity, by zastosować bumpy na podstawie commit message,
Przewidywalnym obliczaniu kolejnej wersji bez potrzeby tagowania każdej zmiany.
GitVersion +1
- Mechanizm działania GitVersion
Proces obliczania wersji (szczególnie w wersji v3+) przebiega tak:
Jeśli obecny commit jest otagowany — używany jest ten tag i metadata builda, a pozostałe kroki są pomijane.
Jeśli nie — wybierana jest strategia wersjonowania (np. Fallback, TaggedCommit, MergeMessage, Mainline itp.).
Na tej podstawie wybierana jest najwyższa możliwa wersja oraz informacja, czy ma być zinkrementowana.
- Zastosowanie w CI/CD
GitVersion można używać:
Lokalne (CLI),
W budowaniu i pipeline’ach CI (np. GitLab CI, Azure DevOps),
Do stemplowania wersji artefaktów,
Do automatycznego patchowania plików AssemblyInfo itp.
Pipeline w .gitlab-ci.yml uruchamia GitVersion jako narzędzie zewnętrzne. Możesz to zrobić np. używając:
obrazu Dockera z GitVersion, albo
zainstalowanego binarnego CLI.
Przykład (Docker):
stages:
- version
- build
variables:
GIT_DEPTH: "0" # ważne, bo GitVersion potrzebuje całej historii
version:
stage: version
image: gittools/gitversion:latest
script:
- gitversion /output json /showvariable FullSemVer > version.txt
artifacts:
paths:
- version.txt
GitVersion analizuje repozytorium → oblicza numer wersji (np. 1.2.3).
Ten numer można używać w kolejnych jobach do:
tagowania obrazów Dockera (myapp:1.2.3),
wersjonowania paczek NuGet/npm,
dodawania wersji do release w GitLabie.
Jak dziala wersjonowanie
Robisz commit i w wiadomości dodajesz instrukcję:
+semver: major → podbije wersję MAJOR (np. 2.0.0 → 3.0.0)
+semver: minor → podbije wersję MINOR (np. 2.3.4 → 2.4.0)
+semver: patch → podbije wersję PATCH (np. 2.3.4 → 2.3.5)
GitVersion czyta te commity podczas pipeline’a.
Wylicza nowy numer wersji na podstawie ostatniego taga + Twoich commitów.
Pipeline dodaje nowy tag w repozytorium (v2.4.0, v3.0.0 itd.).
Instrukcja dla GitVersion (+semver: patch, +semver: minor, +semver: major) to tylko znacznik, który on wyszukuje w treści commita. To co napiszesz w commit message (w tym +semver: patch/minor/major) zostaje w historii gita razem z normalnym opisem Twojego commita.
W praktyce wiele zespołów dodaje go w drugiej linijce commita, żeby tytuł był czysty, a semver tag był w opisie.
Naprawa błędu walidacji w formularzu rejestracji
+semver: patch
+semver: patch
(wtedy Git pokazywałby pierwszą linijkę jako tytuł, a reszta jest w opisie commita).