Pomyśl o tym jak o trzech pudełkach. Cursor to miejsce, gdzie edytujesz stronę. GitHub to bezpieczna kopia z historią zmian. Vercel to publiczna wersja, którą ludzie otwierają w przeglądarce. Jeśli te trzy miejsca są uporządkowane, możesz zmieniać stronę bez strachu, że ją stracisz.
Co będziesz mieć
- Repozytorium GitHub, które bezpiecznie przechowuje stronę
- Projekt Vercel z działającym publicznym adresem
- Jasna lista prywatnych ustawień, np. kluczy formularza lub tokenów mailowych
- Prosty rytm zmian: edycja, zapis, publikacja, kontrola
- Ścieżka powrotu, jeśli nowa wersja zepsuje stronę
● Kroki
Od Cursora do działającej strony: GitHub i Vercel bez paniki
Przygotuj projekt przed publikacją
Otwórz stronę w Cursorze i sprawdź, czy działa lokalnie. Komendę znajdziesz w package.json, najczęściej npm run dev. Otwórz lokalny adres w przeglądarce i przejdź przez najważniejsze podstrony. Efekt: wiesz, że projekt nie był zepsuty jeszcze przed GitHubem i Vercel.
Utwórz repozytorium GitHub
Wejdź na GitHub, utwórz nowe repozytorium i nadaj mu prostą nazwę, np. bakery-website albo clinic-site. Jeśli projekt nie jest gotowy, ustaw repozytorium jako prywatne. Efekt: masz puste miejsce online, gdzie strona będzie zapisana razem z historią zmian.
Zapisz pierwszą wersję kodu
W Cursorze otwórz panel Source Control albo terminal. Dodaj pliki, wpisz krótki opis typu first working version i wyślij kod do GitHuba. Nie mieszaj pierwszego zapisu z dziesięcioma eksperymentami. Efekt: GitHub ma ten sam projekt, który jest na Twoim komputerze.
Zaimportuj repozytorium do Vercel
Otwórz Vercel, wybierz Add New Project, wskaż repozytorium z GitHuba i pozwól Vercel rozpoznać typ projektu. Przed kliknięciem Deploy sprawdź komendę budowania i ustawienia, które pokazuje Vercel. Efekt: Vercel buduje stronę z GitHuba, a nie z Twojego laptopa.
Dodaj prywatne ustawienia w Vercel
Jeśli strona ma formularz, wysyłkę maili, analitykę albo płatne API, dodaj te klucze w Vercel Project Settings -> Environment Variables. Nigdy nie wklejaj prywatnych kluczy do zwykłych plików z kodem. Efekt: publiczna strona może używać prywatnych usług, ale odwiedzający nie widzą sekretów.
Sprawdź live URL jak klient
Otwórz adres z Vercel na telefonie i komputerze. Sprawdź menu, przyciski, formularz, komunikat po wysłaniu, ogólne wrażenie szybkości i oczywiste literówki. Wyślij testowy formularz do siebie. Efekt: potwierdzasz, że strona działa dla realnego odwiedzającego, nie tylko w Cursorze.
Używaj bezpiecznego rytmu zmian
Przy każdej kolejnej zmianie: edytuj w Cursorze, sprawdź lokalnie, zapisz mały commit, wyślij do GitHuba, poczekaj na preview w Vercel i dopiero potem sprawdź produkcję. Jeśli nowa wersja coś zepsuje, otwórz Vercel Deployments i przywróć poprzedni działający deployment. Efekt: możesz rozwijać stronę bez zgadywania, jak ją uratować.
Typowe problemy
- Trzymanie jedynej kopii projektu tylko w Cursorze albo folderze Downloads
- Publikacja przed sprawdzeniem, czy strona działa lokalnie
- Wklejanie prywatnych kluczy bezpośrednio do plików z kodem
- Zmiana ustawień w Vercel bez zapisania, co zostało zmienione
- Brak testu formularza po deployu
- Robienie ogromnych mieszanych commitów, których trudno cofnąć
Deployment stoi albo stresuje?
Wyślij link do GitHuba, screenshot projektu Vercel i live URL. Sprawdzę, gdzie pęka łańcuch, i zostawię Ci powtarzalny sposób publikacji.
- Build failuje i błąd jest niejasny
- Brakuje environment variables albo są zdublowane
- Live strona działa inaczej niż w Cursorze
- Potrzebujesz bezpiecznego rollbacku przed zmianą produkcji
● Powiązane poradniki
Powiązane poradniki
Nie chcesz płacić za stronę? Zrób ją samodzielnie.
Praktyczna ścieżka od pomysłu do live strony: AI-assisted coding, GitHub, Vercel, domena, formularz i podstawy SEO.
TAPE-03Prompty do Cursora, które nie robią śmieci
Struktura promptu dla stron małych firm: kontekst, sekcje, ograniczenia, testy i pętla edycji.
TAPE-04Dlaczego strony AI wyglądają jak tanie demo
Powtarzalny wzorzec porażki: sztuczny copy, słaba oferta, zepsuty mobile, brak formularzy i indeksacji.