Strategie Git i Workflow

Co to jest Git Flow i kiedy stosować trunk-based development?

Git Flow (Vincent Driessen, 2010): ustrukturyzowany model branchowania. Gałęzie: main (produkcja), develop (integracja), feature/* (nowe funkcje), release/* (przygotowanie do releasa), hotfix/* (pilne poprawki). Flow: feature/* -> develop -> release/* -> main + tag. Wady Git Flow: skomplikowany dla small teams. Long-lived branches = merge hell. Ciągła integracja trudniejsza. Dobre dla: scheduled releases (software z numerowanymi wersjami). GitHub Flow (GitHub, 2011): prostszy. main + feature branches. Pull Request -> code review -> merge to main. Deploy po każdym merge. Continuous deployment friendly. Trunk-Based Development (TBD): jeden główny branch (trunk/main). Krótkotrwałe feature branches (max 1-2 dni). Feature flags zamiast długich gałęzi. Ci każdy commit -> build + test. CD każdy zielony build -> deploy. Zalety TBD: minimalna integracja konfliktów. Continuous delivery native. Szybki feedback. Wady: wymaga dyscypliny, feature flags, strong CI. Kiedy co: Git Flow — release-based desktop/mobile apps. GitHub Flow — web apps z CD. TBD — dojrzałe zespoły, microservices. Forking workflow: dla open-source. Fork repo. PR do upstream. Contributor nie ma write access do main repo. GitLab Flow: środek między Git Flow a TBD. Environment branches (staging, production). Feature flags integracja. Release branches opcjonalne.

Conventional Commits, Semantic Release i automatyczny changelog?

Conventional Commits (1.0.0): specyfikacja dla wiadomości commitów. Format: type(scope): description. Typy: feat (nowa funkcja), fix (bugfix), docs (dokumentacja), style (formatowanie), refactor, test, chore (buildy, deps). BREAKING CHANGE: footer lub ! po type. Przykłady: feat(auth): add OAuth2 login. fix(api): handle null response from payment. refactor!: remove deprecated UserContext API. BREAKING CHANGE: UserContext removed. Korzyści: automatyczny changelog. semantic versioning automatyczny. Czytelna historia. Angular commit conventions: inspiracja dla Conventional Commits. Używane w Angular monorepo. Commitlint: npm install @commitlint/cli @commitlint/config-conventional. commitlint.config.js: {extends: ['@commitlint/config-conventional']}. Husky hook: commit-msg -> npx --no commitlint --edit. Commitizen (cz-cli): interaktywne commitowanie. npx cz zamiast git commit. Guided prompts: select type, scope, description. Semantic Release: automatyczne versioning i publishing. Analizuje commits od ostatniego release. feat -> minor bump. fix -> patch bump. BREAKING CHANGE -> major bump. Generuje CHANGELOG.md. Tworzy GitHub Release. Publikuje na npm. .releaserc.json konfiguracja. Changesets (alternatywa): ręczne opisy zmian per PR. popularny w monorepo (pnpm workspaces). pnpm changeset add -> select packages -> describe. pnpm changeset version -> bumps versions. GitHub Release notes: automatyczne z PR labels. release-please (Google): PR-based releases. Conventional commits analysis.

Code Review — pull request best practices i GitHub workflow?

Pull Request (PR) best practices: małe PR (max 400 linii diff). Jeden PR = jedna zmiana. Opis: co zmieniono i dlaczego. Screenshots dla UI changes. Reviewer checklist. Draft PR: work-in-progress. Oznacz jako 'ready for review' po ukończeniu. CI/CD na PR: testy muszą przejść przed review. Lint, type check, unit tests, E2E. Test coverage check. Security scan (CodeQL, Snyk). PR templates: .github/PULL_REQUEST_TEMPLATE.md. Checkboxes: testy dodane, docs zaktualizowane, screenshot. Code review guidelines: Approve szybko (< 24h). Konstruktywna feedback. Pytaj o uzasadnienie zamiast krytykować. Nitpick label dla minor issues. LGTM (Looks Good To Me). Required reviewers: CODEOWNERS file. .github/CODEOWNERS: *.tsx @frontend-team. /api/* @backend-team. Branch protection rules: require PR. require status checks (CI). require code review (min 1-2). dismiss stale reviews. restrict force push. Squash and merge: jeden commit per PR w main. Czystsza historia. Bisect łatwiejszy. Merge commit: zachowuje historię. PR traceability. Rebase and merge: liniowa historia bez merge commits. Git bisect: git bisect start. git bisect bad HEAD. git bisect good v1.0. Automatycznie finuje regresję. GitHub Copilot Review: AI code review. Sugestie security. Automatyczna dokumentacja. Nie zastępuje human review.

Git rebasing, squashing i zaawansowane operacje?

git rebase: przenosi commity na nową bazę. git rebase main — rebazuj feature branch na aktualny main. Rozwiązuj konflikty commit po commit. git rebase --continue po resolving. Vs merge: rebase = liniowa historia. merge = merge commit, zachowuje context. Interactive rebase: git rebase -i HEAD~5. pick = zachowaj. squash = połącz z poprzednim. fixup = squash + odrzuć message. reword = zmień message. drop = usuń commit. edit = zatrzymaj dla amend. Squash commits: git rebase -i HEAD~3 -> squash -> nowy message. Czystsza historia przed merge do main. git commit --amend: zmień ostatni commit (message lub staged files). Nie używaj po push (historia rozbieżna). git cherry-pick: wybierz konkretny commit. git cherry-pick abc123. Przydatny do: port hotfix z main do release branch. git stash: tymczasowe schowanie zmian. git stash push -m 'WIP feature'. git stash pop — przywróć. git stash list, apply, drop. git reflog: historia wszystkich HEAD movements. Przywróć utracone commity. git reflog show -> git checkout lub reset. git bisect: bisekcja do znalezienia regresji. git bisect start. bad HEAD, good v1.0. Automatyczne lub manualne. git worktree: wiele working trees z jednego repo. git worktree add ../hotfix hotfix/critical-bug. Równoległa praca na wielu branchach. git hooks: pre-commit, commit-msg, pre-push. Husky zarządza hookami. Lefthook: Go-based, szybszy niż Husky.

Git w zespole — strategie merge, konflikty i monorepo git?

Merge strategies: --ff (fast-forward): prosta linia, brak merge commit. --no-ff (no fast-forward): zawsze merge commit. --squash: jeden commit per feature branch. GitHub: squash and merge (zalecane dla feature). merge commit (dla release). rebase and merge (dla patch/fix). Konflikt resolution: git mergetool — GUI merger. VSCode: three-way merge editor. Accept current / incoming / both. Manual edit. Uwaga na: auto-resolved conflicts mogą być logicznie błędne. Zawsze review po merge. GitLens (VSCode extension): git blame w edytorze. History per line. PR integration. Graph view. Git Large File Storage (LFS): dla binarnych plików (design assets, videos). git lfs track '*.psd'. .gitattributes. Przechowuje pointer zamiast binarki. Monorepo git strategie: jedna historia dla wszystkich pakietów. Atomic commits (API + client razem). git blame traverse packages. Sparse checkout: git sparse-checkout set packages/frontend. Praca tylko na podzbiorze repozytorium. Przydatny w dużych monorepo. GitHub Actions dla monorepo: paths filter: on push paths: ['packages/api/**']. Triggeruj tylko dotknięte pakiety. Nx affected: nx affected:build, nx affected:test. Tylko zmienione + zależne. Turborepo: cache per package. Incremental builds. git hooks best practices: pre-commit: lint + format (fast). pre-push: full test suite (slow). commit-msg: commitlint. Husky + lint-staged: lint tylko staged files. lint-staged: {'*.{ts,tsx}': ['eslint --fix', 'prettier --write']}.

Wyślij zapytanie