Dal Nedir ve Neden Kullanılır?

Dal, belirli bir commit’i gösteren hareketli bir işaretçidir. Yeni dal oluşturulduğunda Git bütün proje dosyalarını fiziksel olarak kopyalamaz; yalnızca commit geçmişinde yeni bir referans meydana getirir. Bu nedenle dal oluşturmak hızlı ve düşük maliyetlidir.

Bir projenin commit kümesini $C$, belirli bir dalın erişebildiği commit’leri ise $B$ ile gösterirsek dal şu şekilde düşünülebilir:

Her yeni commit, aktif dalın işaretçisini ileri taşır. Ana dal yerinde kalırken özellik dalı kendi geçmişini oluşturur. Böylece yarım kalan kod, üretime gönderilmeye hazır kodla karışmaz.

git switch -c feature/arama

Bu komut feature/arama adında yeni bir dal oluşturur ve çalışma alanını o dala geçirir. Burada yapılan commit’ler main dalını doğrudan etkilemez.

Yaygın Dallanma Stratejileri

Her ekip aynı geliştirme temposuna sahip değildir. Haftada birkaç kez sürüm çıkaran küçük bir web ekibiyle, aylar süren kurumsal sürümler hazırlayan ekip aynı modeli kullanmak zorunda değildir.

GitHub Flow

Geliştirici main üzerinden bir özellik dalı açar, değişikliklerini gönderir ve pull request oluşturur. Kod incelemesiyle otomatik testler tamamlandıktan sonra dal birleştirilir. Küçük ekipler için bürokrasisi az, kullanışlı bir seçenektir.

Git Flow

Git Flow’da main üretimdeki kararlı kodu, develop ise sıradaki sürümün birleşim alanını temsil eder. Özellikler feature, sürüm hazırlıkları release, acil üretim düzeltmeleri ise hotfix dallarında yürütülür. Düzenlidir; ancak çok sık dağıtım yapan ekiplerde dal trafiği küçük bir otoyol kavşağına dönüşebilir.

Trunk-Based Development

Bu yaklaşımda geliştiriciler değişiklikleri sık aralıklarla ana gövdeye entegre eder. Dallar varsa bile birkaç saat veya gün yaşar. Tamamlanmamış özellikler, feature flag kullanılarak kullanıcıdan gizlenebilir.

Entegrasyon riski kabaca dalın ömrü ve değişiklik büyüklüğüyle artar:

Burada $R$ risk, $T$ dalın yaşam süresi, $D$ ise değişiklik miktarıdır. Uzun yaşayan ve yüzlerce dosyayı değiştiren dallar, birleştirme çatışmalarını büyütür.

Güvenli Bir Çalışma Akışı

git switch main
git pull --ff-only
git switch -c fix/sepet-toplami

# Değişikliklerden sonra
git add .
git commit -m 'Sepet toplamı hesaplamasını düzelt'
git push -u origin fix/sepet-toplami

İlk iki komut güncel ana dalı temel almayı sağlar. Ardından hata düzeltme dalı açılır, değişiklikler commit edilir ve uzak depoya gönderilir. Son aşamada pull request açılarak test, inceleme ve onay süreçleri işletilir.

İyi Dal Kullanımının Kuralları

• Dallara feature/, fix/ veya hotfix/ gibi anlaşılır adlar verin.
• Tek dalda birbiriyle ilgisiz değişiklikleri biriktirmeyin.
• Dalları kısa ömürlü tutun ve ana dalla düzenli olarak senkronize edin.
• Birleştirmeden önce otomatik testleri çalıştırın.
• Tamamlanan uzak dalları silerek depo görünümünü temiz tutun.
• Ana dalı koruma kurallarıyla doğrudan gönderimlere kapatın.

Dallanma, yalnızca bir Git komutu değil, ekip içi risk yönetimi yöntemidir. Doğru strateji seçildiğinde geliştiriciler daha cesur deneyler yapar, hatalar daha kontrollü düzeltilir ve ana kod tabanı üretime hazır kalır. En iyi model en karmaşık olan değil; ekibin sürüm sıklığına, büyüklüğüne ve otomasyon seviyesine en iyi uyum sağlayandır.

``

Sabit Dizi ile Dinamik Vektör Arasındaki Fark

Sabit bir dizinin boyutu oluşturulurken belirlenir ve sonradan değiştirilemez. Daha fazla elemana ihtiyaç duyulursa daha büyük bir alan ayırmak, eski elemanları kopyalamak ve önceki alanı serbest bırakmak gerekir. Vektör bütün bu işleri otomatikleştiren bir soyutlamadır.

Vektör nesnesinin kendisi stack üzerinde bulunabilir; ancak elemanların tutulduğu büyük ve bitişik bellek bloğu heap üzerinde ayrılır. Nesne genellikle üç önemli bilgi taşır: veri bloğunun adresi, mevcut eleman sayısı ve ayrılmış toplam kapasite.

