Pierwszy commit i workflow¶

Workflow Git¶

Projekt używa trunk-based development z feature branches:

main (produkcja)
  ↑
develop (development)
  ↑
feature/your-feature-name

Przygotowanie do pracy¶

1. Zaktualizuj develop¶

git checkout develop
git pull origin develop

2. Utwórz feature branch¶

# Nazwa brancha: feature/opis-zadania
git checkout -b feature/add-budget-validation

# Lub dla bugfixa
git checkout -b bugfix/fix-client-validation

# Lub dla hotfixa (z main)
git checkout main
git checkout -b hotfix/critical-security-issue

Konwencje nazewnictwa branchy¶

feature/ - nowa funkcjonalność
bugfix/ - naprawa buga
hotfix/ - pilna naprawa (z main)
refactor/ - refactoring
docs/ - dokumentacja
test/ - testy

Wykonaj zmiany¶

1. Edytuj pliki¶

# Frontend - dodaj walidację
# Edytuj: projects/budgets/src/lib/validators/budget.validator.ts

# Backend - dodaj walidację
# Edytuj: Masaku.Services/Validators/BudgetValidator.cs

2. Testuj lokalnie¶

Frontend:

# Uruchom testy
npm test

# Sprawdź linting
npm run lint

# Sprawdź czy builduje się
npm run build:test-de

Backend:

# Uruchom testy
dotnet test

# Uruchom API i sprawdź ręcznie
dotnet run

3. Sprawdź zmiany¶

# Zobacz co zmieniłeś
git status

# Zobacz diff
git diff

# Diff konkretnego pliku
git diff projects/budgets/src/lib/validators/budget.validator.ts

Commit¶

1. Dodaj pliki do stage¶

# Wszystkie zmienione pliki
git add .

# Konkretne pliki
git add projects/budgets/src/lib/validators/budget.validator.ts
git add Masaku.Services/Validators/BudgetValidator.cs

# Sprawdź co jest staged
git status

2. Commit z opisem¶

Konwencja commit messages:

<type>(<scope>): <subject>

<body>

<footer>

Types: - feat - nowa funkcjonalność - fix - bugfix - refactor - refactoring - test - testy - docs - dokumentacja - chore - zmiany w build/config - style - formatowanie kodu (bez zmian logiki)

Przykłady:

# Prosty commit
git commit -m "feat(budgets): add budget amount validation"

# Z body
git commit -m "feat(budgets): add budget amount validation

- Add BudgetValidator with amount range check
- Update BudgetFormComponent to show validation errors
- Add unit tests for validator

Resolves #123"

# Bugfix
git commit -m "fix(clients): fix NIP validation for Austrian companies"

# Refactoring
git commit -m "refactor(expenses): extract expense calculation to service"

# Dokumentacja
git commit -m "docs(onboarding): add debugging guide"

3. Push do remote¶

# Pierwszy push (ustaw upstream)
git push -u origin feature/add-budget-validation

# Kolejne pushe
git push

Pull Request¶

1. Utwórz PR w Azure DevOps¶

Wejdź na Azure DevOps
Repos → Pull Requests
Kliknij "New Pull Request"
Source: feature/add-budget-validation
Target: develop

2. Wypełnij opis PR¶

Template:

## Opis
Dodano walidację kwoty budżetu aby zapobiec ujemnym wartościom.

## Zmiany
- [x] Frontend: Dodano BudgetValidator
- [x] Frontend: Zaktualizowano BudgetFormComponent
- [x] Backend: Dodano BudgetAmountValidator
- [x] Testy jednostkowe
- [ ] Testy E2E (do zrobienia)

## Screenshots
[Wklej screenshot jeśli zmiany w UI]

## Test plan
1. Otwórz formularz dodawania budżetu
2. Wpisz ujemną kwotę
3. Sprawdź czy pokazuje się błąd walidacji
4. Wpisz poprawną kwotę
5. Sprawdź czy można zapisać

## Checklist
- [x] Kod działa lokalnie
- [x] Testy przechodzą
- [x] Linting OK
- [x] Code review własny przeprowadzony
- [ ] Dokumentacja zaktualizowana (jeśli potrzeba)

## Linked issues
Resolves #123

3. Dodaj reviewerów¶

Wybierz minimum 1-2 reviewers: - Team lead (obowiązkowo dla większych zmian) - Ktoś kto zna ten obszar kodu

4. Czekaj na review¶

Reviewer może: - ✅ Approve - możesz mergować - 💬 Comment - sugestie do rozważenia - ⛔ Request changes - musisz poprawić

