Repolarınızı Bozmadan Gitea'dan Forgejo'ya Nasıl Geçiş Yapılır

Gitea'yı durdurursunuz, Forgejo'yu kurarsınız, app.ini ve veri dizininizi kopyalarsınız ve hizmeti her taşıma rehberinin anlattığı şekilde başlatırsınız. Web arayüzü açılır. Sonra veritabanı taşıması başarısız olur ya da daha kötüsü, Forgejo şema sürümünüz anlayamayacağı kadar yeni olduğu için başlamayı reddeder. Gitea 1.23 veya sonrasındasınızdır ve herkesin belgelediği basit yerinde yükseltme artık sizin için geçerli değildir.

Forgejo, 2024 yılının başında Gitea'nın sert bir fork'u haline geldi ve iki proje o zamandan beri veritabanı şeması düzeyinde birbirinden ayrıldı. Gitea'yı Forgejo'ya nasıl taşıyacağınız artık tamamen Gitea sürümünüze bağlı. Bu rehber size sürümünüz için tam yolu, hem native hem de Docker kurulumları için eksiksiz komutları, Gitea 1.23+ için geçici çözümleri ve bir doğrulama kontrol listesi sunarak repoları, issue'ları veya kullanıcıları kaybetmeden geçiş yapmanızı sağlar.

Özetle

• Sürüm uçurumu gerçek. Forgejo v10.0, Gitea'dan şeffaf bir doğrudan yükseltmeyi destekleyen son sürümdü. Gitea v1.22, desteklenen doğrudan yolu izleyebilecek en yüksek sürümdür.
• Gitea v1.22 veya daha eski sürümde: önce Forgejo v10.0.x'e taşıyın, ardından Forgejo v10'u güncel sürüme (v15) yükseltin. İki sıçrama, ikisi de destekleniyor.
• Gitea v1.23 veya daha yeni sürümde: resmi olarak desteklenen doğrudan bir yol yok. SQL/şema düşürme, topluluk taşıma betikleri, depo/API taşıması veya bu yöntemlerden birini kullanan bir yeni sunucu hazırlama taşıması arasında seçim yaparsınız. Her birinin farklı bir veri kaybı ödünleşimi vardır.
• Herhangi bir şeye dokunmadan önce veri dizininizi ve veritabanınızı yedekleyin. Aşağıdaki her yol, geri yüklenebilir bir yedeğiniz olduğunu varsayar. Desteklenmeyen yollar bunu iki kat varsayar.
• Bazı şeyler her zaman taşıma sonrası dikkat gerektirir: Kişisel Erişim Belirteçlerini yeniden oluşturmayı veya denetlemeyi, Actions çalıştırıcılarını yeniden kaydetmeyi ve Bleve arama indeksini silip yeniden oluşturmayı planlayın. Hangi yolu izlerseniz izleyin bunları planlayın.
• Geçiş yapmak zorunlu değildir. Gitea aktif olarak geliştirilmeye devam ediyor. Geçiş riski, durumunuz için sağlayacağı faydadan ağır basıyorsa, "Gitea'da kal" kararı geçerliliğini korur.

Bu yazının kapsamı dışında: Gogs, GitHub veya GitLab'dan Forgejo'ya taşıma ve Forgejo Actions'ı sıfırdan kurma.

Ön Koşullar / İhtiyacınız Olacaklar

Tek bir komut bile çalıştırmadan önce, iki şeyin tam ve geri yüklenebilir bir yedeğine sahip olduğunuzu doğrulayın: Gitea veri dizininiz (varsayılan bir native kurulumda /var/lib/gitea) ve veritabanınız. Veritabanınız SQLite ise, bu dosya veri dizininin içinde bulunur; PostgreSQL veya MySQL ise, pg_dump veya mysqldump ile ayrı olarak dump alın. Doğrulanmış bir yedek olmadan yapılan bir geçiş, geçiş değil, kumardır.

Ayrıca ihtiyacınız olacak:

• Mevcut Gitea sürümünüz. Şunu çalıştırın: gitea --version (veya docker exec <container> gitea --version). Bu sayı, izleyeceğiniz tüm yolu belirler.
• Veritabanı türünüz: SQLite, PostgreSQL veya MySQL. Bazı geçici çözümler veritabanına özgüdür.
• Sunucuda root veya sudo erişimi.
• Desteklenen yolun, ara bir adım olarak Forgejo v10.0'ı kurduğunun farkında olmak. Forgejo v10.0, 16 Nisan 2025'ten beri EOL durumundadır. Onu yalnızca geçiş süresince kurar ve hemen ardından bir üst sürüme geçersiniz.

Doğrudan Yükseltme Yolu Neden Bozuldu

Aralık 2024'te Forgejo projesi şunu yayınladı uyumluluk bildirimi net bir çizgi çekti: "Gelecekteki Forgejo sürümleri, v1.23 veya üzerini çalıştıran Gitea örneklerinden yükseltmeleri desteklemeyecektir." Bu cümle tüm sorunu tek satırda özetliyor.

Forgejo, 2024'ün başlarında Gitea'dan çatallandığında, iki kod tabanı birbirinden ayrılmaya devam etti ve veritabanı şemaları birbirinden uzaklaştı. Forgejo, mevcut Gitea operatörlerinin geçiş yapabilmesi için bir uyumluluk penceresi korudu ama bu pencerenin bir sonu vardı. 16 Ocak 2025'te yayınlanan Forgejo v10.0 "the last version to allow a transparent upgrade from Gitea v1.22 or lower." v10.0'dan daha yeni herhangi bir sürüm, bir Gitea veritabanını doğrudan okuyamaz.

İnsanları yakalayan şey zamanlama. Gitea v1.23, 2024'ün sonlarında yayınlandı ve Haziran 2026 itibarıyla güncel Gitea sürümü v1.26.4. Gitea kurulumunuzu makul ölçüde güncel tuttuysanız, uçurumu zaten geçmişsinizdir ve standart eğitimler artık durumunuzu tarif etmez.

Bölümün özeti: desteklenen doğrudan yol Gitea v1.22'de son buluyor. Daha yeni her sürüm ekstra bir adım gerektiriyor.

Gitea Sürümünüze Göre Geçiş Yolunuzu Bulun

Çalıştırın gitea --version, satırınızı bulun ve üçüncü sütundaki yolu izleyin. Bu rehberdeki her şey, bu satırların arkasındaki ayrıntılardır.

Sürüm uyumluluğu ifadeleri doğrudan şu kaynaktan geliyor: resmi Forgejo uyumluluk duyurusu: v1.21'e kadar olan Gitea sürümleri Forgejo v7.0 ile v10.0 arasına geçebilir, Gitea v1.22 ise Forgejo v8.0 ile v10.0 arasına geçebilir. Her ikisi de desteklenen son doğrudan hedef olarak v10.0'da sona erer.

Sürüm sorusunun altında üç taşıma stratejisi yatıyor ve adım adım talimatlardan önce bunları görmek işe yarar:

• Yerinde, aynı sunucu. Mevcut sunucudaki ikili dosyayı veya konteyner imajını değiştirin. Sürümünüz destekliyorsa en az çaba gerektirir; v10.0 ara sıçraması gereklidir.
• Yeni sunucuda aşamalandırma. Yeni bir sunucu hazırlayın ve bunu Gitea sürümünüze uyan taşıma yöntemi için güvenli bir hedef olarak kullanın. Bu, orijinal Gitea sunucusunu korur ve geri almayı kolaylaştırır ama Gitea 1.23+ veritabanı şeması sorununu atlatmaz.
• Depo/API taşıma. Eski Gitea örneğinden depoları çekmek için Forgejo'nun taşıma araçlarını kullanın. Git geçmişi güvenilir kısımdır; sorunlar, PR'lar, etiketler, sürümler, wiki verileri ve yorumlar gibi meta veriler en iyi çaba olarak değerlendirilmeli ve depo depo doğrulanmalıdır.