Boyut ve Kapasite Aynı Şey Değildir

Vektörün size değeri gerçekten kullanılan eleman sayısını, capacity değeri ise yeniden bellek ayırmadan saklayabileceği eleman sayısını gösterir. Her eklemede bellek istemek pahalı olacağı için kapasite çoğunlukla ihtiyaçtan büyük tutulur.

Kapasite dolduğunda daha büyük bir blok ayrılır. Yaygın büyüme stratejilerinden biri kapasiteyi yaklaşık iki katına çıkarmaktır:

Ardından mevcut elemanlar yeni alana kopyalanır veya taşınır, eski heap bloğu serbest bırakılır ve yeni eleman eklenir. Bu yeniden yerleştirme tek seferde $O(n)$ maliyetli olsa da her eklemede gerçekleşmez. Bu nedenle sona ekleme işleminin amortize edilmiş zaman karmaşıklığı $O(1)$ kabul edilir.

C++ ile Vektörü Gözlemlemek

Aşağıdaki örnek, eleman eklendikçe boyut ve kapasitenin nasıl değiştiğini gösterir:

#include <iostream>
#include <vector>

int main() {
    std::vector<int> sayilar;

    for (int i = 1; i <= 10; ++i) {
        sayilar.push_back(i * 10);
        std::cout << "Boyut: " << sayilar.size()
                  << ", Kapasite: " << sayilar.capacity()
                  << '\n';
    }
}

push_back, elemanı sona ekler. Kapasite yeterliyse işlem doğrudan yapılır. Yeterli değilse yeni heap alanı ayrılır ve elemanlar taşınır. Kapasitenin büyüme oranı C++ standardında kesin olarak belirtilmediğinden sonuç kullanılan kütüphane uygulamasına göre değişebilir.

Önceden Yer Ayırmak

Kaç eleman ekleneceği yaklaşık olarak biliniyorsa reserve kullanmak gereksiz yeniden ayırmaları önler:

std::vector<int> puanlar;
puanlar.reserve(1000); // En az 1000 elemanlık kapasite hazırlar.

for (int i = 0; i < 1000; ++i) {
    puanlar.push_back(i);
}

reserve, vektörün boyutunu değiştirmez; yalnızca kapasite ayırır. Buna karşılık resize, eleman sayısını değiştirir ve gerekirse yeni elemanlar oluşturur.

Dikkat: İşaretçiler Geçersizleşebilir

Yeniden bellek ayırma gerçekleştiğinde eski bloğu gösteren işaretçiler, referanslar ve iterator’lar geçersiz hale gelebilir. Artık tahliye edilmiş bir evin adresine kargo göndermek gibi düşünün: adres tanıdık görünür, fakat içeride kimse yoktur.

Vektörler hız, bitişik bellek düzeni ve esneklik arasında güçlü bir denge kurar. Yine de bu rahatlığın arkasında kapasite fazlası, taşıma maliyeti ve referans geçersizleşmesi bulunur. size, capacity, reserve ve yeniden ayırma mantığını bilmek, dinamik koleksiyonları yalnızca kullanmayı değil, verimli ve güvenli kullanmayı sağlar.

Git neyi çözer?

Git, dağıtık versiyon kontrol sistemidir. Projenin yalnızca son durumunu değil, belirli zamanlarda kaydedilen sürümlerini de saklar. Her geliştiricide deponun geçmişini içeren yerel bir kopya bulunur. Böylece internet bağlantısı olmadan commit oluşturulabilir ve geçmiş incelenebilir.

Bir dosyanın Git içindeki yolculuğu üç temel alandan geçer:

Bir commit, projenin tamamının gelişigüzel kopyası değildir. Git içerikleri nesneler ve referanslar üzerinden verimli biçimde izler. Basitleştirilmiş olarak bir commit’i şöyle düşünebiliriz:

Burada $D_n$ dosya durumunu, $C_{n-1}$ önceki commit’i, $M_n$ açıklama ve yazar gibi meta verileri, $H$ ise özetleme fonksiyonunu temsil eder. Bu bağlantılı yapı geçmişin tutarlı biçimde takip edilmesini sağlar.

Git kurulumu

Windows kullanıcıları Git’i git-scm.com üzerinden indirebilir. Kurulum sihirbazındaki varsayılan seçenekler çoğu kullanıcı için uygundur. macOS üzerinde resmi yükleyici veya Homebrew, Linux üzerinde ise dağıtımın paket yöneticisi kullanılabilir.

# macOS
brew install git

# Ubuntu ve Debian
sudo apt update
sudo apt install git

