Branching i Pull Requesty
Po co gałęzie
Gałąź izoluje pracę nad jedną zmianą od stabilnego main. Dzięki temu kilka
osób pracuje równolegle, a niedokończona funkcja nie blokuje produkcji.
W ProfessNet main jest zawsze "deployowalny" — to on jedzie na Vercel.
Strategia gałęzi ProfessNet
Stosujemy lekki trunk-based z krótkożyjącymi gałęziami funkcyjnymi.
| Prefiks | Przeznaczenie | Przykład |
|---|---|---|
feature/ | Nowa funkcjonalność | feature/widget-mfa |
fix/ | Poprawka błędu | fix/login-redirect |
hotfix/ | Pilna łatka na produkcji | hotfix/csrf |
chore/ | Porządki, zależności | chore/bump-next-15 |
Gałęzie mają żyć krótko — im dłużej odstają od main, tym trudniejszy
merge i więcej konfliktów.
git switch main
git pull
git switch -c feature/widget-mfa
Cykl pracy
- Zaktualizuj
main(git pull). - Utwórz gałąź
feature/.... - Pracuj małymi, logicznymi commitami.
- Wypchnij gałąź na GitHub.
- Otwórz Pull Request do
main. - Przejdź review + zielony CI.
- Merge i usuń gałąź.
git push -u origin feature/widget-mfa
# następnie utwórz PR przez gh CLI lub na GitHubie
gh pr create --base main --title "feat: widżet MFA" --body "Dodaje widżet MFA na dashboardzie."
Czym jest Pull Request
PR to prośba o włączenie Twojej gałęzi do main plus miejsce na review,
komentarze i wynik CI. To brama jakości — w ProfessNet nic nie wchodzi na
main bez PR. PR uruchamia GitHub Actions i generuje preview na Vercelu.
Wskazówka: Trzymaj PR-y małe (najlepiej < 400 zmienionych linii). Mały PR jest szybciej i rzetelniej recenzowany niż gigant, którego nikt nie chce czytać. Dziel duże zadania na serię PR-ów.
Aktualizowanie gałęzi względem main
Gdy main poszedł do przodu, zaciągnij zmiany, by uniknąć dryfu:
git switch feature/widget-mfa
git fetch origin
git merge origin/main # albo: git rebase origin/main
Merge zachowuje historię jak jest; rebase układa Twoje commity "na czubku"
main (czystsza, liniowa historia). Wybór zależy od konwencji repo — kluczowe,
by nie robić rebase na gałęzi, którą współdzieli ktoś inny.
Ochrona gałęzi main
Na main włączamy branch protection: wymagany przegląd, zielony status
checks i brak pushy bezpośrednich. To gwarantuje, że każda zmiana przeszła
przez review i CI.
Podsumowanie
Krótka gałąź feature/... → mały PR → review → zielony CI → merge do main.
Trzymaj gałęzie świeże względem main, dziel pracę na małe PR-y i nigdy nie
pushuj wprost na chroniony main. To rdzeń obiegu pracy w ProfessNet.