Desteklenen Yol: Gitea v1.22 veya Öncesi

Gitea v1.22 veya daha eski bir sürümdeyseniz, resmi taşıma belgeleri iki adımlı bir yol tanımlıyor: Forgejo v10.0.x'e taşıyın, ardından Forgejo v10'u güncel sürüme yükseltin. İlk adım doğrudan bir değiştirmedir çünkü Forgejo v10.x bir Gitea v1.22 veritabanını okur; ikinci adım normal bir Forgejo yükseltmesidir.

Gitea'nın sunucunuzda nasıl çalıştığına bağlı olarak bunu yapmanın iki yolu var. Mevcut kurulumunuza uyanı seçin. Gitea bir sistem hizmeti olarak çalışıyorsa yerel yolu kullanın. Gitea bir konteynerde çalışıyorsa Docker yolunu kullanın. Forgejo v10.x, Gitea v1.22.x için doğrudan bir değiştirme görevi görür.

Native (systemd) Yolu

Önce yedek alın. Ardından dağıtımınızın paketini veya v10.0'a sabitlenmiş sürüm ikili dosyasını kullanarak Forgejo v10.0.x'i kurun. Herhangi bir şey kopyalamadan önce Gitea'yı durdurun. Kopyalama sırasında veri dizinine yazmaya devam eden çalışan bir servis, kopyayı bozar.

# Stop the running Gitea service before touching its data
systemctl stop gitea

Yapılandırmayı ve veri dizinini Forgejo'nun konumlarına kopyalayın, ardından sahipliği düzeltin. Yapılandırma dosyası forgejo grubu tarafından grup düzeyinde okunabilir olmalıdır; veriler forgejo kullanıcısına ait olmalıdır.

# Copy the existing Gitea config to Forgejo's config path
cp /etc/gitea/app.ini /etc/forgejo/app.ini

# Back up the copied config before rewriting paths
cp /etc/forgejo/app.ini /etc/forgejo/app.ini.bak

# Update old Gitea data paths to Forgejo data paths
sed -i 's#/var/lib/gitea#/var/lib/forgejo#g' /etc/forgejo/app.ini

# Forgejo reads its config as the forgejo group; grant group write
chown root:forgejo /etc/forgejo/app.ini && chmod g+w /etc/forgejo/app.ini

# Copy the data directory and hand ownership to the forgejo user
rsync -aHAX --numeric-ids /var/lib/gitea/ /var/lib/forgejo/
chown -R forgejo:forgejo /var/lib/forgejo

Forgejo'yu başlatın ve önyüklemede etkinleştirin.

# Start Forgejo and enable it at boot
systemctl start forgejo && systemctl enable forgejo

v10.0'dan yükseltme yapmadan önce, sürüm sıçraması sırasında devam eden hiçbir işin kaybolmaması için kuyrukları temizleyin (flush).

# Flush pending queue items before the version upgrade
forgejo manager flush-queues

Şimdi ikili dosyayı v15 ile değiştirip servisi yeniden başlatarak Forgejo v10.0.x'i güncel sürüme yükseltin, standart Forgejo yükseltme rehberi. Her iki adımdan sonra, veritabanını kontrol etmek ve düzeltebildiklerini düzeltmek için doctor'ı çalıştırın.

# Check everything; write a log you can read if something is wrong
forgejo doctor check --all --log-file /tmp/doctor.log

Okuyun /tmp/doctor.log herhangi bir otomatik düzeltme uygulamadan önce. Kullanın: --fix yalnızca doktor komutu çıktısı anladığınız belirli bir onarımı belirlediğinde veya resmi bir sorun giderme yolunu izlediğinizde.

Doctor kritik bir hata bildirmezse ve web arayüzü repolarınızı listelerse, ilk geçiş tamamlanmış demektir.