Kurulumdan sonra kullanıcı bilgileri bir kez yapılandırılır. Bu bilgiler commit’lerin kime ait olduğunu belirtir:

git config --global user.name 'Ada Geliştirici'
git config --global user.email 'ada@example.com'

Terminal kullanmak istemiyorsanız bu ayarları VS Code içindeki Settings ekranından git config aramasıyla veya Git istemcisinin kurulum aşamasında belirleyebilirsiniz. Kurulumu doğrulamak için VS Code’u yeniden başlatmak önemlidir.

VS Code ile depo oluşturma

Proje klasörünü VS Code’da açın ve sol kenar çubuğundaki dallanma simgesine, yani Source Control görünümüne tıklayın. Klasör henüz Git tarafından izlenmiyorsa Initialize Repository düğmesi görünür. Bu düğme, klasörde gizli bir .git dizini oluşturarak yerel depoyu hazırlar.

Bir dosyayı değiştirdiğinizde Changes bölümünde listelenir. Dosyaya tıklamak, eski ve yeni hâli yan yana gösteren karşılaştırma ekranını açar. Satırların anlamı oldukça görseldir:

Commit’e eklenecek dosyanın yanındaki + simgesine basarak dosyayı Staged Changes alanına taşıyın. Üstteki kutuya Kullanıcı giriş ekranını ekle gibi açıklayıcı bir mesaj yazın ve Commit düğmesine basın. İyi bir commit tek bir mantıksal değişikliği kapsamalıdır; yüz farklı işi aynı pakete doldurmak, gelecekteki size bırakılmış bir bilmece olur.

GitHub ile eşitleme

VS Code’daki Publish Branch veya Publish to GitHub seçeneği, yerel depoyu GitHub’a göndermeyi kolaylaştırır. İlk kullanımda tarayıcı üzerinden GitHub hesabına giriş izni istenir. Sonrasında Sync Changes düğmesi iki işlemi yönetir:

• Push: Yerel commit’leri uzak depoya gönderir.
• Pull: Uzak depodaki yeni commit’leri bilgisayara getirir.

Dallar arasında geçmek için pencerenin sol altındaki dal adına tıklayabilirsiniz. Yeni özellikleri ayrı bir dalda geliştirmek, ana sürümü korur. Çakışma oluşursa VS Code; mevcut değişikliği, gelen değişikliği veya ikisini birlikte kabul etme seçenekleri sunar.

Son olarak .env, parola, derleme çıktıları ve node_modules gibi gereksiz ya da gizli içerikleri .gitignore dosyasına ekleyin. Böylece görsel araçların rahatlığıyla güvenli ve düzenli bir sürüm geçmişi oluşturabilirsiniz.

Merge Mantığı: İki Geçmiş, Tek Sonuç

Bir dal, belirli bir commit’ten başlayan bağımsız geliştirme çizgisidir. Örneğin main üretime hazır kodu taşırken feature/login yeni giriş ekranını içerebilir. Özellik tamamlandığında hedefimiz, feature dalındaki commit’leri main dalına aktarmaktır.

Commit geçmişini yönlü bir grafik gibi düşünebiliriz. Her commit bir düğüm, ebeveyn bağlantıları ise kenardır. İki dalın ortak atasını $B$, dal uçlarını $M$ ve $F$ olarak gösterirsek üç yönlü birleştirme şu değişimleri karşılaştırır:

Git, $\Delta_M$ ile $\Delta_F$ değişikliklerini uyumlu biçimde uygulayabiliyorsa merge otomatik tamamlanır. Aynı bölge farklı şekillerde değiştirilmişse karar kullanıcıya bırakılır.

Temel Bir Merge İşlemi

Önce hedef dala geçilir, güncel durum alınır ve kaynak dal birleştirilir:

git switch main
git pull origin main
git merge feature/login

Burada önemli ayrıntı şudur: feature/login, içinde bulunduğumuz main dalına eklenir. Git temiz bir birleştirme yaparsa işlem tamamdır. Takım politikasına göre dal daha sonra silinebilir:

git branch -d feature/login

Conflict Neden Oluşur?

Diyelim ki iki geliştirici aynı fonksiyonun dönüş mesajını değiştirdi. Git hangi mesajın iş kuralını doğru temsil ettiğini bilemez. Dosyada şu işaretleri bırakır:

<<<<<<< HEAD
return "Ana daldaki mesaj";
=======
return "Özellik dalındaki mesaj";
>>>>>>> feature/login

<<<<<<< HEAD mevcut dalın, >>>>>>> feature/login ise birleştirilen dalın içeriğini gösterir. Ortadaki ======= iki sürümü ayırır. Çözüm, işaretleri silip doğru nihai kodu oluşturmaktır; seçeneklerden birini körü körüne seçmek zorunlu değildir.

