Kontrola wersji i współpraca zespołowa

Jest 17:00 w piątek. Rebasujesz swoją gałąź funkcjonalną na main przed wdrożeniem i trafiasz na trójstronny konflikt w pliku, który dwie inne osoby ruszały w tym tygodniu. Wiadomości commitów po obu stronach mówią “wip” i “fixes”, więc nie masz pojęcia, jaką intencję niosła każda zmiana. Dwadzieścia minut później czytasz git blame linia po linii, okno wdrożeniowe się zamyka, a PR kolegi z zespołu leży nieprzejrzany od dwóch dni, bo nikt nie miał czasu przeczytać 600 linii diffa.

To tutaj kontrola wersji wspomagana przez AI zarabia na swoje utrzymanie. Cursor czyta diffy, gałęzie i historię PR tak samo, jak czyta kod, więc potrafi naszkicować wiadomość commita, przeanalizować obie strony konfliktu i zrecenzować PR, zanim człowiek go w ogóle otworzy. Ten przewodnik omawia przepływy pracy specyficzne dla Cursora dotyczące commitów, konfliktów, przeglądów i wspólnego kontekstu zespołu — oraz dokładne prompty, które czynią je niezawodnymi.

Co wyniesiesz

• Sterowany klawiaturą przepływ generowania wiadomości commitów przez AI zgodnych z konwencją twojego zespołu
• Prompt do rozwiązywania konfliktów merge zachowujący intencję z obu gałęzi
• Konfigurację .cursor/BUGBOT.md, dzięki której automatyczny przegląd PR wyłapuje konkretne błędy twojego zespołu
• Wspólne .cursor/rules/, które utrzymują spójność wyników AI u wszystkich
• Prawidłowy sposób uruchamiania Cloud Agents ze Slacka (i to, czego ta integracja nie robi)

Podstawy przepływu pracy Git

Wiadomości commitów generowane przez AI

Nigdy więcej nie pisz ogólnikowej wiadomości commita. Cursor analizuje twoje zmiany w staging i generuje kontekstowe, znaczące wiadomości:

1. Dodaj zmiany do staging w panelu Git
2. Kliknij ikonę gwiazdki obok pola wiadomości commita
3. Przejrzyj i dostosuj wygenerowaną wiadomość
4. Commituj z pewnością

Notatka

Świadomość konwencji
Jeśli twój zespół używa Conventional Commits lub innych standardów, Cursor uczy się i automatycznie podąża za waszymi wzorcami.

Dodanie skrótu klawiszowego

Dla szybszych commitów przypisz generowanie wiadomości do skrótu:

// W Skrótach klawiszowych (Cmd/Ctrl+R, następnie Cmd/Ctrl+S)
{
  "key": "cmd+m",
  "command": "cursor.generateGitCommitMessage"
}

Pytanie Agenta o historię Git

Cursor 2.0 usunął wzmianki @Git, @Branch i @Recent Changes. Agent teraz sam czyta stan git, gdy zapytasz zwykłym językiem — uruchamia git log, git diff i git blame jako narzędzia. Pomiń składnię @ i pytaj bezpośrednio:

Przejrzyj swoją gałąź

Co zmieniłem w module auth na tej gałęzi? Pogrupuj zmiany według intencji.

Porównaj z main

Porównaj tę gałąź z main i podsumuj różnice w zachowaniu,
nie tylko diff na poziomie linii.

Sprawdź ostatnie commity

Pokaż, co zmieniło się w moich ostatnich trzech commitach, i oznacz wszystko,
co wygląda na niezamierzone lub niezwiązane z funkcją.

Pobierz PR

Pobierz PR #123 z tego repo i wyjaśnij, co zmienia i dlaczego.

Notatka

Pobieranie PR działa, ponieważ Cursor indeksuje pull requesty twojego repozytorium — ale wzmianka @PR zniknęła, więc odwołaj się do PR po numerze w swoim promptcie i pozwól agentowi go pobrać.

Checkpointy: twoja siatka bezpieczeństwa

Checkpointy to automatyczne migawki tworzone, gdy Agent wprowadza zmiany do kodu. To twój natychmiastowy przycisk cofnij dla modyfikacji AI.

Jak działają checkpointy

• Automatyczne tworzenie: każda akcja Agenta tworzy checkpoint
• Lokalne przechowywanie: oddzielnie od Git, przechowywane na twoim komputerze
• Oparte na sesji: dostępne dla obecnej i ostatnich sesji
• Tylko Agent: ręczne edycje nie są śledzone

Przywracanie z checkpointów

Dwa sposoby przywracania:

Z pola wprowadzania

