Samouczek Cursor Origin: konfiguracja CLI, mirroring GitHub i pull requesty

Czym jest Cursor Origin?

Cursor Origin to forż Git. Hostuje repozytoria, tworzy mirrory projektów z GitHuba i obsługuje pull requesty oraz przeglądanie kodu. Repozytoria Origin współpracują też z chmurowymi agentami i automatyzacjami Cursor.

Czym różni się Cursor Origin od GitHuba?

Origin nie obejmuje wszystkich funkcji GitHuba. Publiczne repozytoria nie są udokumentowane, a mirrory wykluczają Issues GitHuba, workflowy GitHub Actions i sekrety Actions. GitHub pozostaje szerszą platformą dla publicznych repozytoriów, Issues, Actions i aplikacji zewnętrznych, więc dziś Origin jest usługą o węższym zakresie.

Główna różnica kryje się pod znajomym workflowem Git: Cursor zbudował osobną warstwę przechowywania dla wolumenu gałęzi i commitów produkowanych przez agentów. Cursor nazywa to „skalą agentową” (agent scale): obciążenia, w których wielu agentów rozgałęzia, commituję i otwiera pull requesty względem tego samego repozytorium.

Dlaczego Cursor zbudował własny host Git?

Projekt pamięci wyjaśnia, dlaczego Cursor zbudował nowy host Git zamiast dodać kolejny interfejs do istniejącego.

W poście inżynierskim Cursor o Continuity opisuje istniejące hosty Git jako trzymające repozytorium na kilku serwerach i finalizujące push po uzyskaniu większości. Cursor twierdzi, że ten model kosztuje więcej, gdy system ma tysiące krótkotrwałych repozytoriów lub częste pushe do jednego repozytorium.

Jak działa pamięć Continuity w Cursor Origin?

Continuity, czyli „Cnt”, to system przechowywania stojący za Origin. Przechowuje dziennik write-ahead w zgodnej z S3 pamięci obiektowej jako źródło prawdy. Lokalny repozytorium Git na dysku to ciepła pamięć podręczna, którą można odtworzyć z dziennika.

Continuity przechowuje zapisy Gita jako obiekty. Obraz: autor.

Ponieważ dziennik obiektów jest faktycznym rejestrem, Cursor może dodawać repliki odczytu dla obciążonych repozytoriów i usuwać je, gdy popyt spada. W testach Cursor przepustowość odczytu rosła wraz z replikami, do 100 replik. System obsłużył do 120 pushy na sekundę na standardowym S3, ale te liczby nie były zweryfikowane niezależnym benchmarkiem.

Dla użytkownika efekt jest prostszy: obciążone repozytorium może zyskać większą przepustowość odczytu, a krótkotrwałe repo nie potrzebuje stałej lokalnej kopii na każdym serwerze.

Kto ma dostęp do Cursor Origin?

Origin jest dostępny w planach Pro, Teams i Enterprise, ale nie w planie darmowym. Dostęp jest wdrażany etapami, więc kwalifikujący plan nie gwarantuje natychmiastowego pojawienia się zakładki Codebase. Na Pro masz własną przestrzeń nazw i samodzielnie rezerwujesz nazwę bazy kodu.

Administratorzy Enterprise mogą ją wyłączyć dla organizacji. W przeglądzie Cursor jest mowa, że każdy członek zespołu może zarezerwować pierwszą nazwę bazy kodu, podczas gdy strona Codebase Settings mówi, że musi to zrobić admin zespołu. Sprawdź to uprawnienie w swoim zespole przed konfiguracją.

Czym jest CLI Cursor Origin?

Origin dostarcza własne narzędzie wiersza poleceń do uwierzytelniania, repozytoriów, pull requestów i konfiguracji konta.

Cursor Origin CLI vs. Cursor Agent CLI

CLI Origin to osobny plik binarny, origin, od CLI Agenta Cursor, który działa jako agent. 

Łatwo pomylić te nazwy, bo origin to też zwyczajowa nazwa zdalnego repo w Gicie. W tym artykule „push do origin” oznacza zdalne repo Git, a „uruchom origin” oznacza CLI.

