Przenosisz repozytorium? Mirror zachowa kod, ale nie zastąpi transferu GitHuba

Jeśli repozytorium ma zmienić właściciela w obrębie GitHub.com, wybierz transfer. Zachowuje on historię commitów, zgłoszenia, pull requesty, forki i gwiazdki, a dokumentacja transferu GitHuba opisuje przekierowanie starych adresów repozytorium. To sposób na przeniesienie działającego projektu wraz z jego historią współpracy.

Jeśli potrzebujesz osobnej kopii kodu z pełną historią Git, gałęziami i tagami, wykonaj mirror. Instrukcja tworzenia kopii lustrzanej podaje także osobne polecenia dla obiektów Git LFS. Kopia Git nie przenosi zgłoszeń, pull requestów ani ustawień repozytorium zapisanych przez platformę.

Transfer czy mirror: co zostaje po przenosinach?

Wybór zależy od tego, czy nowe miejsce ma przejąć cały projekt na GitHubie, czy tylko jego historię wersjonowania. Commity i odwołania do gałęzi oraz tagów należą do Git; zgłoszenia, dyskusje w pull requestach i gwiazdki są powiązane z usługą hostingową.

• Kod i historia: transfer zmienia właściciela istniejącego repozytorium. Mirror wysyła jego historię Git do odrębnego repozytorium.
• Gałęzie i tagi: pozostają w repozytorium po transferze. Klon lustrzany obejmuje zdalne gałęzie i tagi dostępne w źródle.
• Zgłoszenia i pull requesty: transfer zachowuje je wraz z repozytorium; mirror nie tworzy ich odpowiedników w miejscu docelowym.
• Forki i gwiazdki: ich powiązania pozostają przy transferze. Utworzenie nowej kopii Git nie odtwarza tych relacji.
• Stare adresy: transfer zapewnia przekierowania dla repozytorium i operacji Git. Mirror tworzy drugi adres, więc odnośniki do źródła nadal prowadzą do źródła.
• Git LFS: przy transferze obiekty są przenoszone w tle. Przy mirrorze trzeba pobrać je i wysłać osobno.

Transfer działa między właścicielami na GitHub.com. Gdy repozytorium ma trafić do innego dostawcy albo istnieć równolegle w dwóch miejscach, wybierz kopię lustrzaną. Jeżeli w takim przypadku potrzebujesz również zgłoszeń i pull requestów, zaplanuj ich migrację oddzielnie według możliwości obu usług.

Jak wykonać transfer na GitHubie

Osoba przenosząca repozytorium potrzebuje dostępu administracyjnego. Przy transferze do organizacji musi mieć też uprawnienie do tworzenia w niej repozytoriów; polityka organizacji może dodatkowo ograniczać przenosiny. Na koncie docelowym nie może już istnieć repozytorium o tej samej nazwie ani fork należący do tej samej sieci.

1. Otwórz repozytorium, przejdź do Settings i na dole strony wybierz Transfer w sekcji Danger Zone.
2. Wskaż nowego właściciela, przeczytaj ostrzeżenia dotyczące planu docelowego, wpisz nazwę repozytorium w polu potwierdzenia i zatwierdź transfer.
3. Jeśli celem jest inne konto osobiste, jego właściciel musi zaakceptować zaproszenie przesłane e-mailem. Zaproszenie wygasa po jednym dniu.

Zmiana właściciela nie usuwa historii commitów, wiki, obserwujących ani powiązań z forkami. Webhooki, sekrety i klucze wdrożeniowe pozostają przypisane do repozytorium. Obiekty Git LFS przenoszą się automatycznie w tle, więc przy dużych plikach albo licznych obiektach może minąć trochę czasu, zanim wszystkie będą dostępne.

Po przeniesieniu do organizacji zaczynają obowiązywać jej domyślne ustawienia uprawnień. Zależnie od kierunku transferu niektóre przypisania zgłoszeń zostaną usunięte; na przykład przy przeniesieniu z konta osobistego do organizacji pozostają przypisania do jej członków. Prywatne repozytorium przeniesione na konto GitHub Free może też stracić dostęp do ochrony gałęzi i GitHub Pages. Te skutki warto uwzględnić przed zatwierdzeniem operacji.

Jak skopiować historię Git i obiekty LFS

Do jednorazowej kopii przygotuj puste repozytorium docelowe oraz adresy źródła i celu. W poniższych poleceniach ADRES_ZRODLA i ADRES_CELU oznaczają rzeczywiste adresy Git, a repo.git jest nazwą lokalnego katalogu. Polecenia LFS wykonaj wtedy, gdy projekt używa Git Large File Storage.

1. Pobierz historię: git clone --bare ADRES_ZRODLA repo.git
2. Wejdź do lokalnego klonu: cd repo.git
3. Pobierz obiekty LFS: git lfs fetch --all
4. Wyślij historię i odwołania Git: git push --mirror ADRES_CELU
5. Wyślij obiekty LFS: git lfs push --all ADRES_CELU

Zwykły push historii Git może zakończyć się powodzeniem, choć zawartość dużych plików nie została jeszcze przesłana. W commitach znajdują się wtedy wskaźniki LFS, dlatego po migracji sprawdź zarówno gałęzie i tagi, jak i możliwość pobrania samych plików. Repozytorium docelowe powinno być puste: wysłanie z opcją --mirror synchronizuje odwołania z klonu i może usunąć odwołania istniejące wyłącznie po stronie celu.

Jeśli kopia ma być regularnie aktualizowana, zacznij od git clone --mirror ADRES_ZRODLA repo.git. W utworzonym katalogu ustaw osobny adres wysyłania poleceniem git remote set-url --push origin ADRES_CELU. Następne synchronizacje wykonuj przez git fetch -p origin oraz git push --mirror; dla projektu z LFS dodaj git lfs fetch --all i git lfs push --all ADRES_CELU. Pobieranie w takim klonie nadpisuje lokalne odwołania stanem źródła, więc nie jest to miejsce na niezależne zmiany.

Co sprawdzić po migracji

Po transferze przekierowania starego adresu obejmują ruch Git i HTTP do repozytorium. Mimo to zmień adres origin w lokalnych klonach poleceniem git remote set-url origin NOWY_ADRES i popraw adresy zapisane w automatyzacji. Utworzenie repozytorium lub forka pod dawną ścieżką trwale usuwa przekierowania; witryna GitHub Pages powiązana z projektem również nie korzysta z przekierowania repozytorium.

• Dostęp: przejrzyj współpracowników, zespoły, przypisania zgłoszeń i uprawnienia wynikające z ustawień nowej organizacji.
• Integracje: sprawdź działanie webhooków i kluczy wdrożeniowych oraz wartości sekretów używanych przez automatyzację. Ich zachowanie przy transferze nie oznacza, że zewnętrzny odbiorca poprawnie obsłuży nowy adres.
• Reguły pracy: sprawdź ochronę gałęzi i wymagane kontrole przed scaleniem zmian, szczególnie po zmianie planu konta lub polityki organizacji.
• Zawartość: porównaj gałęzie i tagi z repozytorium źródłowym. Po wykonaniu mirrora sprawdź dodatkowo pliki LFS; zgłoszenia i pull requesty wymagają wtedy osobnej migracji.

Jeżeli celem są przenosiny projektu z zachowaniem dyskusji i starych odnośników, użyj transferu między właścicielami na GitHubie. Gdy potrzebna jest niezależna kopia historii wersjonowania, wykonaj mirror i uwzględnij osobno obiekty LFS oraz dane zapisane poza Git.

Przeczytaj także:

• Cursor czy GitHub Copilot? Tańszy plan nie zawsze oznacza tańsze agenty
• GitHub Actions czy GitLab CI? Darmowe minuty nie pokazują kosztu zespołu
• Jak wyłączyć trenowanie AI na czatach — historia nie zawsze znika