Git ve Sürüm Kontrolü: Kodunu Kaybetmeden Çalışmanın Yolu

Git, kod dosyalarındaki her değişikliği zaman içinde kaydeden ve gerektiğinde önceki bir noktaya geri dönmeyi mümkün kılan dağıtık bir sürüm kontrol sistemidir. Sürüm kontrolü ise genel olarak, bir projede kim, ne zaman, hangi değişikliği yaptı sorusuna net cevap veren; değişiklikleri kaybetmeden, üzerine yazmadan yönetme yöntemidir. Python veya Java ile ilk projelerini yazan bir öğrenci için bu, dosya isimlerini elle numaralandırmaktan kurtulup projenin tüm geçmişine güvenle erişebilmek anlamına gelir.

Bu rehberde sürüm kontrolünün neden gerekli olduğundan başlayıp, Git'in mantığına, temel kavramlarına ve günlük kullanımına kadar adım adım ilerleyeceğiz.

Sürüm Kontrolü Nedir ve Neden Gereklidir?

Yazılıma yeni başlayan hemen herkesin bir dönem uyguladığı bir yöntem vardır: dosyayı her önemli değişiklikten önce kopyalayıp farklı bir isimle kaydetmek. Sonuç genellikle şuna benzer bir klasör düzenidir: proje_final.py, proje_final_v2.py, proje_final_v2_son.py, proje_final_v2_son_gercek.py. İlk bakışta pratik görünen bu yöntem, proje büyüdükçe ciddi sorunlara yol açar.

Öncelikle, hangi dosyanın gerçekten "son" ve çalışan sürüm olduğunu birkaç gün sonra hatırlamak zorlaşır. İkinci sorun, bir değişikliği geri almak istediğinizde hangi dosyada hangi satırın değiştiğini karşılaştırmak için tüm dosyaları tek tek açıp gözle taramak gerekir; bu hem yavaş hem de hataya açık bir işlemdir. Üçüncü ve belki en can sıkıcı sorun ise bir ekip arkadaşınızla aynı dosya üzerinde çalıştığınızda ortaya çıkar: biri dosyayı e-posta ile gönderir, diğeri kendi değişikliklerini üzerine yazar ve az önce eklenen kod sessizce kaybolur.

Sürüm kontrolü tam olarak bu soruna çözüm üretmek için tasarlanmıştır. Mantık basittir: dosyaları elle kopyalamak yerine, her anlamlı değişiklik zaman damgalı ve geri dönülebilir bir kayıt olarak sisteme işlenir. Böylece proje, tek bir dosya yığını değil, birbirine bağlı kayıtlardan oluşan bir zincir hâline gelir; istenildiğinde zincirin herhangi bir noktasına dönmek mümkün olur.

Bunu günlük hayattan tanıdık bir örnekle düşünebilirsiniz: çoğu belge düzenleme programında bulunan "sürüm geçmişi" özelliği, bir metni kim ne zaman değiştirdi, hangi cümle silindi, hangi paragraf eklendi bilgisini otomatik olarak tutar ve istenirse eski bir sürüme dönülebilir. Sürüm kontrol sistemleri de kod için aynı işlevi görür, ancak çok daha ayrıntılı ve yazılım geliştirme sürecine özel araçlarla. Bir sonraki bölümde bu işi nasıl yaptığını ve neden Git'in bu alanda bu kadar yaygınlaştığını inceleyeceğiz.

Git Nedir? Dağıtık Sürüm Kontrol Sisteminin Mantığı

Git, sürüm kontrolünü dağıtık (distributed) bir mimariyle çözen bir araçtır. Bunun anlamı şudur: projeye katkı sağlayan her geliştiricinin bilgisayarında, projenin sadece güncel hâli değil, tüm geçmişinin tam bir kopyası bulunur. Bir dosyanın bir yıl önceki hâlini görmek istediğinizde uzak bir sunucuya bağlanmanıza gerek yoktur; bu bilgi zaten kendi bilgisayarınızdaki depoda (repository) mevcuttur.