Docker / Konteyner Yolu

Gitea bir konteyner olarak çalışıyorsa, Forgejo'yu da aynı şekilde çalıştırın. Forgejo v10.x imajını, Gitea v1.22.x imajınızın doğrudan yerine geçecek şekilde kullanın ve aynı veri hacmine ve veritabanına yönlendirin. Önce Docker sürümünüzün en az 20.10.6 olduğunu doğrulayın. Daha eski sürümler, Forgejo konteynerleriyle tanımsız davranışlar üretir.

İnsanları takılmaya iten konteynere özgü tek ayrıntı: ortam değişkenleri. Forgejo, uyumluluk için GITEA_ önekini korur ama belgeler, eski adları bırakacak gelecekteki bir Forgejo sürümünde yapılandırmanızın hayatta kalması için her iki öneki de geçmenizi önerir.

# docker-compose.yml (excerpt): pass both prefixes for forward compatibility
environment:
  - GITEA__database__DB_TYPE=postgres
  - FORGEJO__database__DB_TYPE=postgres
  # ...repeat the dual-prefix pattern for every config override you pass

Rootless konteynerler için, veriler rootless imajın çalışma zamanı kullanıcısıyla eşleşecek şekilde 1000 kullanıcısına ve 1000 grubuna ait olmalıdır. Konteyner v10.x üzerinde başladıktan sonra, aynı forgejo doctor check --all konteynerin içinden, ardından imaj etiketini güncel v15 sürümüne yükseltin ve yeniden başlatın.

Gitea v1.23 veya Daha Yeni Bir Sürümdeyseniz

İşte standart rehberlerin durduğu ve mevcut kurulumların çoğunun gerçekte bulunduğu nokta burası. Gitea v1.23+ sürümünden resmi olarak desteklenen doğrudan bir yol yok, bu yüzden aşağıdaki her seçenek ya topluluk kaynaklı ya da veri kaybına yol açıyor. Bunlardan herhangi birini çalıştırmadan önce veri dizininizin ve veritabanınızın tam bir yedeğini alın ve geri yükleyebildiğinizi doğrulayın. Bu yaklaşımlar üretim verilerini değiştirir; yedek tek geri alma seçeneğinizdir.

Bu üç seçenek risk ve ne kadar veri koruduğu bakımından farklılık gösterir. Kabul edebileceğiniz ödünleşime sahip olanı seçin.

Seçenek A: SQL Şema Sürüm Düşürme / Sürüm Yaması

En dar çözüm, veritabanı şema sürümünü düşürerek Forgejo v10'un onu bir v1.22 veritabanı olarak ele almasını sağlar.

Not: Sürüm güncellemesini tek başına tam bir geri düşürme olarak ele almayın. Kaydedilen geçiş sürümü ile gerçek şema eşleşmelidir. Gitea 1.23.x üzerinde, Forgejo'yu ona yönlendirmeden önce tam geri düşürmeyi önce bir kopya üzerinde test edin ve şemayı karşılaştırın.

Bir Forgejo bakımcısı SQL'i şurada açıkladı Codeberg issue #7638:

-- Downgrade the recorded schema version to the v1.22 baseline (PostgreSQL/MySQL)
UPDATE version SET version=305 WHERE id=1;

Bundan sonra, sanki v1.22'deymişsiniz gibi desteklenen yolu izlersiniz. Kritik uyarı şu: bakımcı bunu yalnızca özellikle Gitea v1.23.1 için doğruladı, tüm v1.23.x sürümleri için değil. Şema sürüm numarası kesindir; yanlış hedef değeri yanlış Gitea sürümüne uygulamak, veritabanını hiçbir geçişin kurtaramayacağı bir duruma sokabilir. Bu PostgreSQL/MySQL içindir, resmi olarak desteklenmez ve genel bir prosedür olarak test edilmemiştir.