Na jakich platformach działa Origin CLI?

Cursor dokumentuje macOS, Linuksa i Windows przez WSL. W czasie mojego testu Windows oznaczał WSL, bo nie było natywnego instalatora.

Jeśli działasz na Windowsie, przed instalacją CLI otwórz terminal Ubuntu. Uruchomienie instalatora powłoki w PowerShellu to inna konfiguracja.

Polecenia Cursor Origin CLI

CLI Cursor Origin ma obecnie dziewięć grup poleceń.

Większość poleceń repozytoryjnych odczytuje cel ze zdalnego Git o nazwie origin. Opcja -R owner/repo ustawia cel bezpośrednio, co przydaje się w skrypcie działającym na kilku repozytoriach. Polecenia ruleset tylko wyświetlają istniejące reguły pusha i merge; nie zmieniają ich.

Jak zainstalować i zalogować się do Cursor Origin CLI

Cursor udostępnia CLI przez skrypt powłoki, a nie menedżera pakietów. Polecenie pochodzi ze strony instalacyjnej Cursor install page.

Jak zainstalować Cursor Origin CLI

Instalacja sprowadza się do jednej linijki:

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh

Instalator umieścił origin w ~/.local/bin/origin. Jeśli wasz zespół przegląda skrypty przed uruchomieniem, pobierz skrypt najpierw zamiast przekierowywać go prosto do sh.

Naprawa błędu „command not found” dla Origin CLI

Jeśli twoja powłoka nie znajduje origin po instalacji, dodaj jego katalog do PATH:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Zamień ~/.zshrc na ~/.bashrc na bashu. To jednorazowa poprawka na maszynę.

Sprawdzenie instalacji i logowania

Uruchom origin --version i origin --help, by potwierdzić instalację, a następnie użyj origin auth login, aby otworzyć logowanie przez przeglądarkę Cursor.

Tak wyglądał wynik weryfikacji w WSL:

Wersja i pomoc CLI Origin. Obraz: autor.

W środowisku bezgłowym CLI wypisze zamiast tego URL. Logowanie konfiguruje też helper poświadczeń Gita, więc zdalne Origin działa bez osobnego tokena Git. Uruchom potem origin auth status, by sprawdzić sesję.

Użycie klucza API Cursor bez przeglądarki

Dla CI lub skryptów uruchom origin auth login --api-key <key> lub ustaw CURSOR_API_KEY przed origin auth login. Nie commituj klucza do repozytorium. CURSOR_AUTH_TOKEN to co innego i oczekuje tokena bearer.

Jak utworzyć, sklonować i wypchnąć repozytorium Cursor Origin

Po zalogowaniu możesz utworzyć repozytorium na stronie WWW lub przez CLI. Push korzysta ze standardowych poleceń Git.

Tworzenie repozytorium poleceniem origin repo create

Na cursor.com/codebase wybierz New, wpisz nazwę i wybierz widoczność Internal lub Private. 

Z CLI polecenie origin repo create my-project używa przestrzeni nazw twojego konta. Dodaj właściciela, np. origin repo create acme/my-project, aby użyć przestrzeni zespołu. Opcjonalna flaga --default-branch zmienia domyślną gałąź serwera z main.

Polecenie origin repo clone acme/my-project klonuje repo przez HTTPS z logowaniem zapisanym przez CLI.

Wypychanie pierwszego commita do Origin

Po pierwszym pushu repozytorium pojawi się w Codebase:

Repozytorium wypchnięte i widoczne w Codebase. Wideo: autor.

Dla zupełnie pustego, nowego repozytorium: sklonuj je, dodaj plik i wypchnij:

git clone https://origin.cursor.com/{owner}/{repo}.git
cd {repo}
echo "# {repo}" > README.md
git add .
git commit -m "Initial commit"
git push -u origin main

Jeśli Git zgłasza błąd uprawnień .git/config.lock pod /mnt w WSL, sklonuj pod ~ zamiast tego. To naprawiło błąd w moim teście.

Po pushu otwórz Codebase i sprawdź, czy commit się pojawił. Zakładka Code pokazuje drzewo plików i historię commitów. Naciśnij T aby Go to file, albo użyj pola wyszukiwania, by przeszukać kod.