Bu yapı, eski nesil merkezi sürüm kontrol sistemlerine kıyasla birkaç somut avantaj sağlar. İlk olarak, internet bağlantısı olmadan da commit almaya, geçmişi incelemeye ve dal (branch) oluşturmaya devam edebilirsiniz; bağlantı yalnızca değişiklikleri paylaşırken gereklidir. İkinci olarak, işlemlerin çoğu yerel diskte gerçekleştiği için Git günlük kullanımda oldukça hızlıdır. Üçüncü olarak, her geliştiricinin elinde projenin tam bir kopyası bulunduğundan, tek bir merkezi sunucunun çökmesi durumunda bile proje geçmişi kaybolmaz; bu da doğal bir yedeklilik sağlar.

Bu özellikler sayesinde Git, bireysel projelerden büyük ölçekli kurumsal yazılımlara kadar hemen her yazılım ekibinde standart bir araç hâline gelmiştir. Bir öğrencinin sadece "kod yazmayı" değil, "ekip hâlinde kod yazmayı" öğrenmesi gerektiğinde Git bilgisi, kaçınılmaz bir ön koşul olarak karşısına çıkar. Bu nedenle Python ve Java üzerine ilerleyen bir öğrencinin, dil bilgisine paralel olarak sürüm kontrolü alışkanlığını da erken kazanması önemlidir; Berk Akademi'nin birebir canlı yazılım dersleri kapsamında öğrenciler proje geliştirirken bu tür sektörel araçlarla da tanışır. Git'i sadece bir komut listesi olarak değil, bir çalışma disiplini olarak görmek, ilerleyen bölümlerde ele alacağımız commit, branch ve merge kavramlarını anlamlı kılan temeldir.

Commit, Branch ve Merge: Birbirine Bağlı Üç Temel Kavram

Git'i öğrenirken karşılaşılan üç kavram birbirinden ayrı düşünülemez; her biri diğerinin anlamını tamamlar.

Commit, projenin belirli bir andaki durumunun kaydıdır. Bir commit aldığınızda, o ana kadar yaptığınız değişiklikler projenin geçmişine kalıcı bir nokta olarak eklenir ve istenildiğinde bu noktaya geri dönülebilir. Burada önemli olan, commit'lerin küçük ve anlamlı olmasıdır: "bütün günün değişikliklerini tek commit'te toplamak" yerine, "kullanıcı girişi doğrulaması eklendi" gibi tek bir işi tanımlayan commit'ler almak, hem geçmişi okunabilir kılar hem de bir sorun çıktığında hatanın hangi değişiklikten kaynaklandığını bulmayı kolaylaştırır.

Branch (dal) ise projenin ana hattından ayrılan paralel bir çalışma alanıdır. Yeni bir özellik denemek veya riskli bir değişiklik yapmak istediğinizde, ana koddan bir kopya alarak kendi dalınızda çalışırsınız; bu sırada ana kod hiç etkilenmez. Bir deneme başarısız olursa dalı silip baştan başlayabilir, başarılı olursa değişiklikleri ana hatta aktarabilirsiniz. Bu, aynı anda birden fazla fikri güvenle test edebilmeyi sağlar.

Merge, işte bu paralel dalları tekrar bir araya getirme işlemidir. Bir branch üzerinde tamamlanan çalışma, merge işlemiyle ana koda entegre edilir ve o daldaki tüm commit geçmişi ana hatta taşınır. Commit ve branch kavramları olmadan merge'ün bir anlamı kalmaz: merge, ortada birleştirilecek ayrı bir geçmiş (branch) ve o geçmişi oluşturan kayıtlı adımlar (commit) olduğu için işe yarar. Bu üçlü birlikte, bir öğrencinin tek başına deneme yaparken bile projesini güvenle ilerletmesini, ekip çalışmasında ise farklı kişilerin aynı proje üzerinde çakışmadan çalışabilmesini mümkün kılar.

Yerel Depo ve Uzak Depo Farkı

