Git Mirror Clone
Kısaca: Bir Git deposunun tüm dalları, etiketleri ve eksiksiz commit geçmişi dahil tam bir kopyası — içinde çalışmak için normal bir checkout değil.
Biraz daha ayrıntılı: git clone --mirror <url> bir “bare” depo oluşturur (çalışma dizini yok, yalnızca .git klasörü). Ardından git push --mirror <yeni-url>, eksiksiz geçmişi 1:1 yeni bir hedef depoya aktarır. Gerçekten çalışmaya devam etmek için sonrasında yeni deponun normal bir git clone’una yine ihtiyacınız vardır — ayna klasörü yalnızca bir ara adımdır.
Ayrıntılı
Eksiksiz yöntem
Ayna klonuyla bir depo taşımanın eksiksiz yöntemi üç adımdan oluşur:
git clone --mirror https://github.com/old-account/projekt.git
cd projekt.git
git push --mirror https://github.com/own-account/emzett.git
git clone https://github.com/own-account/emzett.git“Bare depo”nun somut olarak anlamı
Normal klonlanmış bir depo iki parçadan oluşur: .git klasörü (tüm geçmiş/üst veri) ve bir çalışma dizini (düzenlediğiniz, gerçekten checkout edilmiş dosyalar). --mirror ile oluşturulan “bare” depo YALNIZCA .git içeriğinden oluşur, çalışma dizini yoktur — yani doğrudan çalışabileceğiniz hiçbir checkout edilmiş dosya yoktur. Bu bilinçlidir: bare depo salt bir veri kapsayıcısıdır, ara istasyon veya push hedefi olarak düşünülmüştür, doğrudan düzenleme için değil. Bu, ayna push’undan sonra yeni deponun normal bir git clone’una neden hâlâ ihtiyaç duyulduğunu da açıklar.
Normal klon + push’tan farkı
Normal bir git clone + git push’tan belirleyici fark: normal bir klon da o an checkout edilen dalın tam geçmişini getirir, ancak diğer tüm dalları/etiketleri otomatik olarak DEĞİL; normal bir push da tüm başvuru ağını değil, yalnızca geçerli dalı aktarır. Bir depo taşırken ise (günlük işten farklı olarak) gerçekten her şeyi 1:1 almak istersiniz, kendiniz hiç checkout etmemiş olabileceğiniz dallar dahil — eski özellik dalları veya tam geçmiş için önemini koruyan geçmiş sürümlerin etiketleri gibi.
Neler GELMEZ
Depo taşırken kolayca gözden kaçan önemli bir nokta: ayna klonu eksiksiz Git geçmişini aktarır, ancak GitHub sorunları (issues), çekme istekleri, wiki sayfaları, sürümler (Git etiketleri olarak değil, GitHub nesneleri olarak) veya depo ayarları (dal koruma kuralları, webhook’lar, yapılandırılmış sırlar) gibi platforma özgü üst verileri DEĞİL. Bunlar saf Git nesne modelinin dışında, GitHub’ın kendi veritabanında yaşar ve gerçek bir platform taşımasında ayrıca taşınmalı veya yeniden kurulmalıdır.
Ayna push’u sırasında kimlik doğrulama
Bir ayna push’u potansiyel olarak çok sayıda başvuruyu bir kerede aktardığından, büyük depolarda özellikle kimlik doğrulama sorunlarına yatkındır — süresi dolmuş bir belirteç veya yanlış yapılandırılmış bir SSH bağlantısı çoğunlukla ancak aktarımın ortasında hata verir ve bu, hedef depoyu eksik bir ara durumda bırakabilir. Bu yüzden eski depoyu silmeden veya arşivlemeden önce, bir ayna push’undan sonra hedef depodaki dal/etiket sayısını orijinalle karşılaştırmak önerilir.
Ayrıca bak: SSH anahtarı (Git kimlik doğrulaması), Git