İpucu: version=305 değerini doğrudan ayarlamak, TOTP gizli anahtarlarının nasıl kodlandığını değiştiren 304'ten 305'e taşımayı atlar. Codeberg issue #8210 bunun etkilenen kullanıcılar için iki faktörlü kimlik doğrulamayı bozduğunu belgeliyor. Çözüm, sürümü 304 olarak ayarlamak ve taşımanın çalışmasına izin vermek ya da kullanıcıların yeniden kayıt olması için two_factor tablosundaki satırları temizlemektir. Herhangi bir hesap TOTP kullanıyorsa bunu atlamayın.

Seçenek B: Sıralı SQL Sürüm Düşürme Betikleri (Gitea 1.24-1.25.2)

1.24 ile 1.25.2 arasındaki sürümler için, tek bir sürüm yaması yeterli değildir: şema birkaç ara durumdan geçmiştir. Şurada bulunan topluluk betikleri xlrl/prepare-gitea-migration-to-forgejo şemayı ara sürümler boyunca v1.22'ye geri götürün, bundan sonra desteklenen yolu izlersiniz. Bu betikler topluluk çalışmasıdır, yetkili bir prosedür değildir ve birincil durum olarak SQLite'ı hedefler. Bunları yalnızca zaten yedeklediğiniz bir veritabanına karşı çalıştırın.

Seçenek C: Depo Depo API Taşıma (Gitea 1.26+ veya Herhangi Bir Sürüm)

Depo/API yolu, Git verilerini en güvenilir şekilde korur. Kaynağa, izinlere ve taşıma yöntemine bağlı olarak sorunlar, çekme istekleri, etiketler, kilometre taşları, sürümler, wiki verileri ve yorumlar gibi isteğe bağlı meta veriler de mevcut olabilir ama bunları en iyi çaba olarak değerlendirin ve depo depo doğrulayın. Yalnızca kod içeren bir arşiv için bu genellikle sorun değildir; sorun takipçisinin ekibin hafızası olduğu bir sunucu için bu yola bağlanmadan önce meta veri aktarımını test edin.

1.23+ sürümü için daha kapsamlı taşımalar deneyen iki deneysel araç var ama bunların da kendi eksikleri var. pacnpal/gitea2forgejo (GitHub) tam bir dump artı API senkronizasyonu yapar ve şifrelenmiş alanların aktarılabilmesi için eşleşen bir SECRET_KEY gerektirir, ancak Personal Access Tokens, Actions runner'larını, webhook geri çağırma URL'lerini veya 2FA'yı taşımaz. nicoverbruggen/gitea-to-forgejo (GitHub) kullanıcıları, anahtarları, organizasyonları, repoları, issue'ları, PR'ları, sürümleri ve mirror'ları aktaran, Podman tabanlı deneysel bir araçtır, ancak 2FA token'larını, Actions çalışma zamanı verilerini veya sahipsiz kalmış OCI paket manifestlerini aktarmaz. Her ikisini de deneysel olarak kabul edin ve sonucu aşağıdaki aktarım matrisine göre doğrulayın.

Bölümün özeti: Gitea 1.23+ sürümünden resmi olarak desteklenen doğrudan bir yol yok. Katlanabileceğiniz veri kaybı ödünleşimine sahip seçeneği seçin ve başlamadan önce yedek alın.

Yeni Bir Sunucuda Geçiş Yapmak Daha Güvenlidir, Ancak Sürüm Uçurumunu Atlatmaz

Yeni bir sunucu, geçişi aşamalandırmak ve doğrulamak için en güvenli yerdir, ancak ayrı bir şema uyumluluğu yolu değildir. Kaynağınız Gitea v1.22 veya daha eskiyse, önce hedefe Forgejo v10.0.x kurun, Gitea verilerini oraya geri yükleyin veya kopyalayın, Forgejo'nun desteklenen veritabanı geçişlerini çalıştırmasına izin verin ve ardından bu Forgejo v10 örneğini güncel Forgejo sürümüne yükseltin.