Git ile çalışırken iki farklı "depo" kavramıyla karşılaşırsın: yerel depo (local repository) ve uzak depo (remote repository). Yerel depo, projenin tüm geçmişinin senin kendi bilgisayarında tutulduğu .git klasörüdür. İnternet bağlantısı olmadan da commit atabilir, branch oluşturabilir, geçmişi inceleyebilirsin; çünkü bu işlemlerin hiçbiri bir sunucuya ihtiyaç duymaz. Git'i diğer bazı sürüm kontrol sistemlerinden ayıran temel özelliklerden biri de budur: geçmişin tamamı, çalıştığın makinede zaten mevcuttur.

Uzak depo ise projenin bir kopyasının paylaşılan bir sunucuda tutulduğu yerdir. Bu sayede birden fazla kişi aynı projeye farklı bilgisayarlardan katkı verebilir veya tek başına çalışan bir geliştirici projesini yedekleyebilir. Sektörde bu amaçla en yaygın kullanılan araçlardan biri GitHub'dır; benzer işlevi gören başka barındırma servisleri de vardır. GitHub burada Git'in kendisi değil, Git depolarını internet üzerinden erişilebilir hâle getiren bir platformdur — ikisini karıştırmamak önemlidir.

Yerel ve uzak depo arasındaki senkronizasyon iki temel komutla sağlanır: push ve pull. git push, yerel depondaki commit'leri uzak depoya gönderir; böylece senin bilgisayarında yaptığın değişiklikler paylaşılan kopyaya yansır. git pull ise tam tersini yapar: uzak depoda başkalarının eklediği değişiklikleri senin yerel deponla birleştirerek günceller. Bu iki komut olmadan yerel ve uzak depo zamanla birbirinden kopar; ekip hâlinde çalışılan projelerde push ve pull'u düzenli aralıklarla kullanmak, herkesin aynı kod tabanı üzerinde ilerlediğinden emin olmanın en pratik yoludur.

Temel Git Komutları ve İşlevleri

Git'e yeni başlayanların çoğu, komutların çokluğu karşısında nereden başlayacağını şaşırır. Oysa günlük kullanımda ihtiyaç duyulan komut sayısı oldukça sınırlıdır. Aşağıdaki tablo, bir projeye başlarken ve ilerletirken en sık başvurulan komutları ve bunların ne zaman devreye girdiğini özetler.

Bu komutların birbirine nasıl bağlandığını görmek için küçük bir terminal akışına bakalım. Aşağıdaki örnek, bir klasörü Git deposuna çevirmekten yeni bir branch açıp ana dalla birleştirmeye kadar tipik bir döngüyü gösterir:

git init
git add dosya_adi.py
git commit -m "İlk proje yapısı eklendi"
git branch yeni-ozellik
git checkout yeni-ozellik
git add .
git commit -m "Yeni özellik: giriş fonksiyonu eklendi"
git checkout main
git merge yeni-ozellik

Bu akış hem Python hem de Java projelerinde aynı mantıkla işler; komutlar dil bağımsızdır, çünkü Git dosya içeriğiyle değil, dosyaların zaman içindeki değişimiyle ilgilenir.

Yeni Başlayanların Sık Yaptığı Git Hataları

Git'i öğrenirken teknik komutlardan çok, komutların nasıl kullanıldığı sorun yaratır. En yaygın hatalardan biri anlamsız commit mesajları yazmaktır. "update", "asdf", "değişiklik" gibi mesajlar commit anında hızlı görünse de birkaç hafta sonra geçmişe bakıldığında hangi commit'in ne işe yaradığını anlamayı imkânsız hâle getirir. Bir hata ayıklarken hangi commit'in soruna yol açtığını bulmak, commit mesajları anlamlıysa dakikalar, anlamsızsa saatler sürebilir.

İkinci sık hata, her şeyi tek bir branch üzerinde yapmaya çalışmaktır. Örneğin bir öğrenci hem yeni bir özellik eklerken hem de eski bir hatayı düzeltirken aynı dalda çalışırsa, iki bağımsız değişiklik iç içe geçer; biri geri alınmak istendiğinde diğerini de etkiler. Ayrı işler için ayrı branch açmak, her değişikliği izole tutar ve gerektiğinde sadece o dalı geri almayı mümkün kılar.

