Git depolarını GitHub’a taşırken asıl mesele ne?
Bir repo taşımak, aslında bir strateji kararı
Şunu açık konuşayım: Son yıllarda repository taşıma işine artık sadece “migrasyon” diye bakmiyorum. Bu, doğrudan ekiplerin nasıl çalışacağını, hangi AI araçlarına ne kadar hızlı erisecegini (ki bu çoğu kişinin gözünden kaçıyor). Operasyonel yükün nereye kayacagini belirleyen stratejik bir karar hâline geldi. Microsoft’un Azure DevOps’tan GitHub’a bazı is yüklerini taşıma yaklaşımı da tam burada anlam kazanıyor. Kodun nerede durduğu, bugün eskisinden çok daha önemli.
Geçen sene Şubat 2025’te bir finans müşterinde benzer bir tartışma yaşadık. Ekip, Azure Repos’tan memnundu ama Copilot tarafındaki yeni özellikleri de kaçırmak istemiyordu. Orada gördüğüm şey su öldü: Teknik soru gibi başlayan konu, kısa sürede yönetişim, güvenlik ve maliyet meselesine dönüyor. Yanı mesele “GitHub mi Azure DevOps mu?” değil; “hangi hızda donusmek istiyoruz?” sorusu (şaşırtıcı ama gerçek)
Tuhaf ama, Microsoft’un yaklaşımında hoşuma giden taraf su: Her şeyi bir anda koparip atmak yerine, geçişi parça parça ele alıyorlar. Bu bayağı iş görüyor. Çünkü büyük kurumsal yapılarda herkesin aynı gün aynı ritimde hareket etmesi pek gerçekçi değil. Küçük startup tarafında bu is daha kolay; tek ekip, tek ürün hattı, daha az bağımlılık… Kurumsalda işe işler öyle yurumu yor. Bir repo tasinirken test süreçleri, izinler, branch politikaları ve release akisleri de beraber geliyor.
Neden şimdi? AI baskısı işi hızlandırdı
Işin aslı şu ki AI çağında kodun bulunduğu yer artık nötr değil. Bir repo GitHub’daysa Copilot, code review otomasyonu, agent tabanlı akışlar. Veri yakinligi gibi konularda eliniz daha rahat oluyor. Azure DevOps hâlâ güçlü mu? Evet, fazlasıyla güçlü. Ama AI-native geliştirme isteyen ekipler için GitHub’in ekosistemi biraz daha önde gidiyor gibi dürüyor.
Ben AZ-305’e hazırlanırken mimarı kararların ne kadar “küçük detay” sandığımız noktadan çıktığını tekrar görmüştüm. Kimlik doğrulama katmanı değişince ag tasarımı etkileniyor; repository platformu değişince de sadece geliştirme değil, güvenlik. Teslimat zinciri etkileniyor. Neden önemli bu? Kısacası depo neredeyse yalnızca teknik tercih değil, üretkenlik carpanı oluyor.
Şunu söyleyeyim, Ha bu arada… Türkiye’deki şirketlerde bu geçiş biraz daha temkinli ilerliyor. Bunun sebebi teknoloji eksikliği değil; cogun kurumda süreçler uzun yıllardır Azure DevOps üstüne kurulmuş durumda. Insanlar doğal olarak “ya bozulursa?” diye düşünüyor. Haklılar da. Özellikle regülasyon hassasiyeti olan sektörlerde data residency, denetim izi ve yetkilendirme yapısı baştan netleşmeden kimse kipirdamak istemiyor.
Küçük ekip ile enterprise arasında fark var
Küçük bir startup iseniz bence yol basit: hızlı deneyin, birkaç repoyu taşıyın, sonuçlara bakın ve karar verin. Burada en büyük avantaj hızdır.
Enterprise seviyesindeyseniz tablo değişiyor. Bir bankacılık projesinde 2024 Kasım’ında bunu yaşadık; tek sorun migration değildi, etrafındaki onlarca bagimlilikti. Test ortamları, service connection’lar, approval zincirleri derken her adım ayrı inceleme gerektirdi (evet, doğru duydunuz). Büyük kurumlarda pilot yaklaşımı şart oluyor — yoksa operasyon ekibi sizi masanın kenarına oturtur.
Microsoft’un ölçeğinde migration nasıl görünüyor?
CAP organizasyonunun binlerce aktif repository’den söz ettiğini okuyunca ilk refleksimiz su oluyor: “Bunu kaç kişiyle yaptılar acaba?” Cevap şaşırtıcı derecede sade: küçük bir cekirdek ekiple ilerlemisler. Bence buradaki en hayatı mesaj teknoloji değil; odaklanma disiplini. Azure Cosmos DB’de Silinenleri Görmek: Change Feed’in Sessiz Gücü yazımızda bu konuya da değinmiştik.
Geçen yıl İstanbul’da bir telekom müşterinde benzer bir model denedik: önce yüksek riskli olmayan 12 repoyu seçtik, sonra pipeline etkisini ölçtük. Beklediğim kadar pürüzsüz değildi açık konuşayım; eski service hook’lardan biri sessizce bozuldu ve bunu ancak gece kosusunda fark ettik! Çözüm basitti ama can sıktı: webhook URL’lerini yeniden duzenledik ve branch policy eslesmelerini kontrol ettik.
İşin garibi, Migrasyon araçları burada hayat kurtarıyor ama sihir yapmiyorlar. GEI veya ELM gibi araçlar süreci hızlandırabilir; yine de işim alanları, commit geçmişi temizliği ve repo boyutu gibi detaylarda insan eli gerekiyor. Yanı otomasyon iyi güzel ama kahveyi kendisi icmiyor.
| Kriter | Küçük ekip | Büyük kurumsal yapı |
|---|---|---|
| Migrasyon hızı | Daha hızlı | Aşamalı olmalı |
| Risk yönetimi | Daha hafif kontrol yeterli | Sıkı onay mekanizması gerekir |
| Araç seçimi | Basit importer bile iş görür | ELM/GEI gibi kurumsal araçlar daha uygun |
| Eğitim ihtiyacı | Düşük-orta | Yüksek |
Bence asıl kazanım: AI hızını açmak
İlginç olan şu ki, Repo GitHub’a geçtiğinde yalnızca adres değişmiyor; geliştirici deneyimi de değişiyor. Code review kültürü bir düşüneyim… başka yere kayıyor, Copilot ile etkileşim artıyor ve ekipler agentic workflow denen yeni düzene alışmaya başlıyor. Kağıt üstünde küçük fark gibi dürüyor ama pratikte ciddi zaman kazancı var.
Repo migrasyonu yalnızca teknik borcu kapatmaz; doğru yapılırsa ekiplerin yapay zekâdan aldığı verimi de artırır.
Doğrusu, Buna rağmen her şeyi pembe görmek doğru olmaz. Benim deneyimimde en sık hayal kırıklığı yaratan konu uyumluluk beklentisi oluyor. Insanlar bazen “tastik bitti” sanıyor (en azından benim deneyimim böyle). Sonra yetki modeli farklı çıkıyor ya da pipeline tetikleme davranışı ufak farklarla geri dönüyor… Işte o zaman anlıyorsunuz ki iyi planlanmamis migration aslında gecikmis problem demek.
E tabi maliyet tarafı da var. GitHub Enterprise lisansı ile Azure DevOps kullanım modelini birlikte düşünmek lazım; TL bazında bakınca karar bazen hissedilenden farklı çıkabiliyor çünkü döviz kuru sabit kalmıyor — yanı bütçe hesabını aylık değil çeyreklik okumakta fayda var.
Bir müşteri toplantısında bunu net hissettim: Güvenlik ekibi hız istiyordu ama finans tarafı sürpriz fatura istemiyordu.
Çözüm olarak aşamalı geçiş + rol bazlı lisans takibi + kullanılmayan repo temizliği yaptık.
Sonuç fena değildi.
Ama mucize de değildi.
Eğer bütçe kisitliyse ne yapmalı?
- Tüm repoları aynı anda taşımayin; önce düşük riskli olanlardan başlayin.
- Pahalı özelliklere hemen yüklenmeyin; temel collaboration yeterliyse sade kalın.
- Pilot aşamada üç metrik izleyin: build süresi, hata oranı, geliştirici memnuniyeti.
- Ekip içi eğitim olmadan geçiş yapmayın; yoksa tool değişir ama alışkanlık değişmez.
Bende bıraktığı izlenim: iyi yönde adım ama eksikler var
Açık konuşayım; Microsoft’un bu yönelimi doğru yönde atılmış bir adım diye düşünüyorum.
Ama henüz her şey pişmış̧ değil.
Özellikle büyük kurumlarda geçiş sırasında görünürlük katmanı daha da guclenmeli.
Hangi repo neden taşındı?
Kim onayladı?
Eski baglantılar tam olarak nerede kaldı?
Bu sorular bazen yazılım ekibinden çok denetim ekibinin gündeminde oluyor (eh, fena değil)
Aslında, 2019’da kendi laboratuvar ortamımda eski bir SVN’den Git’e göc denerken benzer duyguyu yaşamıştım.
İlk denemede history mapping yüzünden birkaç commit etiketsiz kaldı.
O gün anladığım şey şuydu:
Taşımanın teknik kısmı çözülür;
ama iletişim kötü işe proje yine tökezler.
İnsan faktörü hep orada dürüyor.” GitHub Copilot’ta Bütçe, Plan ve Kullanımın Yeni Ayarı yazımızda bu konuya da değinmiştik.
Nereden başlanır?
Bi saniye — Lafı gevelemeden söyleyeyim:
ilk iş en kritik olmayan reposu seçmek.
Sonra mevcut bağımlılıkları çıkarın,
branch policy’leri belgeleyin,
pipeline bağlantılarını test edin,
bir de rollback planını masaya koyun.
Rollback yoksa migration yok sayılır benim gözümde.
Nokta.” Build 2026: AI Ajanlarında Ölçümden ROI’ye Geçiş yazımızda bu konuya da değinmiştik. Agent Optimizer ile Kurumsal Yapay Zekâyı Pişirmek yazımızda bu konuya da değinmiştik. azure-functions-skills: Azure Functions İçin Yapay Zekâ Çalışma Alanı yazımızda bu konuya da değinmiştik.
# Basit geçiş kontrol listesi
1) Repo kapsamını belirle
2) Pipeline / Board bağımlılıklarını çıkar
3) İzinleri eşleştir
4) Pilot taşıma yap
5) Logları izle
6) Kullanıcı geri bildirimi topla
7) Genişletilmiş taşıma planla
Sıkça Sorulan Sorular
Azure DevOps’tan GitHub’a büyük çoğunluk repoları taşımak gerekiyor mu?
Hayır, hepsini bir anda taşımaya kalkma. Açıkçası bu genelde iyi bir fikir değil. Önce düşük riskli ya da Copilot gibi AI araçlarından en çok kazanç sağlayacak repolarla başlamak çok daha mantıklı. Yanı kurumsal yapılarda hibrit yaklaşım bence çoğu zaman çok daha sağlıklı işliyor.
Migrasyon sırasında Azure Boards’u kullanmaya devam edebilir mıyız?
Evet, birçok senaryoda rahatlıkla devam edebilirsiniz. Mesela ekipler kodu GitHub’da tutup iş takibini Azure Boards üzerinden yürütebilir. Ama tecrübeme göre entegrasyon ayarlarını baştan temiz yapmak şart, sonradan düzeltmek can sıkıyor.
Küçük şirketler için GitHub’a geçiş gerçekten gerekli mi?
Zorunlu değil, ama çoğu küçük ekip için aslında oldukça faydalı. En çok da Copilot ve modern code review akışlarından yararlanmak istiyorsanız gerçekten değer yaratıyor. Bütçe sıkışıksa pilot proje ile başlamak çok daha güvenli bir yol.
Büyük kurumlarda en büyük risk ne?
Bence en büyük risk teknik değil, süreçsel oluyor:
yetki yönetimi,
bağımlılık haritalaması
ve kullanıcı eğitimi eksik kalabiliyor.
Açıkçası bu üçü oturmadan yapılan geçiş sonradan çok pahalıya patlıyor (şaşırtıcı ama gerçek)
Kaynaklar ve İleri Okuma
Vallahi, Microsoft Dev Blog — How Microsoft is migrating repositories to GitHub
GitHub Migration Overview — Microsoft Learn
GitHub Enterprise Importer (GEI) — Resmî Kaynak
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder