Kontrola wersji i współpraca zespołowa w Cursorze

Agent Cursora przejmuje pracę z kontrolą wersji we wspólnym repozytorium: pisze wiadomości commitów na podstawie zmian w stagingu, rozwiązuje konflikty merge po przeczytaniu obu gałęzi, przygotowuje opisy pull requestów i wstępnie recenzuje PR współpracownika. Git pozostaje źródłem prawdy, a testy i git show --remerge-diff dowodzą, co agent faktycznie zmienił.

Ta strona jest dla programisty, który ma już zainstalowanego Cursora i pracuje w repozytorium, do którego pushują też inni. Jest piątek, 17:00. Przed wydaniem scalasz main do swojej gałęzi i trafiasz na konflikt w pliku, który w tym tygodniu zmieniały dwie inne osoby. Ich commity mają opisy „wip” i „fixes”, PR współpracownika na 600 linii czeka na przegląd od dwóch dni, a ty nie masz czasu czytać ani jednego, ani drugiego linijka po linijce.

Co daje kontrola wersji prowadzona przez agenta w Cursorze

• Bezpieczny punkt wyjścia w gicie, dzięki któremu żadna akcja agenta nie zabierze ci pracy, która nie trafiła do commita
• Prompt do wiadomości commitów, który trzyma się konwencji zespołu i opisuje tylko to, co jest w stagingu
• Prompt do konfliktów merge, który zachowuje intencję obu stron, oraz dwa polecenia gita pokazujące dokładnie, co zmieniło rozwiązanie
• Prompt do pull requestów, który daje opis, na podstawie którego recenzent może działać
• Prompt do przeglądu cudzego PR-a, który wskazuje, gdzie patrzeć, zamiast kazać czytać każdą linię
• Jasny podział: co sprawdzasz ty, co CI, a co Bugbot

Konfigurację całego zespołu (wspólne reguły projektu, serwery MCP i skille) omawia strona współpraca zespołowa w Cursorze. Tutaj chodzi o codzienną pętlę pracy z gitem.

Przygotuj bezpieczny stan repozytorium, zanim agent dotknie historii

Agent Cursora uruchamia gita w swoim terminalu jak każde inne polecenie powłoki, zgodnie z trybem uruchamiania, który wybrałeś (Auto-review, Allowlist albo Run Everything; dokumentacja Cursora, sprawdzone 2026-10-12). Dzięki temu działa szybko, ale błędne git checkout --theirs . wykona równie chętnie jak poprawne polecenie. Dlatego najpierw zabezpiecz się.

1. Zaczynaj każde zadanie agenta od czystego drzewa roboczego. Zacommituj albo odłóż to, co masz; -u odkłada też pliki nieśledzone, więc w drzewie nie zostaje nic nowego:

   git status --short
   git stash push -u -m "before agent task"

2. Pracuj na gałęzi, nigdy na main. Jeśli zadanie ma być odizolowane od twojego edytora, użyj worktree Cursora, w którym agent pracuje w osobnym checkoucie gita.

3. Zapisz reguły pracy z gitem w regułach projektu (albo w AGENTS.md, który Cursor też czyta), żeby agent miał je w kontekście: nigdy nie rób force-pusha, nigdy nie przepisuj historii, która jest już na zdalnym repozytorium, nigdy nie commituj plików pasujących do .env* i zapytaj przed git reset --hard.

4. Na razie zostaw push człowiekowi. Agent commituje lokalnie, a ty pushujesz po sprawdzeniu wyników opisanych niżej.

Uwaga

git reflog cofa wszystko, co agent zrobi lokalnie, bo git zapisuje tam każde przesunięcie HEAD. Nie odzyska jednak zmian, które nigdy nie zostały zacommitowane ani odłożone do stasha. Dlatego krok 1 jest pierwszy.

Pisz wiadomości commitów na podstawie zmian w stagingu

Wiadomość commita to jedyny kontekst, jaki współpracownik będzie miał, gdy za pół roku trafi na twoją zmianę w konflikcie. Agent pisze dobre wiadomości, jeśli każesz mu czytać wyłącznie zmiany w stagingu i trzymać się konwencji zespołu. Bez tej instrukcji zwykle opisuje całe drzewo robocze, łącznie z edycjami spoza stagingu.

Prompt do skopiowania: wiadomość commita ze zmian w stagingu