Kaynağınız Gitea v1.23 veya daha yeniyse, Gitea veritabanını doğrudan güncel Forgejo'ya geri yükleyip başlamasını beklemeyin. Yukarıdaki desteklenmeyen 1.23+ yaklaşımlarından birine hala ihtiyacınız var: aşamalı bir SQL geri düşürme veya geri alma, bir topluluk geçiş aracı veya bir repo/API geçişi. Yeni sunucu, orijinal Gitea makinesi dokunulmadan kaldığı için geri alma riskini azaltır; ancak veritabanı sürüm uyuşmazlığını ele alma ihtiyacını ortadan kaldırmaz.

İşte bu noktada Cloudzy'nin tek tıkla Forgejo uygulaması yardımcı olabilir: onu temiz hedef örnek olarak kullanın, ardından Gitea sürümünüze uyan taşıma yöntemini çalıştırın. Cloudzy'nin pazar yeri imajı, size şu adreste hazır bir Forgejo hedefi sunar: yüksek performanslı VPS, böylece ilk kurulum yerine geri yükleme, doğrulama ve geçiş adımlarına odaklanabilirsiniz. Geçiş planı, Gitea 1.22 uçurumunun öncesinde mi yoksa sonrasında mı olduğunuza hala bağlıdır.

Ne Aktarılır ve Neyi Yeniden Yapmanız Gerekir

Verilerinizin bir kısmı otomatik olarak taşınır, bir kısmı yalnızca bir koşul sağlandığında taşınır ve bir kısmı hiç taşınmaz, elle yeniden oluşturulması gerekir. Başlamadan önce hangisinin hangisi olduğunu bilmek, temiz bir geçiş ile bir hafta boyunca kafası karışmış kullanıcılar arasındaki farktır.

Dört öğe en sert şekilde vurur çünkü sessizce bozulurlar veya her kullanıcıyı etkilerler, bu yüzden bunları özenle ele alın: kullanıcılar Personal Access Tokens'larını yeniden oluşturmalı veya denetlemeli, Actions runner'larınızı yeni ana bilgisayar adına karşı yeniden kaydetmelisiniz, Forgejo'nun temiz bir şekilde yeniden oluşturması için Bleve arama indeksini silmelisiniz ve herhangi bir uses: Actions iş akışlarınızdaki kısa referansları tam GitHub URL'lerine dönüştürün, çünkü Forgejo ve Gitea eylemleri ayrı yansılardan çeker ve göreli bir referans yanlış yere çözümlenir.

İpucu: Taşıma sırasında Gitea ve Forgejo'yu paralel çalıştırıyorsanız ve ikisi de aynı Redis örneğine işaret ediyorsa, başlamadan önce Forgejo'yu Redis db=1 olarak değiştirin. İkisi de varsayılan olarak db=0 kullanır ve bunu paylaşırlarsa Gitea, Forgejo'nun taşıma olaylarını tüketir ve taşıma kuyruğunu bozar. (blog.mei-home.net documents this exact failure.)

Bölümün özeti: Kişisel Erişim Belirteçleri, Actions çalıştırıcıları, depo başına dağıtım anahtarları ve Bleve arama indeksi her zaman elle yapılır. Bunları sonradan akla gelen işler olarak değil, taşıma görevleri olarak planlayın.

Taşımanın Başarılı Olduğunu Doğrulayın

Doktor komutuyla başlayın, ardından sayıları kontrol edin, sonra kullanıcıların gerçekte yaptığı şeyleri test edin. Doktor komutu veritabanı düzeyindeki sorunları yakalar; elle yapılan kontroller ise doktor komutunun göremediği veri kaybı ve erişim sorunlarını yakalar.

