# Monorepo vs Polyrepo: Bir Kez Seçilen Mimari Karar

URL: https://whatshouldibuildnext.com/tr/journal/monorepo-vs-polyrepo
Type: blog
Locale: tr
Published: 2026-09-26
Updated: 2026-09-26

---

> Monorepo veya polyrepo kullanmalı mısınız? Her şey hizmetlerin kod paylaşıp paylaşmadığına, kimden erişim gerektiğine ve CI toleransınıza bağlı. İşte pratik çerçeve.

Monorepo ve polyrepo sorusu her yeni projeye başlamadan önce çıkıyor; cevap aylar boyunca CI/CD kuruluşunu, refaktoring yükünü ve takım erişim kontrolünü şekillendiriyor. 2026'da paylaşılan kodla ürün oluşturan bağımsız geliştiriciler için doğru varsayılan monorepo'dur. Moda olduğu için değil, iki paket birbirle konuşması gereken anda polyrepoya dayatılan yayımlarma törenini ortadan kaldırdığı için. Hizmetleriniz tamamen bağımsızsa ve asla kod paylaşmayacaksa polyrepo daha basit olur. Diğer her durumda, seçim bağlamdan bağlıdır. Monorepo vs polyrepo kararı erken verilmeli çünkü altı ay sonra değiştirmek projenizi yeniden yapılandırmak demektir.

Saat 22:00 (veya yerel zamanınızda geç saatler). Yeni proje şekil alıyor: bir arka uç API'si, paylaşılan TypeScript tipler paketi ve her ikisini de tüketecek olan ön uç kontrol paneli. İki sekme açık. İmleç yanıp sönüyor.

Bu konudaki çoğu yazı, Bazel yapılandırması yapıp sevinen özel bir DevOps mühendisiyle yirmi kişilik mühendislik ekipleri için yazılmıştır. Bu yazı, ilk committen önce karar vermeleri gereken ve altı ay sonra, gerçek kullanıcılarınız olduğunda ve kas hafızanız CI boru hattını ezberlediğinde yeniden yapılandırmanın bir side projesinin hızını kalıcı olarak öldüreceğini bilen geliştiriciler içindir.

## Monorepo Gerçekten Ne Sağlıyor (Ders Kitabı Sürümü Değil)

Standart değişim "bir repo, paylaşılan bağımlılıklar, atomik değişiklikler." Bu tamamen gerçek. Ama bağımsız bir geliştirici için günlük olarak önemli olan daha konkret: paketleri yerinde kullanmak için yayımlamanız gerekmez.

Polyrepo kurulumunda, eğer `shared-utils` düzeltilmesi gerekiyorsa ve `api-service` da etkileniyorsa, ya `shared-utils` yeni bir sürüm yayımlarsınız, `api-service` bağımlılığını güncellersiniz, CI'nin geçmesini beklersiniz ve sonra dağıtırsınız. Bu döngü dakikalar alabilir veya saatler alabilir. Yoksa sprint ortasında çalışmayı kesen `npm link` hile yöntemine düşersiniz ve bu hile eksiksiz değildir. Monorepo'da pnpm workspace'ler ile kod değişikliği yaparsınız ve onu içe aktaran her paket değişikliği hemen görür. Tüm paketler aynı kaynaktan çıktığı için tutarlılık garantilidir. Yayımlama töreni yok, npm registry işlemleri yok, versiyon senkronizasyon problemi yok.

Pnpm workspace'leri ile bu nasıl görünüyor (minimal yapılandırma yükü ekler):

`/packages
  /shared-types      ← API ve web tarafından doğrudan içe aktarıldı
  /api
  /web
package.json         ← "workspaces" alanı bulunan workspace kökü`
```
`// api/package.json
{
  "dependencies": {
    "@myapp/shared-types": "workspace:*"
  }
}`
```
Yayın yok. Geliştirme sırasında sürüm güncellemesi yok. `workspace:*` yerel pakete çözümlenir ve TypeScript'in proje referansları tüm grafik üzerinde kademeli derleme sağlar.