Write a commit message for the changes that are staged right now. Read them with
`git diff --cached` only; ignore unstaged and untracked files.

Follow Conventional Commits (feat, fix, refactor, test, docs, chore) with a scope
taken from the top-level directory that changed. Subject line: imperative mood,
at most 72 characters. Body: explain WHY the change was needed and any behaviour
a reviewer should know about, not a list of files.

If the staged changes mix unrelated concerns, do not write one message. Tell me
how to split them into separate commits instead. Show me the message before you
run `git commit`.

Wynik sprawdzisz w pięć sekund, bez ponownego czytania diffa: uruchom git diff --cached --stat i upewnij się, że każdy obszar wymieniony w wiadomości jest na liście plików, a na liście nie ma niczego, czego wiadomość nie opisuje.

Rozwiązuj konflikty merge, nie tracąc żadnej ze stron

Ogólna prośba „napraw te konflikty” zwykle kończy się tym, że agent wybiera jedną stronę i usuwa znaczniki. Konflikt znika, a razem z nim zmiana innej osoby z zespołu. Poniższy prompt zmusza agenta, żeby najpierw nazwał intencję każdej strony i zatrzymał się, gdy te intencje się wykluczają.

1. Rozpocznij merge i wypisz pliki z konfliktami:

   git merge origin/main
   git diff --name-only --diff-filter=U

2. Przekaż agentowi poniższy prompt z wklejoną listą plików.

3. Kiedy agent skończy, uruchom testy i sprawdzanie typów, zanim zacommitujesz. Rozwiązanie, które się kompiluje, ale nie przechodzi testu, zgubiło jakieś zachowanie.

4. Zacommituj merge, a potem obejrzyj tylko to, co zrobiło rozwiązanie konfliktu:

   git show --remerge-diff HEAD

   --remerge-diff wymaga Gita 2.36 lub nowszego; wersję sprawdzisz przez git --version. To polecenie pokazuje różnicę między stanem z konfliktem (ze znacznikami <<<<<<<) a tym, co trafiło do commita, więc przeglądasz decyzje, a nie całe pliki. Przy rebase zamiast merge git range-diff origin/main ORIG_HEAD HEAD porównuje twoje commity sprzed rebase i po nim.

Prompt do skopiowania: rozwiąż konflikt merge i zachowaj obie intencje

These files have merge conflicts between my branch and origin/main:
<paste the output of git diff --name-only --diff-filter=U>

For each conflict hunk:
1. State in one line what each side changed and why. Use `git log -p` on the
   file for both branches if the intent is not obvious from the code.
2. Write a resolution that keeps BOTH intents where they are compatible. Never
   drop a side silently, and never use `git checkout --ours` or `--theirs` on a
   whole file.