1. Çalıştırın forgejo doctor check --all --log-file /tmp/doctor.log, ardından değişiklik yapmadan önce günlüğü okuyun. Kullanın --fix yalnızca anladığınız belirli bir onarım için.
2. Repo sayısının, issue ve PR sayılarının, LFS nesne sayısının ve toplam boyutun, geçiş öncesi sayılarınızla eşleştiğini doğrulayın. Burada bir uyuşmazlık, bir şeyin aktarılmadığı anlamına gelir.
3. Bir SSH push ve pull işlemini test edin. İstemciler bir ana bilgisayar anahtarı uyumsuzluğu alırsa, /etc/ssh/ssh_host_* dosyalarını yeni sunucuya kopyalamamışsınız demektir.
4. Giriş yapın ve 2FA kullanan bir hesap için 2FA'nın çalıştığını doğrulayın. TOTP bozuksa, yukarıdaki Seçenek A uyarısına bakın.
5. Kişisel Erişim Belirteçlerini yeniden oluşturun, Actions çalıştırıcılarını yeniden kaydedin ve bir test iş akışı çalıştırın.

Geçiş sonrası birkaç belirtinin bilinen nedenleri vardır. Eksik bir favicon veya logo, marka varlıklarınızın Forgejo'nun artık beklediği custom/ yerine hala public/assets/img/ içinde olduğu anlamına gelir. Paket rotalarındaki 404 hataları, yanlış yapılandırılmış depolama yollarına işaret eder. "repository not found" hatasıyla başarısız olan Actions ise uses: yansıtma sorunu. Tam URL'lere geçin. Bir SQLite veritabanında girişten sonra boş veya 500 sayfası, minimumun altında olduğunuz anlamına gelir, ki bunu yükseltme belgeleri Forgejo v1.19.3-0 olarak belirledi.

Gitea'da Kalmanın Mantıklı Olduğu Durumlar

Geçiş yapmak bir zorunluluk değil, bir tercihtir. Uçurumu zaten geçtiyseniz ve geçiş karmaşıklığı, durumunuz için yönetişim veya özellik faydasından ağır basıyorsa, Gitea'da kalmak meşru bir tercihtir. Gitea aktif olarak geliştiriliyor (ayda birden fazla sürüm, şu anda v1.26.4'te) ve CommitGo şunları da içeren ticari seçenekler sunuyor Gitea Enterprise, Gitea Cloud ve SOC 2 Type 2 sertifikası buna ihtiyaç duyan ekipler için.

Dürüstçe tartılması gereken bir EOL ara aşama endişesi de var. Desteklenen doğrudan yol, Nisan 2025'ten beri EOL olan Forgejo v10.0'ı kısa süreliğine kurmayı gerektirir. Bu, hemen ardından yükselteceğiniz geçici bir taşıma adımı olarak kabul edilebilir ama bazı operatörler politika gerekçesiyle buna itiraz edecektir. Onlar için, yeni bir Forgejo örneğine depo/API taşıması EOL sıçramasını tamamen atlayabilirken, yeni sunucu hazırlama hâlâ seçtiğiniz taşıma yöntemine bağlıdır.

Geçiş nedeniniz geliştirme aktivitesiyse, veriler Forgejo'yu daha aktif proje olarak destekliyor: şu analiz honeypot.net Temmuz 2024'ten Mayıs 2025'e kadar 1.228 Gitea commit'ine karşılık 3.039 Forgejo commit'i ve Mayıs 2025'te sona eren yıl boyunca Gitea için 153'e karşılık 232 Forgejo katkıcısı saydı. Bu birkaç sinyalden biridir; bunu belirleyici olarak ele almak yerine taşıma riskinize karşı tartın.

Bölümün özeti: taşımak zorunlu değil. Karar, taşıma riskine karşı tartılan bir yönetişim ve etkinlik tercihidir ve her iki seçim de savunulabilir.

Yolunuzu Seçin ve Önce Yedek Alın