İkinci gerçek avantaj: paketler arası refaktoring tek bir PR'de iniş yapar. `shared-types` içindeki arayüzü yeniden adlandırsanız, TypeScript bozulan her tüketiciyi same kodbase'de, aynı editör oturumunda size söyler. Polyrepoda, repo A'da adı değiştirir, yeni bir sürüm yayımlarsınız ve kırılmayı repo B'de üç gün sonra bir iş arkadaşı `npm install` çalıştırdığında ve türler çalışma zamanı ile eşleşmediğinde keşfedersiniz.

Üçüncü avantaj, bağımsız geliştiricilerin hafife aldığı: araçlar için tek bir yer. Bir `.eslintrc`, bir `prettier.config.js`, bir CI iş akışı dosyası. Polyrepo'da her repoda bu dosyaları ayrı ayrı yönetirsiniz ve tutarlılık sağlamak için kopya-yapıştırma yapıyorsunuz. Monorepo'da bir değişiklik tüm paketleri etkiler. Değişiklik başına küçük tasarruflar, ama aylar boyunca yineleme üzerinde birikirler. Altı ay sonra bu farklılık okunabilirlik ve bakım maliyetinde belirgin hale gelir.

Monorepo'nun vermediği şeyleri adlandırmaya değer: hizmetleri daha az bağlı yapmaz. Hizmetleriniz gerçekten bağımsızsa ve yine de monorepo'ya koysanız, koordinasyon yükü eklemişsinizdir. Monorepo'nun faydaları, hizmetler gerçekten kod paylaştığında veya birlikte değiştiğinde ortaya çıkar. Repo yapısı bağımlılık yapısını yansıtmalı, dayatmamalıdır.

![Monorepo'yu tek ağaç ile polyrepo'yu çoklu kutular ile karşılaştıran soyut görselleştirme](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-09/06d7c6-img-1.webp)

## Polyrepo Merkezini Kazandığı Durumlar

Polyrepo bir hata değildir. Spesifik durumlar için doğru seçimdir ve aksini iddia etmek sizi 40 servis monorepo'suyla baş başa bırakır ve klonlaması 25 dakika sürer.

En açık durum: gerçekten farklı sahiplik, sürüm döngüsü veya uyum gereksinimlerine sahip hizmetler. Faturalandırma hizmetiniz PCI kapsamında ve pazarlama siteniz değilse, onları ayrı reporda tutmak erişim kontrolü, denetim günlükleri ve hasar alanını temiz olarak ayrı tutmanız anlamına gelir. Kimse faturalandırma kodunuza ince ayar yapmasa bile, başka bir reposunda yapılanlar burayı etkilemez. Bu operasyonel yük değildir. Bu özellik. Finans ve güvenlik açısından gerektiğinde, polyrepo sızıntıları ortadan kaldırır.

Polyrepo ayrıca kodu açık kaynak haline getirirken kazanır. Adanmış bir genel repo, dış katkıda bulunanların özel altyapınızı kapsama dahil etmeden çatallandırıp PR göndermelerine izin verir. GitHub'ın havuz düzeyi izin modeli, ölçekte temiz yol tabanlı erişim yalıtımı vermez. Ayrı repo bunu doğru bir şekilde ele alır.

Ve tamamen farklı teknoloji yığınlarına sahip saf mikro hizmetler için: kod düzeyinde hiç paylaşmayan Go servisi ve React Native uygulaması, monorepo koordinasyon maliyeti ekler ve faydayı sunmaz. Paylaşılacak paket yoksa paylaşacak hiçbir şey yoktur.

Bunun dürüst sürümü: polyrepo'yla başlayan çoğu indie proje sonunda pişmanlık duyar, polyrepo kötü mimari olduğu için değil, parçaların ne kadar bağımsız kalacağını abartmış oldukları için. Ön uç her zaman arka uçtan bir tip almak istiye çıkıyor. İşçi her zaman API'den bir yardımcı almak istiyor. İki repo dört PR haline geliyor. Koordinasyon sorunu monorepo'ya geçmeden sonra ortaya çıkıyor, bu noktada tekrar geçiş yapılan kararı pahalı ve yorucu hale getiriyor. Monorepo'yla başlayanlar ise, gerçekten ayrı tutmanız gereken durumları daha sonra tespit etmek ve o zaman bölmek için daha rahat bir konumdadır.

