Bir projeyi “bitti” diye işaretlemek kolay. Asıl mesele başka. O işi başkalarının da anlayacağı, kullanacağı ve güveneceği bir hale getirmek — işte bu bambaşka bir şey. Geçen ay Kadıköy’de bir ekip toplantısında tam bu konuyu tartışıyorduk; kod çalışıyordu ama repo dağınıktı, README yarım yamalaktı, sürüm etiketi yoktu… Hani ne farkı var diyorsunuz, değil mi? Yani o meşhur “çalışıyor ama anlatamıyor” durumu, hani hepimizin en az bir kere yaşadığı o his.
Şöyle söyleyeyim, İşin aslı şu: GitHub’daki son %1 çoğu zaman en görünmez kısım oluyor. Ama sahada farkı yaratan da tam o. Çünkü sadece çalışan bir kod yetmiyor arkadaşım — sürümün paketlenmiş olması lazım, izlenebilir olması lazım, yarın sabah biri geldiğinde “tamam, buradan devam ederim” diyebilmesi gerekiyor. Hmm, nasıl desem… Mutfakta yemeği pişirmek ayrı iş, masaya düzgün servis etmek ayrı iş, değil mi? Proje tarafında da durum birebir aynı — pişirmesini biliyorsun, servisi atlıyorsun.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Neden Son %1 Bu Kadar Önemli?
Garip gelecek ama, İlk kez 2023 yazında gördüm bunu, hem de çok net. Levent’te küçük bir SaaS ekibiyle çalışıyorduk — üç haftalık sprint bitmişti, herkes “yaptık, bitti” rahatlığıyla nefes almıştı, ama demo günü gelince her şey patladı. Versiyon karışmış, release note yok, kurulum adımları eski. Açık konuşayım: teknik borç genelde kodda saklanmıyor. Bazen sunumda, bazen dokümantasyonda, bazen de kimsenin dokunmadığı o dağınık repo yapısında gizlenip oturuyor.
“Done” ile “ready to ship” arasındaki fark… hmm, nasıl desem. Birincisi seni içten rahatlatıyor, ikincisi gerçekten para kazandırıyor — ya da en kötü ihtimalle can yakmıyor. Açık kaynakta bu ayrım çok daha sert hissettiriyor kendini,. Seni tanımayan biri repona geliyor, README’ye bakıyor, aradığını bulamazsa — gidiyor. Nokta. Seni ikna etmeni beklemiyor, ikinci şans vermiyor.
Peki gerçekten hazır mı proje? Şimdi dur bir saniye ve şunu düşün: sadece derleniyor olması yeterli mi? Sürüm belli mi? Geri alınabiliyor mu? Seni hiç tanımayan biri güvenip deploy edebilir mi? Kulağa sıkıcı geliyor, biliyorum — ama işin aslı şu: profesyonellik büyük ölçüde bu “sıkıcı” işleri usulüne uygun yapıp yapamamaktan ibaret zaten.
Bunu biraz açayım.
README ve About Bölümü: İlk İzlenim Bedava Değil
README. Herkesin bildiği, çoğunun es geçtiği o yer (kendi tecrübem). Ben de yıllar içinde bu hatayı birkaç kez yaptım açıkçası — lokalimde her şey kristal netliğinde görünüyordu, kafamdaki şema mükemmeldi, (inanın bana). Dışarıdan bakan biri için repo neredeyse kilitli bir kutu gibiydi, içine girmenin yolu gözükmüyordu. Sonra fark ettim: iyi bir README, şık bir satış broşürü gibi değil, hani daha çok “ambalajı düzgün olan bir kullanım kılavuzu” gibi olmalı. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
İşin garibi, Basit tut işi. Proje ne yapıyor? Neden var? Nasıl çalıştırılır? Bunlar yoksa — sorun var. Fazlası varsa zaten bonus, kimse şikayet etmez. Ama eksikse, o zaman gel başa. En çok da kurulum iki-üç komutla çözülmüyorsa, hani orada içimde küçük bir alarm çalıyor artık; “bir şeyler yanlış” diyorum. İnsanlar uzun uzun düşünmek, beş farklı dependency’yi tek tek çözmeye çalışmak istemiyor — hızlıca ayağa kaldırıp denemek istiyor, oldu oldu, olmadı geçti. Daha fazla bilgi için Chrome’da Birikmiş Yer İntihar Etmeden: Aftermark Ne Yapıyor? yazımıza bakabilirsiniz. Bu konuyla ilgili Zoxide ile Terminalde Kayıp Gitmemek: Hızlı Gezinme Rehberi yazımıza da göz atmanızı tavsiye ederim.
About kısmını hafife almayın
Şimdi burada bir şey söyleyeyim, çoğu geliştirici bunu duyunca şaşırıyor. GitHub’daki About alanı küçük görünüyor diye, “ne önemi var ki” deniyor. Yanlış. Tamamen yanlış. Bazen tek satırlık o kısa açıklama, doğru anahtar kelimeyi yakalayıp projenin keşfedilmesini sağlıyor — ne kadar da basit, değil mi? Geçen sene Berlin’den çalışan bir arkadaşım bunu özellikle optimize etti; yılda gelen katkı talebi sayısı şaşırtıcı biçimde artmıştı. Bir satır, ciddi fark.
İyi bir repo sadece kod deposu değildir; anlaşılabilirlik katmanı olmayan proje ise yarım kalmış demektir.
Dallar Karışmasın: Branch Disiplini ve Etiketler
Bak şimdi, Kulağa akademik geliyor, biliyorum. Branch hygiene — sanki bir botanik dersindeyiz gibi. Ama işin aslı, bu çok daha gündelik ve acı bir ihtiyaçtan çıkıyor. Ana dalınız kirlenirse, herkes kafasına göre commit atarsa, release günü “kim nerede ne yaptı” sorusu masaya geliyor — ve o soruyu sormaya başladığınızda güzel giden bir proje aniden berbat bir sabaha dönüşüveriyor.
Küçük startup’larda genelde hız baskısı var. “Aman şimdi kurallarla vakit kaybetmeyelim, ürünü çıkaralım önce” deniyor — tabi, anlıyorum, mantıklı bile geliyor o anda. Kurumsalda ise tam tersi uçta buluyorsunuz kendinizi: aşırı prosedür, onay katmanları, imzalar… İkisinin ortasında makul olan şu aslında: korunan ana dal, net bir PR akışı, bir de anlamlı tag sistemi (evet, doğru duydunuz). Bu kadar. Basit ama baya iş görüyor, ciddiye alın. Daha fazla bilgi için QuerySelector’ı Bıraktım: DOM’a Direkt Bağlanmak yazımıza bakabilirsiniz.
| Konu | Küçük ekip | Enterprise seviye |
|---|---|---|
| Branch stratejisi | Sade tutulur | Zorunlu onaylarla sıkılaştırılır |
| Release tagleri | `v1.2.0` yeterli olabilir | Sürüm notlarıyla birlikte otomatikleşir |
| Kurallar seti | Birkaç temel kural yeterli | Kapsamlı politika gerekir |
| Acil düzeltme akışı | Bazen manuel yönetilir | Ayrı hotfix hattı tercih edilir |
Tag koymak niye önemli?
Şöyle düşünün: sürüm etiketi yoksa geçmişe dönmek… Bir bakıma, hmm, nasıl desem… resmen arkeolojiye dönüşüyor. Bugün gayet iyi çalışan bir build’in üç hafta sonra hangi commit’e tekabül ettiğini bulmaya çalışmak istemezsiniz — ben Aralık 2024’te İstanbul’da tam olarak böyle bir repo kurtarma operasyonuna girdim, sabahın dördüne kadar git log çıktılarına baktım, branch geçmişini tersine mühendislikle çözmeye çalıştım. Açık konuşayım, hiç eğlenceli değildi. Hiç. Siz ne dersiniz? Tag koymak bu yüzden “küçük bir detay” falan değil — sonradan kendinize teşekkür ettiğiniz şeylerden biri.
Lisans Meselesi ve Güven Duygusu
Lisans konusu hep ikinci plana atılıyor. Önce heyecan var, sonra “onu sonra hallederiz” deniyor, sonra unutuluyor — ve işte tam orada bir sorun başlıyor farkında bile olmadan. Açık kaynakta lisans yoksa ne var? Belirsizlik. Belirsizlik de katkıyı öldürür, yavaş yavaş (belki yanılıyorum ama) ama emin adımlarla. Ben bunu defalarca gördüm; MIT gibi sade, anlaşılır lisansların giriş bariyerini nasıl düşürdüğünü, insanların “tamam, kullanabilirim” diye kolayca karar verebildiğini — çünkü kural açık, risk sıfır.
Bazı ekipler “nasıl olsa şirket içinde kullanıyoruz, kim ne diyecek” deyip geçiyor. Anlıyorum bu mantığı. Ama şöyle düşün — proje er ya da geç dışarı açılıyor, başka ekipler tüketmeye başlıyor, bir gün birisi “bunu ürünümüze koyabilir miyiz?” diye soruyor. İşte o noktada lisanssız repo tam anlamıyla baş ağrısına dönüşüyor. Hukuki detaylara gireyim mi? Hayır, o kadar sıkmayalım. Ama şunu net söyleyeyim: kullanıcıya sınırlarınızı açıkça anlatmıyorsanız, farkında olmadan güven yitiriyorsunuz. Bu kadar basit.
Pipeline Sağlığı ve Sürümlenmiş Çıktılar
Şimdi iş sadece etiket yapıştırmakla bitmiyor tabii. CI/CD kırılmışsa o etiket biraz duvar süsü oluyor, lafı gevelemeden söyleyeyim. Test ettiğim projelerde şunu net gördüm: yeşil pipeline görmek insanın omzundaki yükü gerçekten azaltıyor — fiziksel olarak bile hissediyorsunuz bunu. Tersine? Kırmızı build varsa herkes gergin. Haklı olarak.
Bence, Sürümlenmiş artifact üretmek de tam burada devreye giriyor işte. Tekrar üretilebilir build olmadan yarın aynı sürümü çıkaramazsınız — bu kadar basit. Bilhassa de de bağımlılıkların bir haftada üç kez değişebildiği Node.js ya da Python projelerinde, hmm, nasıl desem, bu konu gerçekten can yakmaya başlıyor; bağımlılık versiyonu kayar, build farklı çıkar, sonra “ama bizim makinede çalışıyordu” muhabbeti başlar (ki bu çoğu kişinin gözünden kaçıyor). Siz de saatlerce debug yaparsınız.
# Basit örnek akış
git tag v1.4.0
git push origin v1.4.x
# ardından CI:
# — test çalıştır
# — paket üret
# — artifact'i versiyonla
# — release notes'u yayınla
)Küçük ekipte pratik yaklaşım nasıl olur?
Bence, Küçük ekibiniz varsa fazla bürokrasi kurmadan ilerleyebilirsiniz, gerçekten. Tek bir checklist yeterli çoğu zaman:
- Tüm görevler Done’a taşındı mı? — bunu es geçmeyin
- README güncel mi?
- Sürüm numarası eklendi mi?
- Paket çıktısı doğrulandı mı?
Büyük organizasyonda ise — ve burada biraz ağırlaşıyor konu — imzalı artifact’ler, erişim politikaları, audit log’lar falan devreye giriyor; ilk bakışta “bu kadar şey şart mı” diyorsunuz, anlıyorum, ben de öyle dedim, ama ölçek büyüyünce mecburen gerekiyor bunlar. Yoksa gece üçte prod sorununa uyanan kişi siz olursunuz. Garanti.
Tamamlamak Yetmez, Anlatmak Da Gerekir
Bence en az konuşulan adımlardan biri bu. Yapılan işi görünür kılmak. Bir blog yazısı yazmak ya da kısa bir demo videosu çekmek, bazen —. Bunu söylerken biraz içim sızlıyor açıkçası — tamamen teknik bir iyileştirmeden çok daha etkili olabiliyor. Geçen yıl Maslak’taki bir — kendi adıma konuşayım — ürün ekibiyle tam da buna benzer bir şey yaptık; iç kullanım için hazırlanmış, kimsenin fazla umursamadığı bir araç vardı ortada, kısa bir demo videosu çektik, — bence çok yerinde bir karar —. Iki hafta içinde ekibin beklediğinin çok üzerinde geri bildirim geldi.
Neden video veya makale işe yarıyor?
Şöyle düşün: bir proje ne kadar iyi tamamlanmış olursa olsun, iki dakikada anlatılamıyorsa… hâlâ yarım hissettiriyor. İşte sorun tam da orada.
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.