Üçüncü hata ise commit yapmadan uzun süre kod biriktirmektir. Bazı öğrenciler "işim bitince tek seferde commit atarım" diyerek günlerce değişiklik biriktirir. Bu yaklaşımın iki riski vardır: bilgisayarda beklenmedik bir sorun yaşanırsa saatlerce süren emek kaybolabilir, ayrıca tek seferde atılan dev bir commit, içinde hangi değişikliğin ne amaçla yapıldığını ayırt etmeyi zorlaştırır. Küçük, sık commit'ler hem daha güvenli hem daha okunabilirdir.

Bu tür alışkanlık hatalarının çoğu, kod yazarken fark edilmesi zor olan detaylardır ve genellikle bir başkasının geçmişine bakıp geri bildirim vermesiyle daha hızlı düzelir. Bu noktada birebir Python ve Java dersleri kapsamında öğrencinin gerçek proje geçmişi üzerinden commit alışkanlıklarının incelenmesi, bu hataların erken aşamada fark edilip düzeltilmesine katkı sağlar.

Python veya Java Projesinde Günlük Git Akışı

Git komutlarını tek tek bilmek yeterli değildir; bunları bir günlük çalışma düzenine oturtmak asıl fark yaratan şeydir. Bir Python veya Java projesinde sabah oturup kod yazmaya başladığınızda, Git'i arka planda sessizce çalışan bir güvenlik ağı gibi düşünebilirsiniz. Aşağıdaki terminal akışı, küçük bir Python dosyası üzerinde yeni bir özellik eklerken izlenebilecek gerçekçi bir sırayı gösterir:

git init
echo "def topla(a, b):
    return a + b" > hesap.py
git add hesap.py
git commit -m "hesap.py dosyasına topla fonksiyonu eklendi"
git branch cikarma-fonksiyonu
git checkout cikarma-fonksiyonu
echo "def cikar(a, b):
    return a - b" >> hesap.py
git add hesap.py
git commit -m "cikar fonksiyonu eklendi"
git checkout main
git merge cikarma-fonksiyonu

Aynı mantık bir Java projesinde de geçerlidir; tek fark dosya uzantısının .java olması ve derleme adımının araya girmesidir. Bu akışı sıraya koyduğunuzda ortaya şu adımlar çıkar:

1. Proje klasöründe git init ile deponun başlatılması
2. Kodda küçük ve anlamlı bir değişiklik yapılması (yeni fonksiyon, düzeltme, ekleme)
3. Değişikliğin git add ile staging alanına eklenmesi
4. Anlamlı bir mesajla git commit yapılması
5. Yeni özellik veya deneme için bir branch açılması
6. Geliştirmenin bu branch üzerinde sürdürülmesi ve gerektiğinde ayrı commit'lerle kayıt altına alınması
7. Değişiklik test edildikten sonra ana branch'e merge edilmesi

Bu döngüyü küçük projelerde bile tekrar tekrar uygulamak, kod yazma alışkanlığınızın bir parçası hâline gelir. Yeni başlayan bir öğrenci için bu tür pratik tekrarlar, teorik bilgiden çok daha kalıcıdır; bu yüzden birebir Python dersleri kapsamında öğrencilerin gerçek proje dosyaları üzerinde bu adımları defalarca uygulaması hedeflenir. Fonksiyonlar, sınıflar veya küçük modüller üzerinde bu akışı içselleştiren biri, ileride çok daha büyük kod tabanlarında da rahat hareket eder.

Git Sadece Ekip Projeleri İçin Değil, Bireysel Bir Alışkanlıktır

Git denince akla genellikle birden fazla kişinin aynı proje üzerinde çalıştığı senaryolar gelir; ancak tek başına çalışan bir öğrenci için de Git'in sağladığı fayda azımsanmayacak kadar büyüktür. Bir algoritmayı farklı bir yaklaşımla denemek istediğinizde, mevcut kodu bozma korkusu yaşamadan yeni bir branch açıp orada özgürce deneme yapabilirsiniz. Deneme işe yaramazsa o branch'i bırakıp ana koda geri dönmeniz yeterlidir; hiçbir şey kaybolmaz.