Wypychanie istniejącego repozytorium Git do Origin

Jeśli masz już projekt z historią Gita, najpierw uruchom git remote -v. Poniższe polecenie dotyczy tylko sytuacji, gdy repozytorium nie ma jeszcze zdalnego o nazwie origin:

git remote add origin https://origin.cursor.com/{owner}/{repo}.git
git push -u origin main

Jeśli origin już wskazuje na GitHuba, użyj innej nazwy zdalnego, np. cursor, zamiast podmieniać istniejący URL. Polecenia Origin CLI nie wywnioskują repozytorium z tej nazwy, więc przekazuj -R owner/repo przy ich uruchamianiu.

Jak wykonać mirroring repozytorium GitHub w Cursor Origin

Mirror kopiuje istniejący projekt z GitHuba do Origin i utrzymuje połączenie między usługami.

Wymagania mirroringu GitHub w Cursor Origin

Potrzebujesz dostępu do Origin, aplikacji Cursor GitHub połączonej z organizacją lub kontem będącym właścicielem repozytorium oraz uprawnień administratora do tego repozytorium na GitHubie. Same uprawnienia zapisu nie wystarczą.

Rozpoczęcie mirroringu GitHub w Cursor Origin

Na cursor.com/codebase wybierz Sync from GitHub, wskaż organizację i repozytorium i potwierdź. Alternatywa w CLI to origin repo create-mirrored owner/repo, opisana w dokumentacji mirroringu.

Co Cursor Origin odzwierciedla z GitHuba

Origin odzwierciedla dane Gita, ale nie każdą funkcję GitHuba:

GitHub Actions nadal działają na GitHubie. Integracje Depot i Buildkite dotyczą repozytoriów hostowanych w Origin, a nie kopii w mirrorze.

Kiedy GitHub pozostaje źródłem prawdy

Gdy repozytorium jest w mirrorze, pushe przez Origin przechodzą na GitHuba. Detach from GitHub w ustawieniach repozytorium sprawia, że kopia w Origin staje się samodzielna, bez zmian w repozytorium GitHub.

Jak otworzyć i zrecenzować pull request w Cursor Origin

Pull requesty Origin używają tej samej sekwencji: gałąź, push, przegląd — jak na innych hostach Git. Nasz przewodnik po pull requestach wyjaśnia tę sekwencję.

Tworzenie gałęzi i wypchnięcie zmiany

Utwórz i wypchnij roboczą gałąź:

git checkout -b my-change
echo "Example change" >> README.md
git add README.md
git commit -m "Add example change"
git push -u origin my-change

Git zrobił swoje; następne polecenie należy do Origin.

Otwieranie pull requesta w Origin CLI

Polecenia repozytorium wnioskują cel ze zdalnego Git o nazwie origin. Uruchom origin pr create lub podaj -R owner/repo, aby ustawić repo bezpośrednio. Domyślnie polecenie tworzy draft; podaj --status open, aby od razu był gotowy do recenzji.

Recenzowanie pull requesta w Cursor Origin

CLI zawiera origin pr list, origin pr view, origin pr diff i origin pr checks. Bez skonfigurowanej aplikacji CI origin pr checks wypisało No checks reported. i zakończyło się kodem 1 w moim teście.

Ten kod wyjścia ma znaczenie w skryptach powłoki z set -e, bo pusta karta Checks może zatrzymać skrypt, mimo że sam pull request jest OK.

Recenzja pull requesta z czterema zakładkami. Obraz: autor.

W widoku WWW każdy pull request ma cztery zakładki: Activity, Commits, Checks i Files Changed, a także prośby o recenzję, komentarze w linii i przycisk merge. Strona WWW pokazuje konflikty scalania, a origin pr status --conflict-status raportuje je z terminala.

Terminal obsługuje też origin pr merge. Pull requesty utworzone w repo hostowanym w Origin pozostają w Origin, a aktywność w repo w mirrorze jest odsyłana do GitHuba.

Dostęp zespołu i uprawnienia repozytoriów w Cursor Origin