Taşıma yolunuz tek bir sayıya iniyor: Gitea sürümünüz. v1.22 veya öncesinde, Forgejo v10 üzerinden desteklenen iki adımlı yolu izlersiniz. v1.23 veya sonrasında, kabul edebileceğiniz veri kaybına göre bir geçici çözüm seçersiniz: SQL/şema düşürme, topluluk betikleri, depo/API taşıması veya yeni sunucu hazırlama taşıması. Hangi yolu izlerseniz izleyin, önce veri dizininizi ve veritabanınızı yedekleyin, şunu çalıştırın: forgejo doctor sonrasında ve depo, sorun ve LFS sayılarınızın başladığınız değerlerle eşleştiğini doğrulayın.

Sürümünüzü belirleyin, yedeği alın ve eşleşen satırı izleyin. Yol, eski eğitimlerin vaat ettiğinden daha karmaşık, ancak sürüm uçurumunda nerede durduğunuzu bildiğinizde net bir şekilde tanımlanmış.

Sıkça Sorulan Sorular

Gitea'dan Forgejo'ya Doğrudan Yükseltme Yapabilir miyim?

Evet, Gitea v1.22 veya öncesini çalıştırıyorsanız: doğrudan Forgejo v10.0'a yükseltin, ardından Forgejo v10'u güncel sürüme yükseltin. Hayır, Gitea v1.23 veya daha yenisini çalıştırıyorsanız. Forgejo v10.0, şeffaf bir doğrudan yükseltmeyi destekleyen son sürümdü, bu yüzden daha yeni Gitea sürümleri bunun yerine bir geçici çözüm gerektiriyor.

Forgejo ile Hangi Gitea Sürümü Uyumludur?

Gitea v1.22 ve öncesi, Forgejo'ya desteklenen doğrudan bir yükseltme yoluna sahiptir (Forgejo v10.0'a kadar, ardından güncel sürüme). Gitea v1.23 ve sonrası için resmi olarak desteklenen doğrudan bir yol yoktur, çünkü Forgejo, v10.0 sonrası sürümlerden itibaren Gitea v1.23+'tan şeffaf yükseltmeleri desteklemeyi bıraktı.

Gitea 1.26'dan Forgejo'ya Geçiş Yapabilir miyim?

Evet ama desteklenen bir doğrudan yükseltme yoluyla değil. Seçenekleriniz; Git geçmişinin güvenilir kısım olduğu ve meta verinin depo depo test edilmesi gereken bir depo/API taşıması, deneysel bir taşıma betiği veya yukarıdaki desteklenmeyen 1.23+ yöntemlerinden birini kullanan bir yeni sunucu hazırlama taşımasıdır. Gitea 1.26'dan resmi olarak desteklenen yerinde bir yol yoktur.

Personal Access Tokens'larım Aktarılır mı?

Taşıma sonrasında Kişisel Erişim Belirteçlerini yeniden oluşturmayı veya döndürmeyi planlayın. Bazı taşıma yolları bunları korumaz ve belirteçler mevcut kalsa bile kullanıcılar onlara tekrar güvenmeden önce kapsamlarını denetlemelidir. Eski belirteçleri kullanan betikler veya entegrasyonlar geçişten sonra test edilmeli ve güncellenmelidir.

Gitea Actions İş Akışlarım Forgejo'da Çalışır mı?

Çoğunlukla, iki gerekli düzeltmeyle birlikte. İş akışı uses: kısa referanslar bozulur çünkü Forgejo ve Gitea eylemleri ayrı yansılardan çeker. Bunları tam GitHub URL'lerine değiştirin (örneğin, uses: https://github.com/sammcj/dotenv-output-action@main). Ayrıca Actions runner'larınızı yeniden kaydetmeniz gerekir, çünkü kayıt token'ları eski ana bilgisayar adına bağlıdır.

Gogs'tan Forgejo'ya Taşıma Konusunda Ne Olacak?

Bu, farklı bir yola sahip farklı bir taşıma işlemidir ve bu yazının kapsamı dışındadır. Bu rehber özellikle Gitea'dan Forgejo'ya taşımayı ele alır; bir Gogs kaynağı için Gogs'a özgü prosedür konusunda Forgejo'nun resmi taşıma belgelerine başvurun.