Örneğin iki fikri birleştiren sonuç şöyle olabilir:

function loginMessage(username) {
  return `Hoş geldin ${username}, giriş başarılı!`;
}

Ardından çözüm Git’e bildirilir:

git add src/login.js
git commit -m "Resolve login message conflict"

Tüm çakışmaları görmek için git status, yapılan düzenlemeyi incelemek için git diff kullanılabilir. Yanlış yola girildiyse git merge --abort, çalışma alanını merge öncesi duruma döndürür.

Güvenli Çözüm Stratejisi

Conflict çözmek yalnızca sözdizimini düzeltmek değildir; iki değişikliğin niyetini anlamaktır. Önce çakışan commit’leri ve ilgili gereksinimleri inceleyin. Ardından küçük parçalar hâlinde düzenleme yapın, testleri çalıştırın ve davranışın korunduğunu doğrulayın.

Son olarak merge commit’ini uzak depoya göndermeden önce uygulamayı derlemek ve test paketini çalıştırmak gerekir. Unutmayın: Git satırları birleştirir, fakat ürün davranışının doğru olup olmadığına karar veremez. Başarılı conflict çözümü; araç bilgisi, iletişim ve biraz da kod dedektifliği gerektirir.

``

Yerel ve Uzak Depo Mantığı

Git ile çalışırken aslında birbirinden bağımsız iki depo bulunur:

• Yerel depo (local repository): Bilgisayarımızdaki proje geçmişidir.
• Uzak depo (remote repository): Ekibin ortak kullandığı sunucu kopyasıdır.

Dosyayı kaydetmek, değişikliği otomatik olarak uzak sunucuya göndermez. Önce değişiklik çalışma alanında oluşur, ardından git add ile hazırlama alanına alınır ve git commit ile yerel geçmişe kaydedilir. Ancak bundan sonra git push kullanılarak uzak depoya aktarılabilir.

Bu akışı basitçe şöyle gösterebiliriz:

Senkronizasyon durumunu kabaca bir fark denklemiyle de düşünebiliriz:

$Fark > 0$ ise gönderilecek yerel commit’lerimiz vardır. $Fark < 0$ ise uzak depoda henüz almadığımız güncellemeler bulunabilir. Gerçekte Git yalnızca sayıları değil, commit’ler arasındaki yönlü geçmiş ilişkisini inceler.

Push ve Pull Karşılaştırması

Değişiklikleri Uzak Sunucuya Göndermek

Aşağıdaki komutlar tamamlanan bir özelliği kaydeder ve main dalına gönderir:

git status
git add .
git commit -m "Kullanıcı profil ekranını ekle"
git push origin main

git status, hangi dosyaların değiştiğini gösterir. git add ., değişiklikleri hazırlama alanına taşır. git commit, bu aşamanın yerel anlık görüntüsünü oluşturur. Son komuttaki origin, uzak deponun yaygın takma adı; main ise gönderilecek daldır.

İlk gönderimde dalın takip ilişkisini kurmak gerekebilir:

git push -u origin feature/profil

-u seçeneği yerel dalı uzak dalla ilişkilendirir. Sonraki işlemlerde yalnızca git push yazmak çoğunlukla yeterli olur.

Güncellemeleri Çalışma Alanına Çekmek

Ekip arkadaşımız uzak depoya yeni commit gönderdiyse bunları şu şekilde alabiliriz:

git switch main
git pull origin main

git pull, perde arkasında iki işi birlikte gerçekleştirir:

Önce fetch uzak geçmişi indirir, ardından merge bu geçmişi mevcut dalımızla birleştirir. Süreci daha kontrollü yürütmek isteyenler iki adımı ayrı çalıştırabilir:

git fetch origin
git log --oneline main..origin/main
git merge origin/main

Buradaki git log, uzakta bulunan fakat yerel main dalında olmayan commit’leri gösterir. Böylece neyi birleştirdiğimizi önceden görebiliriz.

Çakışmalar ve Sağlıklı Akış

Aynı dosyanın aynı satırları iki kişi tarafından değiştirilmişse Git hangi sürümün doğru olduğuna karar veremez ve conflict oluşturur. Çakışmalı bölümler elle düzenlenir, test edilir ve yeniden commit edilir:

git add duzeltilen-dosya.js
git commit -m "Birleştirme çakışmasını çöz"
git push

Sağlıklı bir ekip akışında güne git pull ile başlamak, küçük ve anlamlı commit’ler oluşturmak, push öncesinde testleri çalıştırmak ve doğrudan main yerine özellik dalları kullanmak faydalıdır. Kısacası pull dinlemeyi, push konuşmayı temsil eder. İyi bir Git kullanıcısı ise yalnızca konuşmaz; önce ekibin en güncel hâlini dinler.

Git’in temel yaklaşımı: Anlık fotoğraflar