Kliknij Restore Checkpoint przy dowolnym poprzednim żądaniu Agenta

Z wiadomości

Najedź na dowolną wiadomość Agenta i kliknij przycisk +

Uwaga

Ważne: Checkpointy to NIE kontrola wersji. Zawsze używaj Git do stałej historii i współpracy zespołowej.

Rozwiązywanie konfliktów merge

Gdy pojawią się konflikty, pozwól AI pomóc w ich inteligentnym rozwiązaniu:

Rozwiązywanie konfliktów wspomagane przez AI

1. Napotkaj konflikt merge - znaczniki Git pojawiają się w plikach
2. Kliknij “Resolve in Chat” w interfejsie konfliktu merge
3. Agent analizuje obie wersje - rozumie intencję z każdej gałęzi
4. Przejrzyj proponowane rozwiązanie - Agent sugeruje inteligentne scalenie
5. Zastosuj lub zmodyfikuj - zaakceptuj rozwiązanie AI lub poproś o zmiany

Domyślny prompt “Resolve in Chat” jest w porządku dla trywialnych konfliktów, ale w każdym przypadku, gdzie obie strony zmieniły zachowanie, daj agentowi wyraźne instrukcje, co zachować. Ogólnikowe prompty typu “scal to” mają tendencję do wybierania jednej strony i po cichu porzucania drugiej:

Wskazówka

Prompt do skopiowania-wklejenia dla rozwiązywania konfliktu merge:

This file has a merge conflict between my branch and main. For each conflict marker:

1. Explain in one line what each side changed and why (read the surrounding code and git history if needed).
2. Produce a merged version that keeps BOTH intents where they are compatible. Do not silently drop either side.
3. If the two sides are genuinely incompatible, stop and ask me which behavior should win -- do not guess.

Show me the resolved file as a diff before applying it.

Instrukcja “stop and ask” ma znaczenie: to różnica między scaleniem, któremu możesz zaufać, a takim, w którym agent po cichu odrzucił zmianę kolegi z zespołu, aby znaczniki konfliktu zniknęły.

Przepływy pracy pull requestów

Generowanie opisów PR z kontekstem

Z podłączonym serwerem GitHub MCP agent może otworzyć PR za ciebie, zamiast tego, żebyś przełączał się do przeglądarki. Jakość opisu zależy całkowicie od tego, jak konkretny jest twój prompt — “zrób PR” produkuje przerobiony diff; poniższy prompt produkuje coś, czego recenzent może faktycznie użyć:

Wskazówka

Prompt do skopiowania-wklejenia dla opisu PR gotowego do przeglądu:

Create a pull request for this branch against main. The description must include:

- A one-paragraph summary of WHAT changed and WHY (the problem it solves), not a list of files.
- A "How to test" section with the exact commands or steps a reviewer should run.
- A "Risk" section calling out anything that touches auth, payments, migrations, or public API.
- Links to any issue numbers I mention here: [#234].

Use our existing commit messages on this branch as the source of truth. Keep it under 250 words.

Indeksowanie i wyszukiwanie PR

Cursor indeksuje pull requesty twojego repozytorium, więc agent może wydobywać historyczne decyzje, zamiast tego, żebyś ręcznie grepował zamknięte PR-y. Pytaj zwykłym językiem i odwołuj się do tego, czego szukasz:

How have we implemented authentication in past PRs? List the relevant PR numbers
and summarize the approach each one took, then tell me which pattern is current.

Agent wydobywa pasujące PR-y i może pobrać pełny diff dowolnego, który wskażesz, jako kolejny krok.

BugBot: twój automatyczny recenzent

BugBot automatycznie recenzuje PR-y pod kątem potencjalnych problemów:

Wykrywanie błędów

Wykrywa sprawdzanie null, obsługę błędów, problemy bezpieczeństwa

Standardy kodu

Egzekwuje konwencje zespołu i najlepsze praktyki

Wydajność

Oznacza potencjalne problemy wydajnościowe

Bezpieczeństwo

Identyfikuje luki w zabezpieczeniach

Konfiguracja BugBot

Utwórz .cursor/BUGBOT.md z zasadami specyficznymi dla zespołu:

# BugBot Configuration

## Critical Rules
- All API endpoints must have authentication
- No console.log statements in production code
- SQL queries must use parameterized statements

## Code Style
- Use async/await instead of promises
- Prefer const over let
- Destructure objects when possible

## Performance
- Warn about N+1 query patterns
- Flag synchronous file operations
- Check for missing database indexes

Funkcje współpracy zespołowej

Wspólny indeks bazy kodu

Zespoły mogą dzielić się pracą nad indeksowaniem dla szybszego wdrażania:

• Automatyczne dzielenie: członkowie zespołu korzystają ze wspólnego indeksu
• Szybsza konfiguracja: nowi programiści zaczynają z prebudowanym indeksem
• Spójny kontekst: wszyscy mają to samo zrozumienie bazy kodu

Przechwytywanie trwałych decyzji projektowych

Modele nie zachowują pamięci między uzupełnieniami, więc trwałe decyzje architektoniczne należą do pliku objętego kontrolą wersji, który dzieli cały zespół — a nie do czatu, o którym agent zapomina. Cursor czyta zarówno pliki .cursor/rules/, jak i AGENTS.md w katalogu głównym projektu na początku kontekstu modelu. Jako szybkie, czytelne miejsce na “fakty, które każdy powinien znać”, AGENTS.md jest opcją o najmniejszym tarciu:

# Project Instructions

## Money handling
- All monetary values are stored as integer cents, never floats.
- Any code that touches prices, totals, or currency must use the Money
  helper in src/lib/money.ts and never do raw floating-point math.

## Conventions
- Authentication uses JWT with a 15-minute access-token expiry.
- Pagination is cursor-based, not offset/limit.

Zapisuj decyzje, które są trwałe; pomijaj jednorazowe fakty, aby plik się nie zdezaktualizował. Gdy decyzja się zmienia, edytuj plik i commituj go, aby agent każdego kolegi z zespołu wychwycił tę zmianę.

Wspólne zasady projektu

Spójność na poziomie zespołu poprzez .cursor/rules/:

general.mdc

---
alwaysApply: true
---

- Use TypeScript for all new files
- Follow ESLint configuration
- Write tests for all new features
- Use semantic commit messages

api-patterns.md

- All endpoints return consistent error format
- Use middleware for authentication
- Validate input with Joi schemas
- Return 201 for successful creation

testing.md

- Unit test coverage minimum 80%
- Integration tests for all API endpoints
- E2E tests for critical user flows
- Mock external services in tests

Zaawansowane wzorce współpracy

Równoległy rozwój z Cloud Agents

Gdy dwie niepowiązane funkcje muszą obie trafić do wdrożenia, nie musisz ich szeregować. Cloud Agents Cursora działają na izolowanych gałęziach w tle, więc możesz wysłać jednego i dalej pracować lokalnie nad drugim. Uruchom je z paska bocznego agenta (lub ze Slacka — patrz niżej), a każdy otworzy własny PR po zakończeniu. Trzymaj zadania naprawdę niezależne; dwóch agentów edytujących ten sam moduł po prostu wręczy ci później konflikt merge.

Przepływ pracy przeglądu kodu

Realistyczna pętla przeglądu z Cursorem w grze wygląda tak:

1. Autor otwiera PR z opisem wygenerowanym przez AI (użyj promptu powyżej).
2. BugBot automatycznie recenzuje diff i komentuje inline znalezione problemy.
3. Ludzki recenzent prosi agenta o wyjaśnienie wszystkiego, co niejasne, zanim przeczyta 600 linii ręcznie — na przykład wklej: Walk me through the authentication flow in this PR and flag any place a token could leak into logs.
4. Autor naprawia feedback z przeglądu w jednym przejściu promptem typu: Address every BugBot comment on this PR. For each one, make the fix and reply with a one-line note on what you changed.
5. Ponowny przegląd, następnie scalenie.

Dzielenie się wiedzą między zespołami

Uruchamianie Cloud Agents ze Slacka

To część, którą większość ludzi robi źle. Aplikacja Cursor dla Slacka nie jest konwersacyjnym botem, który podsumowuje PR-y lub odpowiada na pytania na kanale. Wzmianka @Cursor tworzy Cloud Agenta, który pracuje nad zadaniem kodowania w repozytorium i otwiera PR — wybiera repo i model na podstawie twojej wiadomości i ostatniej aktywności. Użyj tego do rozpoczęcia pracy bez opuszczania Slacka:

@Cursor in backend-api, fix the login bug where expired sessions return 200
@Cursor with opus, refactor the auth module to use the new token helper
@Cursor branch=develop autopr=false add rate limiting to the password reset endpoint
@Cursor list my agents

Użyj branch=, aby ustawić gałąź bazową, oraz autopr=false, jeśli nie chcesz, aby automatycznie otwierał PR. Uruchom @Cursor settings, aby ustawić domyślne repozytorium kanału, oraz @Cursor help, aby zobaczyć bieżącą listę komend. Nie ma komendy “podsumuj ten PR dla QA” — po to zapytaj agenta wewnątrz IDE, używając wcześniejszego promptu do pobierania PR.

Generowanie dokumentacji

Gdy kolega z zespołu potrzebuje dokumentacji, skieruj agenta na kod, zamiast opisywać, czego chcesz:

Wskazówka

Prompt do skopiowania-wklejenia dla generowania dokumentacji API dla innego zespołu:

Generate Markdown API reference docs for every route in @src/routes/. For each endpoint include:
- Method and path
- Auth requirement (which middleware guards it)
- Request body shape with types
- Response shape and status codes
- One realistic curl example

Write it to docs/api-reference.md. Pull the actual types and validation from the route files -- do not invent fields.

Wskazówki i triki Git

Agent może sterować gitem bezpośrednio przez swoje narzędzie terminala, więc to są prompty do wklejenia, a nie skryptowany output:

Create a feature branch off main called fix/cart-totals, cherry-pick commits
5abc123 and 7def456, then push it to origin and show me the resulting log.

Rebase this feature branch onto main. If you hit a conflict, keep my feature's
behavior, explain each resolution, and stop to ask if a resolution is ambiguous.

Dla powtarzalnych sprawdzeń zakoduj je w git hooku, zamiast ponawiać prompt za każdym razem. Hook pre-commit uruchamiający lint i sprawdzanie typów przed każdym commitem:

.git/hooks/pre-commit

#!/bin/bash
npm run lint
npm run type-check

Najlepsze praktyki współpracy zespołowej

Spójne standardy

Używaj wspólnych reguł i konfiguracji BugBot

Przechwytywanie wiedzy

Zapisuj trwałe decyzje we wspólnych regułach i AGENTS.md

Regularne synchronizacje

Dziel się naukami AI na spotkaniach zespołu

Stopniowe wdrażanie

Zacznij od ochotników, rozszerzaj stopniowo

Mierzenie sukcesu współpracy

Śledź te metryki, aby zmierzyć poprawę:

• Czas obrotu PR: powinien się zmniejszyć z recenzjami AI
• Rozwiązywanie konfliktów merge: szybsze z pomocą AI
• Spójność kodu: lepsza ze wspólnymi regułami
• Szybkość wdrażania: nowi deweloperzy produktywni szybciej
• Wskaźnik uciekających błędów: niższy z BugBot wyłapującym problemy

Gdy to się psuje

@Git nic nie robi

Wpisałeś @Git lub @Recent Changes z przyzwyczajenia, a agent to zignorował. Te wzmianki zostały usunięte w Cursor 2.0. Pomiń @ i pytaj zwykłym językiem (“porównaj tę gałąź z main”) — agent uruchamia git sam.

Rozwiązanie konfliktu gubi zmianę

Agent “rozwiązał” konflikt, po cichu wybierając jedną stronę. Ponów prompt z wyraźną instrukcją “keep both intents, stop and ask if incompatible, show me a diff before applying” z powyższego promptu konfliktu merge i przejrzyj diff, zanim zaakceptujesz.

BugBot pomija oczywiste błędy

BugBot wie tylko to, co mu powiesz. Otwórz .cursor/BUGBOT.md, dodaj konkretną zasadę dla wzorca, który pominął (np. “flag any SQL built with string concatenation”), i potwierdź, że BugBot jest włączony dla repo w twoim dashboardzie Cursor.

Agent Slacka zrobił coś nie tak

Pamiętaj, że @Cursor uruchamia agenta kodującego, a nie chatbota. Jeśli wybrał złe repo, nazwij je wyraźnie (@Cursor in backend-api, ...) lub ustaw domyślne dla kanału przez @Cursor settings. Używaj autopr=false, dopóki wciąż kalibrujesz prompty.

Indeks nie jest dzielony w zespole

Cursor kolegi z zespołu reindeksuje od zera. Sprawdź, czy wspólny indeks bazy kodu jest włączony w ustawieniach zespołu i czy ma on dostęp do tego samego workspace i repozytorium.

Co dalej

Reguły projektu Zakoduj konwencje swojego zespołu we wspólne .cursor/rules, aby wynik AI każdego dewelopera pozostawał spójny.

Konfiguracja MCP Podłącz serwer GitHub MCP, aby agent mógł otwierać PR-y, czytać zgłoszenia i pobierać diffy PR bezpośrednio.

Testowanie i jakość Połącz przeglądy BugBot z przepływem testowania wspomaganym przez AI, aby wyłapać regresje, zanim trafią do PR.

Zbuduj swoją pierwszą funkcję Połącz reguły, kontekst i tryb Agent, aby dostarczyć prawdziwą funkcję od początku do końca.