Uprawnienia Origin istnieją na poziomie codebase i repozytorium.

Ustawienia codebase vs. ustawienia repozytorium

Ustawienia codebase są zespołowe: kto może włączyć Origin, tworzyć repozytoria i instalować aplikacje. Ustawienia repozytorium dotyczą jednego repo i obejmują General, Permissions, Rules i Protections oraz Apps, choć dokumentacja Cursor ostrzega, że ekrany Permissions i Rules są w przebudowie.

Jeśli członek zespołu może używać Origin, ale nie może otworzyć jednego repozytorium, sprawdź uprawnienia tego repo, a nie ustawienia zespołowe.

Repozytoria Internal vs. Private

Są dwa typy repo z ograniczonym dostępem:

• Internal repositories są widoczne dla członków zespołu z dostępem do codebase. 
• Private repositories są widoczne tylko dla członków z dostępem nadanym bezpośrednio lub przez uprawnienia codebase. Przełączenie repozytorium na private zachowuje osobę zmieniającą jako admina.

Jak sprawdzić dostęp do repozytorium Cursor Origin

Polecenie origin repo list pokazuje każde repo widoczne dla bieżącego konta. Aby sprawdzić, kto ma dostęp do jednego repo, otwórz Settings, potem Permissions.

Najlepsze praktyki dla Cursor Origin

Trzy rzeczy są bardzo ważne, gdy pracujesz z Origin:

• Przed usunięciem lub zmianą konfiguracji repozytorium potwierdź pełną wartość owner/repo i sprawdź jego zdalne adresy.

• Unikaj -y, dopóki nie zweryfikujesz celu.

• Strony uprawnień Cursor są niespójne, więc sprawdzaj aktualną dokumentację przed automatyzacją zmian dostępu.

Cursor Origin vs. GitHub: porównanie funkcji

Origin jest powiązany z przepływem pracy agentów Cursor, podczas gdy GitHub obejmuje szerszy ekosystem repozytoriów.

Hosting Git, pull requesty i CI/CD

Zamiast powtarzać każdą sekcję, oto skrócona wersja podziału funkcji:

Wiersz o agentach wymaga kontekstu.

Cursor Origin vs. GitHub dla przepływów pracy agentów

Obie platformy pozwalają agentom pracować na repozytoriach. Origin utrzymuje tę pętlę w Cursorze; GitHub oferuje ją przez panel Agents i narzędzia Copilot, w tym dostępne ogólnie CLI.

Kiedy używać Cursor Origin, GitHuba lub obu

• Użyj Origin, gdy repozytorium jest internal lub private, większość pracy agentów i tak dzieje się w Cursorze, a wasze wdrożenia lub CI mogą działać przez Vercel, Depot lub Buildkite.
• Pozostań przy GitHubie jako głównym hoście, gdy projekt jest publiczny, Issues i Actions to codzienny workflow albo zespół polega na marketplace GitHuba.
• Użyj obu, gdy chcesz przeglądania kodu i przepływu pracy agentów Origin bez przenoszenia repozytorium źródłowego. Mirror utrzymuje push i aktywność PR powiązane z GitHubem, jednocześnie udostępniając ten sam kod w Origin.

Podsumowanie

Od świeżej instalacji WSL do otwartego pull requesta w Origin doszedłem używając tego samego przepływu gałąź–commit–push, co na GitHubie. CLI nie zmieniło sposobu działania Gita; różnice Origin dotyczyły hostingu, uprawnień i mirroringu.

Po użyciu potraktowałbym Origin jako uzupełnienie GitHuba, a nie pełne zastępstwo. Mirroring to najbardziej praktyczny punkt wejścia dla istniejącego repozytorium, bo GitHub może pozostać nadrzędny. Projekty publiczne i workflowy mocno oparte na Actions wciąż mają niewiele powodów do przenosin.

Powiązana lektura: nasz przewodnik po Cursor Automations obejmuje zadania agentów uruchamiane na istniejącym repozytorium. Nasz przewodnik czym jest GitHub i jak go używać wyjaśnia workflow GitHuba bardziej szczegółowo.