Git çoğu zaman yalnızca satır satır farkları saklayan bir araç gibi düşünülür. Oysa temel modeli snapshot, yani anlık fotoğraf yaklaşımıdır. Commit oluşturulduğunda Git, izlenen dosyaların o andaki durumunu temsil eden bir kayıt üretir. Değişmeyen dosyalar için mevcut nesneler yeniden kullanılabildiğinden bu yöntem düşündüğünüzden daha verimlidir.

Her commit; proje ağacına, yazara, tarihe, açıklama mesajına ve genellikle bir önceki commit’e referans verir. Böylece commit’ler birbirine bağlanarak bir tarihçe oluşturur:

Burada $S_n$ proje fotoğrafını, $P(C_{n-1})$ önceki commit referansını, $M_n$ mesajı ve $A_n$ yazar bilgilerini temsil eder. İçeriğin özeti alınarak commit kimliği üretilir. Bu nedenle geçmişteki bir kaydın içeriği değiştirilirse kimliği de değişir.

Üç çalışma alanını anlamak

Git kullanımındaki karışıklıkların büyük bölümü çalışma dizini, staging area ve repository ayrımının bilinmemesinden kaynaklanır.

git add, değişikliği doğrudan tarihçeye kaydetmez. Yalnızca bir sonraki fotoğrafa hangi düzenlemelerin gireceğini belirler. Bu ara katman, aynı anda yaptığınız ilgisiz değişiklikleri ayrı commit’lere bölmenizi sağlar.

İlk anlamlı commit akışı

Aşağıdaki komutlar yeni bir depo oluşturur, durumu inceler ve seçilen değişiklikleri kaydeder:

git init
git status
git add README.md src/app.js
git diff --staged
git commit -m "Kullanıcı giriş doğrulamasını ekle"

git diff --staged, commit oluşturulmadan önce sahnelenen içeriği gösterir. Bu küçük kontrol, yanlışlıkla şifre, geçici dosya veya ilgisiz kod kaydetme riskini azaltır. Commit sonrasında git log --oneline ile kısa tarihçe görüntülenebilir.

git log --oneline --decorate
git show HEAD

git show HEAD, son commit’in bilgilerini ve değişikliklerini incelemek için kullanılır. Buradaki HEAD, üzerinde çalıştığınız güncel commit’i işaret eder.

İyi commit mesajı ne anlatır?

“Değişiklik yaptım” veya “son düzeltme” gibi mesajlar gelecekte kimseye yardımcı olmaz. İyi bir mesaj, kodda görülebilen ayrıntıyı tekrarlamak yerine değişikliğin amacını açıklar.

Mesajın emir kipinde, kısa ve odaklı olması okunabilirliği artırır. Büyük bir commit içinde özellik, biçimlendirme ve hata düzeltmesi karıştırmak yerine her mantıksal işi ayrı kaydetmek daha sağlıklıdır.

Commit atmadan önce mini kontrol

Önce git status ile kapsamı, ardından git diff ile değişiklikleri inceleyin. İlgili testleri çalıştırın, yalnızca aynı amacı taşıyan dosyaları staging area’ya ekleyin ve “Bu commit neden var?” sorusunu cevaplayan bir mesaj yazın.

Commit’i bir yedekleme düğmesi değil, gelecekteki geliştiriciye bırakılan açıklamalı bir zaman kapsülü olarak düşünün. Küçük, çalışır ve anlamlı commit’ler; hata ayıklamayı, kod incelemeyi ve gerektiğinde güvenli biçimde geçmişe dönmeyi ciddi ölçüde kolaylaştırır.

``

Yerel ve uzak depo nedir?

Yerel depo, bilgisayarındaki çalışma dosyalarını, commit geçmişini, dalları ve Git metadata’sını içeren depodur. Uzak depo ise genellikle internete bağlı bir sunucuda barındırılan ve ekip için ortak buluşma noktası görevi gören Git deposudur.

Git dağıtık bir sürüm kontrol sistemi olduğu için uzak sunucu, geçmişin tek sahibi değildir. Bir projeyi klonladığında commit geçmişinin tamamına yakın bir kopyasını alırsın. Başka bir deyişle yerel depo $L$, uzak depo $R$ ile gösterilirse klonlama sonrasında başlangıçta yaklaşık olarak şu ilişki kurulur:

Zamanla iki tarafta farklı commit’ler oluşabilir. Ayrışma miktarını basitçe şu şekilde düşünebiliriz:

Burada $C_L$ ve $C_R$ yerel ve uzak commit kümelerini, $\triangle$ ise iki küme arasındaki farklılığı temsil eder. fetch, pull ve push işlemleri bu farkı yönetmemizi sağlar.

Bir projeyi klonlamak