3. If the two sides are incompatible (for example, both change the same
   function's return type), stop and ask me which behaviour should win.

When every file is resolved, run the test suite and the type check, report the
results, and list each hunk with the side(s) you kept. Do not commit.

Najważniejsza jest linia „stop and ask”. To ona odróżnia merge, któremu możesz zaufać, od takiego, w którym agent usunął poprawkę innej osoby z zespołu, żeby pozbyć się znaczników.

Otwórz pull request, na podstawie którego recenzent może działać

Opis PR-a napisany na podstawie diffa powtarza diff. Użyteczny opis podaje problem, dowód, że poprawka działa, i miejsce, gdzie jest ryzyko. Żeby agent sam otworzył pull request, podłącz serwer MCP GitHuba (konfiguracja w MCP w Cursorze) albo zainstaluj GitHub CLI (gh) i zaloguj się raz. Pierwszy fragment to wpis zdalnego serwera MCP GitHuba dla Cursora (z osobistym tokenem dostępu), drugi loguje gh:

~/.cursor/mcp.json

{ "mcpServers": { "github": {
  "url": "https://api.githubcopilot.com/mcp/",
  "headers": { "Authorization": "Bearer YOUR_GITHUB_PAT" } } } }

gh auth login

Prompt do skopiowania: opis PR-a gotowy do przeglądu

Open a pull request from this branch into main. Base the description on the
commit messages in `git log origin/main..HEAD` and on the test results you get
by running the test suite now. The description must have these sections:

- Summary: one paragraph on the problem this solves and the approach, not a
  list of files.
- Evidence: the exact test and type-check commands you ran and their results.
  If anything failed, say so and do not open the pull request.
- How to verify: the steps a reviewer runs to see the new behaviour.
- Risk: anything that touches authentication, payments, database migrations,
  or a public API. Write "None identified" only if you checked all four.

Keep it under 250 words and link issue #234.

Sekcja Evidence pozwala recenzentowi zaufać zmianie bez ponownego uruchamiania wszystkiego. Pełny kontrakt dla pull requestów od agenta, z wynikami kryteriów akceptacji i klasą ryzyka, opisuje strona pakiet dowodów.

Przejrzyj pull request współpracownika z pomocą agenta

Agent przydaje się w przeglądzie najbardziej, zanim przeczytasz jakikolwiek kod: buduje model mentalny zmiany, wskazuje ryzykowne fragmenty i znajduje brakujące testy. Decyzję o akceptacji nadal podejmujesz ty. Najpierw pobierz PR do lokalnej gałęzi, żeby agent pracował na prawdziwych plikach:

git fetch origin pull/123/head:pr-123
git diff --stat origin/main...pr-123

Prompt do skopiowania: wstępny przegląd cudzego PR-a

Review the changes in `git diff origin/main...pr-123`. Do not edit any files.

1. In five sentences or fewer, explain what the change does and how data flows
   through it.
2. List the hunks I must read myself, ranked by risk: authentication and
   authorization, input validation, error handling that swallows exceptions,
   database queries, and concurrency. Give file and line for each.
3. List behaviour the change introduces that no test covers, and name the test
   you would add.
4. Check out pr-123 in a separate worktree, run the test suite there, and
   report the result.

Do not comment on style that our linter already enforces.

Przeczytaj fragmenty z punktu 2 i listę brakujących testów z punktu 3, a potem zaakceptuj zmianę albo poproś o poprawki. Głębszy proces przeglądu, z osobnym przejściem dla każdego problemu i dużymi refaktoryzacjami, opisuje strona code review w Cursorze.

Gdzie w przeglądzie mieści się Bugbot?

Bugbot to recenzent pull requestów od Cursora: według dokumentacji „reviews pull requests and identifies bugs, security issues, and code quality problems” (cursor.com/docs/bugbot, sprawdzone 2026-08-28). Działa po twoim pushu na platformie, która hostuje repozytorium, więc łapie to, co przepuściły lokalne kontrole, a nie je zastępuje. Strony pomocy Cursora, według streszczenia z 2026-08-28 (od tamtej pory niesprawdzonego ponownie), opisują też plik .cursor/BUGBOT.md na wskazówki do przeglądu specyficzne dla projektu oraz komentarz bugbot run, który uruchamia przegląd ponownie. Konfigurację, wyuczone reguły i Autofix omawia strona o Bugbocie.

Żeby obsłużyć uwagi Bugbota w jednym przejściu, przekaż agentowi komentarze, zamiast je przepisywać:

Prompt do skopiowania: obsłuż uwagi Bugbota

Read the inline review comments on pull request #123 with
`gh api --paginate repos/{owner}/{repo}/pulls/123/comments`, and the review
summaries with `gh pr view 123 --comments`. Bugbot posts its findings inline, so
the first command is the one that returns them.
For each Bugbot finding: fix it if it is correct, or explain in one line why it
is a false positive. Run the tests after all fixes and show me the diff. Do not
push.

Uwaga

Jeśli ustawisz check Bugbota jako wymagany w ochronie gałęzi, sprawdź, jaki status zgłasza, gdy znajdzie problemy. Wymagany check, który przechodzi mimo otwartych uwag, uruchamia się przy każdym PR-ze i żadnego nie blokuje.

Rozdziel równoległą pracę między worktree i agentów w chmurze

Dwa niezależne zadania nie muszą na siebie czekać. Lokalne worktree daje każdemu agentowi osobny checkout na twojej maszynie. Agent w chmurze działa w odizolowanej maszynie wirtualnej i można go uruchomić z edytora albo przez automatyzację (Cursor Automations), na przykład po nowej wiadomości na Slacku. W obu przypadkach każde zadanie kończy się na osobnej gałęzi, gotowej do pull requestu, i przechodzi te same kontrole. Pilnuj, żeby zadania były naprawdę niezależne: dwóch agentów edytujących ten sam moduł wyprodukuje konflikt z poprzedniej sekcji, który rozwiążesz później, mając mniej kontekstu. Konfigurację worktree i uruchomienia równoległe opisuje strona checkpointy i gałęzie.

Jak udowodnić, że praca agenta z gitem jest poprawna?

Nie czytasz ponownie każdej linii. Każdy artefakt ma kontrolę, która odpowiada na jedno pytanie, i konkretną osobę, która go zatwierdza.

Artefakt	Kontrola	Zatwierdza
Wiadomość commita	git diff --cached --stat zgadza się z obszarami wymienionymi w wiadomości	Autor
Rozwiązanie konfliktu	Testy i sprawdzanie typów przechodzą, a git show --remerge-diff HEAD pokazuje każdą decyzję	Autor
Rebase	git range-diff origin/main ORIG_HEAD HEAD nie pokazuje niezamierzonych zmian w twoich commitach	Autor
Pull request	CI na zielono, a sekcja Evidence wymienia uruchomione polecenia i ich wyniki	Autor, potem recenzent
Przegląd PR-a współpracownika	Fragmenty uszeregowane według ryzyka i lista brakujących testów zostały przeczytane	Recenzent (człowiek) akceptuje
Przegląd po pushu	Uwagi Bugbota poprawione albo wyjaśnione	Autor

Co się psuje, gdy agent pracuje z gitem

• Merge „rozwiązany” przez wyrzucenie zmiany innej osoby z zespołu. Przed commitem uruchom git merge --abort i zacznij od nowa z promptem do konfliktów. Po commicie, ale przed pushem, git reset --hard ORIG_HEAD przywraca stan sprzed merge; to polecenie usuwa commit merge, więc najpierw sprawdź git log -1 ORIG_HEAD.
• Agent zacommitował coś niechcianego. Znajdź ostatni dobry wpis przez git reflog, a potem git reset --soft HEAD@{1} (albo SHA z reflogu) cofnie commity i zostawi zmiany w stagingu.
• Wiadomość commita opisuje zmiany spoza stagingu. Agent przeczytał git diff zamiast git diff --cached. Uruchom ponownie prompt do wiadomości commitów, który wprost nazywa to polecenie.
• Sekret albo plik .env trafił do commita. Jeśli nie był pushowany, usuń go przez git rm --cached .env, dodaj wzorzec do .gitignore i popraw commit (--amend). Jeśli był pushowany, najpierw unieważnij sekret; przepisanie historii nie usunie go z klonów i forków.
• Agent zrobił force-pusha na wspólną gałąź. Każdy, kto ma jeszcze stary wierzchołek gałęzi, może go przywrócić. Poproś tę osobę, żeby znalazła go w swoim git reflog jako <old-sha> i wypchnęła z powrotem przez git push --force-with-lease=<branch>:<bad-sha> origin <old-sha>:<branch>, gdzie <bad-sha> to wierzchołek wypchnięty przez agenta. Dzięki --force-with-lease push się nie powiedzie, jeśli ktoś w międzyczasie wypchnął coś nowego. Potem dopisz „never force-push” do reguł projektu i zabezpiecz gałąź na platformie.
• Agent ignoruje twoje reguły dotyczące gita. Zanim na nich polegasz, sprawdź, czy naprawdę wczytują się w sesji, i pamiętaj, że reguły działają tylko w Agencie, a nie w uzupełnianiu Tab, Inline Edit ani w przeglądach PR przez Bugbota (pomoc Cursora, sprawdzone 2026-10-12). Sposób sprawdzenia opisuje strona współpraca zespołowa w Cursorze.

Co dalej z pracą zespołową w Cursorze

Współpraca zespołowa w Cursorze Commituj wspólne reguły, konfigurację MCP i skille, żeby agent każdego członka zespołu działał tak samo.

Code review w Cursorze Samodzielny przegląd przed PR-em, jedno przejście na każdy problem i reguły przeglądu dla zespołu.

Checkpointy i gałęzie Worktree, uruchomienia równoległe i rytm commitów przy pracy z agentem.

Pakiet dowodów Co pull request od agenta musi udowodnić, zanim przejrzy go człowiek.

Kontrola wersji w Claude Code Ta sama pętla pracy z gitem w terminalu, dla zespołów, które używają też Claude Code.

Integracja Codexa z GitHubem Jak Codex łączy się z GitHubem przy pull requestach i przeglądach.