Obsługa review comments¶

1. Wprowadź poprawki¶

# Edytuj pliki według sugestii
# ...

# Commit poprawek
git add .
git commit -m "fix: address review comments"

# Push
git push

PR zostanie automatycznie zaktualizowany.

2. Odpowiedz na komentarze¶

Odpowiedz na każdy komentarz
Jeśli coś zmieniłeś: "Fixed in [commit hash]"
Jeśli nie zgadzasz się: wyjaśnij dlaczego
Zaznacz resolved gdy załatwione

Merge¶

1. Upewnij się że:¶

✅ Wszystkie testy przechodzą (CI/CD pipeline)
✅ Code review approved
✅ Konflikty rozwiązane
✅ Branch zaktualizowany z develop

2. Merge strategies¶

Squash merge (zalecane dla małych PR): - Wszystkie commity łączą się w jeden - Historia jest czysta - W Azure DevOps: "Complete" → "Squash commit"

Standard merge: - Zachowuje wszystkie commity - Używaj dla większych feature branchów

Rebase and merge: - Linear history - Używaj ostrożnie (może powodować problemy)

3. Complete PR¶

W Azure DevOps: 1. Kliknij "Complete" 2. Wybierz merge strategy 3. Zaznacz "Delete source branch" (branch zostanie usunięty) 4. Kliknij "Complete merge"

Po merge¶

1. Zaktualizuj lokalnego developa¶

git checkout develop
git pull origin develop

# Usuń lokalnego feature brancha
git branch -d feature/add-budget-validation

2. Sprawdź deployment¶

Testing environment: automatyczny deploy po merge do develop
Staging: manual deployment
Production: manual deployment z main

Git hooks¶

Projekt może używać pre-commit hooks:

# W .git/hooks/pre-commit
#!/bin/sh
npm run lint-staged

Jeśli commit się nie udaje:

# Pomiń hook (ostrożnie!)
git commit --no-verify -m "..."

Troubleshooting¶

Konflikty podczas merge¶

# Zaktualizuj z develop
git checkout develop
git pull origin develop

# Wróć do feature brancha
git checkout feature/add-budget-validation

# Merge develop do feature
git merge develop

# Rozwiąż konflikty w edytorze
# Pliki z konfliktami będą oznaczone:
# <<<<<<< HEAD
# Twoje zmiany
# =======
# Zmiany z develop
# >>>>>>> develop

# Po rozwiązaniu
git add .
git commit -m "merge: resolve conflicts with develop"
git push

Pomyłkowo committed na develop¶

# Jeśli nie push'owałeś jeszcze
git reset --soft HEAD~1  # Cofnij commit, zostaw zmiany

# Utwórz feature branch
git checkout -b feature/my-changes
git push -u origin feature/my-changes

Chcę zmienić ostatni commit message¶

# Jeśli nie push'owałeś
git commit --amend -m "nowa wiadomość"

# Jeśli już push'owałeś (force push - ostrożnie!)
git commit --amend -m "nowa wiadomość"
git push --force-with-lease

Chcę dodać coś do ostatniego commita¶

# Edytuj pliki
git add .

# Amend do ostatniego commita
git commit --amend --no-edit

# Push (jeśli już było push'owane)
git push --force-with-lease

Best practices¶

DO:¶

✅ Małe, atomowe commity
✅ Opisowe commit messages
✅ Testy przed commitem
✅ Code review własny przed PR
✅ Aktualizuj branch z develop regularnie
✅ Odpowiadaj na review comments
✅ Usuwaj feature branche po merge

DON'T:¶

⛔ Commit bezpośrednio na develop/main
⛔ Force push na develop/main
⛔ Commit secrets/credentials
⛔ Commit node_modules, bin/, obj/
⛔ Commit bez testów
⛔ Merge bez code review

Przykładowy workflow¶

# 1. Nowe zadanie
git checkout develop
git pull origin develop
git checkout -b feature/add-expense-category

# 2. Rozwój
# ... edytuj pliki ...
git add .
git commit -m "feat(expenses): add category field"

# ... więcej zmian ...
git commit -m "test(expenses): add category tests"

# 3. Push
git push -u origin feature/add-expense-category

# 4. Utwórz PR w Azure DevOps

# 5. Review comments
# ... wprowadź poprawki ...
git commit -m "fix: address review comments"
git push

# 6. Merge (w Azure DevOps)

# 7. Cleanup
git checkout develop
git pull origin develop
git branch -d feature/add-expense-category