Var olan bir uzak projeyi bilgisayara indirmek için git clone kullanılır:

git clone https://github.com/kullanici/proje.git
cd proje

Bu komut yalnızca dosyaları indirmez. Commit geçmişini getirir, çalışma dizinini hazırlar ve uzak adresi varsayılan olarak origin adıyla kaydeder. Farklı bir klasör adı kullanmak da mümkündür:

git clone https://github.com/kullanici/proje.git benim-projem

HTTPS kolay başlangıç sunarken SSH, anahtar tabanlı kimlik doğrulamasıyla sık işlem yapan geliştiriciler için daha rahattır.

Yerel depoyu uzak sunucuya bağlamak

Bilgisayarında sıfırdan oluşturduğun bir projeyi uzak depoya bağlamak için önce serviste boş bir depo oluşturabilir, ardından şu komutları çalıştırabilirsin:

git init
git add .
git commit -m "İlk sürüm"
git branch -M main
git remote add origin git@github.com:kullanici/proje.git
git push -u origin main

git remote add origin ..., adrese origin takma adını verir. git push -u origin main ise yerel main dalını sunucuya gönderir ve takip ilişkisi kurar. Sonraki gönderimlerde çoğunlukla yalnızca git push yazmak yeterlidir.

Kayıtlı bağlantıları incelemek için:

git remote -v

Yanlış adres eklediysen bağlantıyı değiştirebilirsin:

git remote set-url origin yeni-adres
git remote remove origin

Fetch, pull ve push farkı

Bu üç komut benzer görünse de aynı işi yapmaz:

Özellikle ekip çalışmalarında önce git fetch çalıştırıp farkları incelemek daha kontrollü olabilir:

git fetch origin
git log --oneline main..origin/main
git pull --rebase origin main
git push origin main

Bu akış, uzaktaki commit’leri görmeni, değişiklikleri doğrusal bir geçmişle bütünleştirmeni ve ardından kendi commit’lerini paylaşmanı sağlar. Kısacası clone projeye giriş kapısı, remote adres defteri, fetch haberci, pull teslimatçı ve push ise kodunu buluta taşıyan kurye gibidir.

``

Neden kendi Git sunucumuz?

Git dağıtık bir sürüm kontrol sistemidir. Her geliştiricinin bilgisayarındaki depo, projenin geçmişini taşıyan bağımsız bir kopyadır. GitHub, GitLab veya Gitea ise bu depoların paylaşılmasını kolaylaştıran web tabanlı bir forge, yani yazılım geliştirme platformudur.

Kendi platformunu barındırmak veri üzerindeki kontrolü artırır fakat bakım sorumluluğunu da bize verir. Basit bir değerlendirme modeli şöyle kurulabilir:

Burada $T$ toplam sahip olma maliyetini, $K$ sunucu maliyetini, $B$ bakım emeğini, $G$ güvenlik çalışmalarını ve $Y$ yedekleme giderlerini temsil eder. Ücretsiz yazılım, sıfır maliyetli sistem demek değildir; sadece faturanın şekli değişir.

Platformların karşılaştırılması

GitLab, İsviçre çakısı gibidir: CI/CD, paket deposu, sorun takibi ve güvenlik taraması tek pakette gelir. Gitea ise cebinizdeki sağlam çakıdır; daha az kaynak tüketir ve temel işleri hızla tamamlar. Eğitim ortamında Gitea’ya Woodpecker CI eklenebilir veya GitLab CI kullanılarak her öğrenci gönderimi otomatik test edilebilir.

Docker Compose ile Gitea kurulumu

En az 2 GB RAM bulunan güncel bir Linux sunucu başlangıç için yeterlidir. DNS üzerinde git.ornek.com adresini sunucunun IP adresine yönlendirdikten sonra aşağıdaki compose.yaml dosyası hazırlanabilir:

services:
  gitea:
    image: gitea/gitea:latest
    restart: always
    ports:
      - 3000:3000
      - 2222:22
    volumes:
      - ./gitea-data:/data

Bu yapı, web arayüzünü 3000 ve Git SSH bağlantısını 2222 numaralı portta açar. Veriler gitea-data klasöründe kalıcı tutulur. Sistemi başlatmak için:

docker compose up -d
docker compose logs -f gitea

İlk komut konteyneri arka planda çalıştırır; ikincisi kurulum günlüklerini gösterir. Ardından tarayıcıdan http://sunucu-ip:3000 adresine gidilerek yönetici hesabı oluşturulur. Gerçek kullanımda Nginx veya Caddy ile ters vekil kurulmalı ve HTTPS etkinleştirilmelidir.

Güvenlik ve yedekleme