Bu alışkanlığın bir diğer faydası, öğrenme sürecinizin kendisini kayıt altına almasıdır. Her commit mesajı aslında "bu noktada neyi neden yaptım" sorusuna verilmiş küçük bir cevaptır. Zamanla geriye dönüp baktığınızda, bir konuyu nasıl kavradığınızı, hangi hataları yaptığınızı ve nasıl düzelttiğinizi adım adım görebilirsiniz. Özellikle branch ve merge gibi kavramlar ilk seferde tam oturmayabilir; bu noktada birebir Java dersleri gibi canlı içeriklerin kayıtlarına dönüp ilgili anlatımı tekrar izlemek, konuyu pratikle birlikte pekiştirmenin pratik bir yoludur. Ders kayıtlarına bir yıl boyunca sınırsız erişebilmek, tam da böyle "şu kavramı bir daha dinlemem lazım" dediğiniz anlarda işe yarar. Tek başına Git kullanmayı öğrenen bir öğrenci, ileride bir ekip projesine katıldığında ortak depo, pull request veya kod inceleme süreçlerine yabancılık çekmez. Çünkü commit atmak, branch açmak ve merge yapmak zaten günlük rutininin bir parçası hâline gelmiştir. Bu yüzden Git'i yalnızca "ekip çalışması aracı" olarak değil, kod yazan herkesin edinmesi gereken temel bir disiplin olarak görmek daha doğrudur.

Sık Sorulan Sorular

Git nedir, kısaca nasıl tanımlanır?

Git, kod dosyalarında yapılan değişiklikleri zaman içinde kayıt altına alan, dağıtık çalışan bir sürüm kontrol sistemidir. Her geliştiricinin bilgisayarında projenin tam geçmişiyle birlikte bir kopyası bulunur.

Sürüm kontrolü olmadan proje geliştirmek neden risklidir?

Sürüm kontrolü olmadan yapılan bir değişiklik geri alınamaz, hangi dosyanın ne zaman ve neden değiştiği izlenemez. Bu da özellikle hata ayıklarken veya eski bir sürüme dönmek gerektiğinde ciddi zaman kaybına yol açar.

Git ile GitHub arasındaki fark nedir?

Git, bilgisayarınızda çalışan sürüm kontrol yazılımının kendisidir. GitHub ise bu Git depolarını internet üzerinden barındırmaya, paylaşmaya ve ekiple ortak yönetmeye yarayan bir platformdur.

İyi bir commit mesajı nasıl yazılmalı?

İyi bir commit mesajı, yapılan değişikliği kısa ve net biçimde açıklar; "düzeltme" gibi belirsiz ifadeler yerine "kullanıcı girişindeki boş şifre hatası düzeltildi" gibi somut bir cümle tercih edilmelidir.

Branch ne zaman açılmalı, ne zaman merge edilmeli?

Yeni bir özellik eklerken veya riskli bir deneme yaparken ayrı bir branch açmak, ana kodu korumanın en güvenli yoludur. Değişiklik test edilip çalıştığından emin olunduğunda ana branch'e merge edilmelidir.

Tek başına çalışan bir öğrencinin Git öğrenmesine gerek var mı?

Evet; tek başına çalışan bir öğrenci bile Git sayesinde denemelerini güvenle yapabilir, öğrenme sürecini kayıt altına alabilir ve ileride bir ekip projesine geçtiğinde bu alışkanlıkla çok daha rahat uyum sağlar.

Git öğrenmeye nereden başlamalıyım?

En sağlıklı yol, küçük bir Python veya Java projesi üzerinde git init, add, commit, branch ve merge komutlarını sırayla deneyerek başlamaktır; teorik okumadan çok pratik tekrar bu konuda kalıcı öğrenme sağlar.

Git, ilk bakışta karmaşık görünen ama düzenli kullanıldıkça kod yazma alışkanlığınızın doğal bir parçası hâline gelen bir araçtır. Bu temel kavramları pratikle pekiştirmek isteyenler için canlı yazılım eğitimleri sayfasına göz atabilirsiniz.