## Hiç kimse faturasına çarpana kadar bahsetmediği CI/CD Maliyeti

Monorepoların gerçek bir operasyonel maliyeti vardır: eğer CI naif bir şekilde her committe her şeyi çalıştırırsa, değiştirdiğiniz şeyle hiçbir ilgisi olmayan yapılar ve testler için zaman ve paranız gider.

Web paketine CSS ince ayar gönderin. CI `api`, `worker` ve `shared-types` için tam test paketini çalıştırır. Linting, unit testler, entegrasyon testleri, build aşamalarının tamamı. Bu bir renk değişikliği için GitHub Actions'ın altı dakikalık hesaplamasıdır. Bunun para maliyeti göz ardı edilebilir, ama geliştirme hızı açısından önemli. Ölçekte bu, tüm takımınızı bloke eden CI kuyruklarına dönüşür. Hatta bağımsız geliştiriciler için bile, kendi zamanı boşa harcıyor ve commit hızını düşürüyor.

Çözüm var, ama kasıtlı kurulum gerekir: bağımlılık grafiğinizi anlayan yapı yönetimi araçları. [Turborepo](https://turbo.build/) ve Nx ikisi de bunu çözer. Turborepo'nun `turbo.json` her görevin yalnızca değiştirilen girdileri olan paketler için çalıştığı bir boru hattı tanımlar:

`{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "cache": true
    }
  }
}`Uzaktan önbellekleme etkinleştirildiğinde (küçük takımlar için Vercel'in Turborepo Cloud katmanında ücretsiz), değişmeden paket üzerinde önbellek isabeti anında gerçekleşir, yeniden yapı yok, yeniden test yok. Bağımsız geliştirici için yan projede, bu CI'yi yapı yapıtları ısındıktan sonra çoğu itişte iki dakikanın altında tutar.

Maliyet: Turborepo veya Nx'i ihtiyacınız varsa değil, ihtiyaç duyduğunuzdan önce öğrenmeniz gerekir. Bu kabaca yarım günlük kurulumdur. Atlarsanız ve CI yağ biriktirir izin verirseniz, monorepo CI o kadar yavaşlayacak ki mimari seçimin tamamını sorgulamaya başlarsınız, ve işte o zaman geliştiriciler polyrepo'nun hep haklı olduğuna karar verirler, gerçek sorun sadece eksik yapılandırma dosyasıydı.

![Monorepo mimarisi için paralel yapı işleri ve dağıtım durumunu gösteren CI/CD boru hattı kontrol paneli](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-09/10ba32-img-2.webp)

## Yapay Zeka Kodlama Araçları Bu Tartışmadaki Matematiği Nasıl Değiştirdi

Son zamanlara kadar, polyrepo için gerçek bir argüman bilişsel yük vardı: küçük repolar daha kolay anlaşılır çünkü izole ederler. Yeni servise bağlam değişir, sadece o servis için ilgili şeyler görürsünüz. Argüman meşruydu.

Yapay zeka kodlama araçları bu hesabı değiştirir. Cursor, Claude Code veya GitHub Copilot ile çalışırken araç tam kodbase'inizle kontekst içinde çalışır. Servisler arası bağımlılıkları görür, hangi arayüzün hangi hizmet tarafından tüketildiğini anlar ve yeniden adlandırılmış bir alanı her tüketici aracılığıyla izleyebilir siz kafanızda modeli tutmadan. "Isolated repo anlaşılması kolay" argümanı yapay zeka asistanı zaten bağımlılık grafiğini tuttuğunda önemli ölçüde zayıflar.

Betimsel bir örnek: polyrepo kurulumunda, bir yapay zeka asistantan API uç noktasını refaktörlemesini istediğinizde ve bu aynı zamanda paylaşılan tipi etkiliyor, araç tipik olarak her iki repoyu tek oturumda göremez. Siz Cursor penceresinize repo A eklersiniz, ama repo B erişim dışıdadır. Koordinasyonu elle yapıyorsunuz, bu tam olarak monorepo'nun ortadan kaldırması gereken yüktür. Monorepo'da aynı refaktoring bir konuşmadır. Yapay zeka tüm bağımlılıkları görür ve çoklu paket güvenli bir şekilde refaktör eder. Özellikle TypeScript projeleri için, bu verimlilik kazanımı kayda değerdir.

Bu kararı tamamen çevirmiyor. Ama küçük takımlar ve bağımsız geliştiriciler için polyrepo'nun tarihsel adlandırmalarından birini ortadan kaldırır ve kod gerçekten bağlı olduğunda monorepo'ya doğru varsayılanı hafifçe iter.

## Repoyu Bölmenin Zamanının Geldiğini Söyleyen Üç İşaret

Monorepo'yla başladınız. Güzel. Ama burada bölünmenin doğru çağrı olduğunu söyleyen somut işaretler var:

**Erişim kontrolü yüksüze çıkıyor.** Bir yüklenici ön uç erişimi istediğinde, arka uç değil. Ortak kaynaşma ekibi API şemanızı okumak ister ama özel değildir. GitHub'ın Codeowners hangi yolları gözden geçirebileceğini sınırlayabilir, ama okuma erişimini sınırlamaz. Okuma izolasyonu uyum veya güvenlik için önemliyse, ayrı repolar temiz cevaptır. Codeowners jimnastiği havuz düzeyi izinlerin yerini asla tamamen tutmaz.

**Tek bir hizmet içindeki CI hataları bağlantısız hizmetde dağıtımı bloke ediyor.** Eğer `payment-service`'deki kırık test kargo yapmak istediğiniz `marketing-site` içindeki hotfix'i sınırlandırıyorsa, monorepo'nuz kodbase'inizin olmadığı bağlantı oluşturuyor. Ya yapı yapılandırması düzeltilmeye ihtiyaç duyuyor (Turborepo ile görev kapsamı bunu çözecek), ya da iki hizmet gerçekten aynı repoda olmamışlıkları.

**Bir parça açık kaynak olacak diğeri değil.** Bu en temiz bölünme durumudur. Açık kaynak parçasını kendi genel repoya çıkarın. GitHub monorepo'sunda karışık genel/özel kod gerçekten acı: ayrı bir kuruluş veya kalıcı bakım yükü oluşturan manuel budlama işlemi gerekir.

## Çoğu Geliştirici Üzerine Iniş Yapan Pratik Kurulum

Tecrübeli geliştiricilerin benimsediği cevap: yapı etki alanı başına bir monorepo, "oluşturdunuz her şey için bir monorepo" değil ve "paket başına bir repo" değil.

Web ön ucu, bir API ve paylaşılan tip kütüphanesi olan SaaS oluşturuyorsanız, bu bir ürün. Tek monorepo'da tutun. Ayrıca diğer projeler kullanan açık kaynak CLI yardımcısı bakıyorsanız, bu farklı dinleyici ve sürüm döngüsüne sahip farklı bir repodur.

Hata monorepo/polyrepo seçimini ideolojik bir şey olarak ele almaktır. "Monorepo takımları" ile "polyrepo takımları" değil. Üç soruya dayalı yapısal karar: Hizmetleriniz arasındaki bağımlılık grafiği nedir? Kim neye erişim ihtiyacı duyuyor ve izolasyon önemli mi? CI/CD kurulum karmaşıklığına toleransınız nedir?

![Proje mimarisi kararlarını düşünen dizüstü bilgisayarda çalışan bağımsız geliştirici](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-09/0b60e1-img-3.webp)

Side projeler özelinde: pnpm workspace'leri (npm workspace'leri de çalışıyor, sadece daha az ergonomik) kullanarak monorepo'yla başlayın. Kurulum ilk gün, belki yarım saat. root package.json'ınıza bir workspaces alanı ekleyin ve her paket kendi package.json'ını tutsun. Typescript'i ayarlayın ve bu kadar. Turborepo'yu yalnızca CI düzenli olarak 4+ dakikaya vurmaya başladığında ekleyin, bu da ekstra bir gün değer verir. Ayrı repoya yalnızca somut bir nedeni olduğunda bölün: açık kaynak, erişim kontrolü, uyum veya farklı sürüm döngüsü olan ortak ekip. Mimari olarak daha temiz hissettirdiği için değil. Gerçek problem göründüğünde hareket edin.

Monorepo ve polyrepo tartışması çoğu bağımsız geliştiricinin cevabının aynı olduğu seçimlerden biridir: basit başlayın, spesifik sürtünme göründüğünde en iyileştirin. Bağlamı iyi tanıyın, sonra karar verin. İmleç hala yanıp sönüyor. İlk commiti gönderin ve ileriye doğru hareket edin.

## FAQ

### Monorepo, Cursor veya GitHub Copilot gibi yapay zeka kodlama araçları için daha mı iyidir?

Evet, genel olarak. Yapay zeka kodlama asistanları tam bağımlılık grafiğini tek bağlam penceresinde görebildiklerinde en iyi çalışırlar. Monorepo'da, Cursor gibi bir araç paylaşılan tipten tek oturumda her tüketiciye bir değişikliği izleyebilir. Polyrepo'da bu serviser arası bağlam eksik veya elle kurulum gerekir, koordinasyonu size geri koyar.

### Turborepo ve Nx arasında gerçek fark nedir?

Her ikisi de monorepo yapı yönetimi araçlarıdır ve bağımlılık grafik analizini kullanarak değişmememiş paketler için yapıları atlar. Turborepo yapılandırması daha basittir ve JavaScript/TypeScript projeleri için iyi çalışır. Nx daha zengin özellikli, gömülü üreteçler, proje grafik UI'u ve çoklu dil desteği ile. Yan proje için Turborepo genellikle doğru başlangıç noktasıdır.

### Polyrepo'dan monorepo'ya daha sonra geçebilir miyim?

Evet, ama yeterince bozucudur ki bunu kasıtlı yapmak isteyeceksiniz. İşlem her paketi workspace yapısına taşıyor, içe aktarmaları güncelliyor, CI boru hatlarını ayarlıyor ve isteğe bağlı olarak git subtree veya git-filter-repo kullanarak git tarihçesini yeniden yazıyor. Bunu yapan çoğu takım değer bulmuş olduğunu söylüyor, ama önemli boyutlu proje için minimum iki veya üç gün bütçesi ayırın.

### Büyük şirketler monorepo kullanıyor mu?

Google, Meta, Microsoft ve Twitter'ın tamamı tarihçede ana kod tabanları için monorepo kullanmış. Uber'ın iOS ve Android takımları özellikle serviser arası koordinasyon yükünü azaltmak için monorepo'ya geçti. Yani, bu şirketlerin kullandığı araçlar (Bazel, Buck, Pants) bağımsız geliştiricinin ihtiyaç duyduğundan çok daha karmaşıktır. Turborepo ve pnpm workspace'leri altyapı yükü olmadan faydaların %95'ini kapsar.

### Monorepo, Vercel veya diğer platformlara nasıl dağıtmamı etkiler?

Çoğu modern platform monorepo'yu yerli olarak destekler. Vercel her proje başına kök dizin belirtmenize izin verir, bu yüzden packages/web dağıtırken monorepo köküne yapı komutu gösterebilirsiniz. Netlify ve Railway benzer desteğe sahip. Yapılandırma on dakika sürer ve zaten sahip olduğunuz altyapının ötesinde hiçbir şey gerektirmez.

### Bağımsız geliştirici ilk günden Turborepo kurması gerekir mi?

Zorunlu değil. Paylaşılan paket faydaları için pnpm workspace'leriyle başlayın. CI düzenli olarak üç ila dört dakikadan fazla sürmek başladığında Turborepo ekleyin, ya da yerel yapıları hızlandırmak için uzaktan önbellekleme istediğinizde. Existing workspace kurulumuna Turborepo eklemek yaklaşık otuz dakika sürer, bu yüzden bekleme yaparak kendini kilitlemiyorsunuz.

### Yazılım mimarisi seçerken monorepo veya polyrepo'yu ne zaman seçmeliyim?

Bağımlılık grafiğine bakın: paketler gerçekten kod paylaşıyor mu? Erişim kontrolü önemli mi? CI/CD maliyeti ne kadar? Çoğu yan proje monorepo'yla başlayıp basit kalır. Açık kaynaklama, uyum, ya da ortak ekip ihtiyacı gibi somut sorunlar ortaya çıkacaksa o zaman, yalnızca o zaman bölün. Teknik olarak daha temiz hissettirdiği için değil.