Bağımsızlık, “kur ve unut” anlamına gelmez. Yönetici hesabında iki faktörlü kimlik doğrulama kullanılmalı, kayıt özelliği gerekmedikçe kapatılmalı ve SSH erişimi anahtarlarla sınırlandırılmalıdır. Güncellemeler önce test ortamında denenmelidir.

Kullanılabilirlik yaklaşık olarak şu oranla ölçülebilir:

Yüzde 99 kullanılabilirlik iyi görünse de yılda yaklaşık 3,65 gün kesinti anlamına gelir. Bu nedenle veritabanı, depo dosyaları ve yapılandırmalar düzenli olarak farklı bir konuma yedeklenmelidir. Ayrıca geri yükleme işlemi denenmeyen yedek, Schrödinger’in yedeğidir: ihtiyaç anına kadar çalışıp çalışmadığı bilinmez.

Sonuç olarak kapsamlı DevOps süreçleri için GitLab, düşük kaynak tüketimi için Gitea veya Forgejo mantıklı seçimlerdir. Eğitim kurumları ise otomatik test, grup yönetimi ve sınıf şablonlarını merkeze almalıdır. Küçük bir sunucuyla başlayan bu yolculuk, kodun ve geliştirme kültürünün gerçekten size ait olduğu bağımsız bir ekosisteme dönüşebilir.

``

Jeneriklerin Temel Mantığı

Jenerik programlamada somut bir tip yerine tip parametresi kullanılır. Genellikle T, U, Element veya Value gibi isimlerle gösterilen bu parametre, kod kullanılırken gerçek bir tipe dönüşür.

Örneğin iki değerin yerini değiştiren işlemi her veri tipi için ayrı yazmak gereksizdir. Swift ile jenerik sürümü şöyle tanımlanabilir:

func yerDegistir<T>(_ ilk: inout T, _ ikinci: inout T) {
    let gecici = ilk
    ilk = ikinci
    ikinci = gecici
}

var x = 10
var y = 20
yerDegistir(&x, &y)

var ad1 = "Ada"
var ad2 = "Linus"
yerDegistir(&ad1, &ad2)

Buradaki T, çağrı sırasında Swift tarafından belirlenir. İlk çağrıda Int, ikinci çağrıda String olur. Fonksiyonun gövdesi ise yalnızca bir kez yazılmıştır.

Kod tekrarının yaklaşık maliyetini $C_{tekrar} = n \times m$ şeklinde düşünebiliriz. Burada $n$ desteklenen tip sayısı, $m$ ise her uygulamanın bakım maliyetidir. Jenerik yaklaşımda bu maliyet ideal olarak $C_{jenerik} \approx m$ seviyesine iner.

Jenerik ve Geleneksel Yaklaşım

Jenerikler, Any kullanmakla aynı şey değildir. Any, farklı tipleri kabul ederken tip hakkındaki bilgiyi büyük ölçüde çalışma zamanına bırakır. Jenerikler ise derleme zamanında gerçek tipi korur. Bu nedenle yanlış tip kullanımları program çalışmadan yakalanabilir.

Jenerik Yapılar

Bir yığın veri yapısı yalnızca sayılarla çalışmak zorunda değildir. Kitaplar, kullanıcılar veya uzay gemileri de aynı yığına eklenebilir; tabii aynı örnek içinde eleman tipi tutarlı olmak şartıyla.

struct Yigin<Element> {
    private var elemanlar: [Element] = []

    mutating func ekle(_ eleman: Element) {
        elemanlar.append(eleman)
    }

    mutating func cikar() -> Element? {
        elemanlar.popLast()
    }
}

var sayilar = Yigin<Int>()
sayilar.ekle(42)
sayilar.ekle(7)

var diller = Yigin<String>()
diller.ekle("Swift")
diller.ekle("Rust")

Element, yığının saklayacağı tipi temsil eder. Aynı yapı tanımıyla sınırsız sayıda tip için güvenli yığınlar oluşturulabilir.

Enum’larda Jenerik Gücü

Ağ işlemlerinde başarı durumunda veri, başarısızlık durumunda hata taşımak yaygın bir ihtiyaçtır. Jenerik enum bu iki değerin tipini dışarıdan alabilir:

enum APIResult<Success, Failure> {
    case success(Success)
    case failure(Failure)
}

struct User {
    let id: Int
    let name: String
}

enum NetworkError {
    case timeout
    case unauthorized
}

let result: APIResult<User, NetworkError> =
    .success(User(id: 1, name: "Grace"))

Bu model, başarılı sonucun User, hatanın ise NetworkError olduğunu açıkça belirtir. Böylece belirsiz sözlükler veya zorunlu tip dönüşümleri ortadan kalkar.

Tip Kısıtlamaları

Her jenerik işlem bütün tiplerle çalışamaz. Örneğin iki değerin eşitliğini kontrol etmek için tipin Equatable protokolüne uyması gerekir:

func ayniMi<T: Equatable>(_ sol: T, _ sag: T) -> Bool {
    sol == sag
}

print(ayniMi(5, 5))
print(ayniMi("Swift", "Kotlin"))

T: Equatable ifadesi, “Herhangi bir tip olabilir ama eşitlik karşılaştırmasını desteklemeli” demektir. Kısıtlamalar jenerikleri daraltmaz; aksine hangi yeteneklere güvenilebileceğini açıkça tanımlar.

Jenerikler doğru kullanıldığında kod tabanını küçültür, hataları derleme aşamasına taşır ve soyutlamaları güçlendirir. Ancak yalnızca bir yerde kullanılacak basit kodu gereksiz yere jenerikleştirmek okunabilirliği azaltabilir. Altın kural şudur: Aynı davranış birden fazla tip için gerçekten anlamlıysa jenerikler sahneye çıkmalı; aksi hâlde soyutlama pelerinini dolapta bırakmalıdır.

``

Kapanış neden sıradan bir fonksiyondan farklıdır?

Normal bir fonksiyon çoğunlukla yalnızca parametrelerine ve erişebildiği genel değerlere bağlıdır. Kapanış ise tanımlandığı kapsamın değişkenlerini yakalayabilir. Matematiksel açıdan sıradan bir fonksiyonu

şeklinde düşünürsek, dışarıdaki $a$ değerini yakalayan kapanış şu aileyi temsil eder:

Burada $a$, açıkça parametre olarak verilmemesine rağmen hesaplamanın parçasıdır. Kapanışın yanında taşıdığı bu çevresel bilgilere bazen closure environment denir.

Rust’ta bir kapanış çevresindeki değeri referansla ödünç alabilir, değiştirilebilir biçimde ödünç alabilir veya sahipliğini üstlenebilir. Derleyici buna göre kapanışı Fn, FnMut ya da FnOnce davranışlarından biriyle ilişkilendirir.

fn main() {
    let katsayi = 3;
    let carp = |sayi: i32| sayi * katsayi;

    println!("{}", carp(5)); // 15
}

Buradaki carp, katsayi değişkenini çevresinden yakalar. Böylece her çağrıda katsayıyı ayrıca göndermemiz gerekmez.

İteratör: Koleksiyon değil, üretim süreci

İteratör bir koleksiyonun kendisi değildir; sıradaki elemanın nasıl elde edileceğini tanımlayan bir mekanizmadır. Temel fikir, her adımda ya yeni bir değer ya da akışın bittiğini bildiren sonuç üretmektir.

$n$ elemanlı bir koleksiyon tek kez dolaşılıyorsa zaman karmaşıklığı çoğunlukla

olur. map, filter ve take gibi işlemlerin zincirlenmesi mutlaka her aşamada yeni bir koleksiyon oluşturmaz. Birçok dilde, özellikle Rust’ta, iteratörler tembeldir: Sonuç tüketilene kadar hesaplama başlamaz.

İkisini birlikte kullanalım

Aşağıdaki örnek çift sayıları seçer, dışarıdan yakalanan katsayıyla çarpar ve sonuçları toplar:

fn main() {
    let sayilar = vec![1, 2, 3, 4, 5, 6];
    let katsayi = 10;

    let toplam: i32 = sayilar
        .iter()
        .filter(|sayi| *sayi % 2 == 0)
        .map(|sayi| sayi * katsayi)
        .sum();

    println!("Toplam: {}", toplam); // 120
}

filter içindeki kapanış yalnızca çift değerleri geçirir. map kapanışı ise katsayi değişkenini yakalayarak değerleri dönüştürür. sum, tembel zinciri tüketen terminal işlem olduğu için gerçek hesaplama bu noktada gerçekleşir.

Aynı yaklaşım klasik bir döngüyle de yazılabilir; ancak iteratör zinciri “indeksi artır, elemana eriş, sonucu geçici değişkende tut” ayrıntılarını gizler. Böylece kod, mekanizmadan çok niyeti anlatır.

Ne zaman dikkatli olmalıyız?

Uzun ve iç içe kapanış zincirleri okunabilirliği azaltabilir. Yan etkiler, karmaşık hata yönetimi veya çok sayıda koşul varsa işlemleri isimlendirilmiş fonksiyonlara ayırmak daha sağlıklıdır. Ayrıca sahiplik kullanan dillerde move ile yakalanan bir değerin artık önceki kapsamda kullanılamayabileceği unutulmamalıdır.

Özetle kapanışlar davranışı veri gibi taşır, iteratörler ise veriyi kontrollü bir akışa dönüştürür. Birlikte kullanıldıklarında döngü yazmaktan fazlasını yaparız: Dönüşümleri birbirine bağlayan küçük ve güçlü bir işlem hattı kurarız.