Git ve Sürüm Kontrolü Nedir? Depo, Commit ve Branch Rehberi

Dosya geçmişinden Git deposuna: sürüm kontrolü neyi kaydeder?

Sürüm kontrolü, bir dosya veya dosya grubunda yapılan değişiklikleri zaman içinde izleyen sistemdir. Bu sistem yalnızca yedekleme amacı taşımaz. Değişikliğin ne zaman yapıldığını, hangi dosyaları etkilediğini ve commit mesajı sayesinde neden yapıldığını incelemeyi sağlar.

Git'te projenin sürüm kontrolü altına alınmış hâline depo (repository) denir. Yerel depo, bilgisayarınızdaki proje dosyalarıyla birlikte Git'in geçmişi yönettiği gizli .git klasörünü içerir. git init ile bir klasörde yeni depo başlatıldığında, Git bu klasördeki değişiklikleri takip edebilecek yapıyı oluşturur. Var olan bir uzak depoyu bilgisayara almak için ise git clone kullanılır; bu işlem projenin dosyalarıyla birlikte Git geçmişinin yerel bir kopyasını edinmeye yarar.

Git'in takip ettiği dosyalar için üç durumu ayırmak gerekir:

• Çalışma dizini: Bilgisayarınızda doğrudan düzenlediğiniz dosyaların bulunduğu alandır.
• Hazırlama alanı (staging area): Bir sonraki commit'e alınmasını istediğiniz değişiklikleri seçtiğiniz ara alandır.
• Commit geçmişi: Hazırlanan değişikliklerin açıklayıcı bir mesajla kalıcı olarak kaydedildiği geçmiş bölümüdür.

Bu ayrım, Git'i sıradan bir "kaydet" komutundan farklı kılar. Bir dosyada değişiklik yapmanız, o değişikliğin henüz commit edildiği anlamına gelmez. Önce git status ile durumu kontrol eder, git add dosya-adi ile ilgili dosyayı hazırlama alanına alır, ardından git commit -m "aciklayici mesaj" ile kaydedersiniz. git diff, henüz hazırlama alanına alınmamış değişiklikleri incelemek için; git log ise commit geçmişini görmek için kullanılabilir.

Bir commit, projenin belirli bir andaki durumuna ait kayıt ve açıklamadır. Git, geçmişi verimli tutmak için değişmeyen içerikleri yeniden saklamak yerine bunlara referans verebilir; bu nedenle commit'i her dosyanın bağımsız ve tam kopyası gibi düşünmek yerine projenin geçmişteki bir durumunu temsil eden kayıt olarak anlamak daha doğrudur.

Git'in dağıtık yapısı: yerel depo ile uzak depo arasındaki fark

Git, dağıtık sürüm kontrol sistemidir. Bunun anlamı, her geliştiricinin yalnızca güncel dosyaları değil, projenin Git geçmişini de içeren bir yerel depo kopyasına sahip olabilmesidir. Commit oluşturma, geçmişi inceleme ve çoğu karşılaştırma işlemi yerel bilgisayarda yapılabildiği için bu işlemler uzak sunucuya sürekli bağlanmaya bağlı değildir.

Uzak depo, yerel depodan ayrı bir konumda bulunan ve Git'in remote olarak tanımladığı depodur. Bu depo GitHub gibi çevrim içi bir hizmette bulunabileceği gibi yerel bir dosya yolunda veya başka bir sunucuda da bulunabilir. GitHub, GitLab ve Bitbucket bu depoları barındırmak için kullanılabilen hizmetlerdir; ancak bunlar Git'in kendisiyle aynı şey değildir. Yerel commit'lerin uzak depoya gönderilmesi git push ile yapılır. Uzak depodaki yeni commit'leri yerel çalışma akışınıza almak için git pull kullanılabilir. Daha kontrollü bir inceleme yapmak isteyenler önce git fetch ile uzak geçmişi alıp ardından birleştirme kararını kendileri verebilir.

Basit bir akış şöyledir:

1. Uzak depodaki güncel değişiklikler alınır.
2. Yerel dosyalarda yeni bir özellik veya hata düzeltmesi yapılır.
3. git status ve git diff ile değişiklikler kontrol edilir.
4. Uygun dosyalar git add ile hazırlanır.
5. Açıklayıcı bir commit oluşturulur.
6. Gerekli kontrollerden sonra commit git push ile uzak depoya gönderilir.

Dağıtık yapı önemli bir dayanıklılık sağlar; çünkü proje geçmişi tek bir bilgisayarda veya tek bir sunucuda bulunmak zorunda değildir. Bununla birlikte Git, otomatik bir yedekleme stratejisinin yerine geçmez. Uzak depoya hiç gönderilmemiş yerel commit'ler bilgisayar arızasında erişilemez hâle gelebilir. Ayrıca uzak depoda depolanan gizli anahtarlar, parolalar veya kişisel veriler de güvenlik riski oluşturabilir.

Branch ve merge ile ana projeyi bozmadan geliştirme

Branch (dal), commit geçmişinde bağımsız bir geliştirme yolu oluşturur. Yeni bir özellik, hata düzeltmesi veya deneysel değişiklik için ayrı branch açmak, henüz hazır olmayan çalışmanın ana dalı etkilemesini önlemeye yardımcı olur. Ana dalın adı projeye göre main veya başka bir ad olabilir; bu adın ne olduğu Git kavramının kendisiyle karıştırılmamalıdır.

Örnek bir işlem dizisi:

git switch -c menu-duzenle

Bu komut, menu-duzenle adında yeni bir branch oluşturup çalışma konumunu bu dala geçirir. Bazı Git kullanım biçimlerinde dal değiştirmek için git checkout da görülür. Dalda yapılan değişiklikler commit'lerle kaydedilir. Çalışma tamamlandığında test edilir ve ana dala alınmasına karar verilirse merge işlemi yapılır.

Ana dala geçmeden önce git branch --show-current veya git branch ile ana dalın adı kontrol edilir. Dal adı main olarak belirlenmişse git switch main; aksi durumda mevcut ana dalın adı kullanılır. Ardından:

git merge menu-duzenle

komutu, menu-duzenle dalındaki geçmişi ana dala entegre etmeyi dener. Değişiklikler birbirini etkilemiyorsa Git birleştirmeyi otomatik gerçekleştirebilir. Aynı dosyanın aynı bölümünde farklı değişiklikler yapıldıysa merge conflict, yani birleştirme çatışması oluşabilir.

Branch, dosyanın fiziksel bir kopyasını farklı adla saklamak anlamına gelmez. Daha doğru ifade, commit geçmişi üzerinde farklı bir referans veya çalışma yolu olduğudur. Bu ayrım, çok sayıda branch kullanan projelerde gereksiz kopya fikrinden kaçınmayı sağlar. Branch açmak tek başına kalite veya güvenlik garantisi de vermez; değişikliklerin test edilmesi ve ekip kurallarına göre incelenmesi gerekir.

Merge conflict oluştuğunda hangi dosya neden seçilir?

Birleştirme çatışması, Git'in iki değişikliği güvenli biçimde otomatik olarak birleştiremeyeceği durumda ortaya çıkar. En yaygın durum, iki branch'in aynı dosyanın aynı satırlarını farklı biçimde değiştirmesidir. Çatışma oluştuğunda Git, ilgili dosyada hangi bölümlerin çakıştığını işaretler; karar geliştiriciye bırakılır.

Çözüm adımları şöyledir:

1. git status çalıştırılarak çatışmalı dosyalar belirlenir.
2. Dosya açılır ve Git'in eklediği çatışma işaretleri incelenir. Bu işaretlerin üst ve alt kısmı farklı branch'lerdeki seçenekleri gösterir.
3. Projenin gereksinimine göre bir değişiklik seçilir, iki değişiklik birleştirilir veya ilgili bölüm yeniden yazılır.
4. Çatışma işaretleri dosyadan kaldırılır ve dosya çalışır durumda kaydedilir.
5. Çözülen dosya git add dosya-adi ile hazırlanır.
6. Birleştirme süreci, Git'in beklediği merge commit'i oluşturularak tamamlanır.

Buradaki karar yalnızca "hangi satır daha yeni" sorusuyla verilmez. İki değişiklik de gerekli olabilir veya bir tarafın değişikliği diğer tarafın varsayımını geçersiz kılabilir. Bu nedenle çatışma çözüldükten sonra ilgili kodu çalıştırmak, test etmek ve mümkünse değişikliğin sahibiyle kontrol etmek gerekir.

Çatışmayı çözmek, değişikliklerin doğru olduğu anlamına gelmez. Git yalnızca metinsel veya geçmişe dayalı birleştirme yapar; uygulamanın iş kuralının doğru olup olmadığını kendisi değerlendirmez. Örneğin iki branch ayrı ayrı çalışıyor olsa bile birleşimden sonra bir fonksiyonun beklediği veri biçimi değişmiş olabilir.

Çözümlü örnek: yeni bir web menüsünü branch ile eklemek

Verilenler: Bir web projesinde index.html ve style.css dosyaları vardır. Ana dalda çalışan sürüm korunacaktır. Menü görünümünü değiştiren çalışma ayrı bir branch'te yapılacaktır.

1. Depoyu başlatma ve mevcut durumu kontrol etme

Proje klasöründe git init çalıştırılır. Ardından git status ile dosyaların değişmiş, hazırlanmış, çatışmalı veya izlenmeyen durumları kontrol edilir. İzlenen dosyaların tamamını listelemek için ayrıca uygun Git komutları kullanılmalıdır. Dosyalar daha önce izlenmiyorsa git add index.html style.css komutuyla seçilir ve git commit -m "calisan temel sayfayi kaydet" ile ilk kayıt oluşturulur.

2. Menü için ayrı dal açma

git switch -c menu-duzenle komutu çalıştırılır. Bundan sonra yapılan HTML ve CSS değişiklikleri bu branch üzerinde ilerler; ana dal henüz etkilenmez.

3. Değişikliği inceleme ve kaydetme

index.html içinde menü yapısı, style.css içinde menünün görünümü değiştirilir. Önce git diff ile farklar incelenir. Sadece beklenen iki dosya değiştiyse git add index.html style.css çalıştırılır ve git commit -m "ust menu gorunumunu duzenle" komutuyla kayıt yapılır.

4. Ana dala dönme ve birleştirme

Menü tarayıcıda kontrol edildikten sonra önce git branch --show-current veya git branch ile ana dalın adı kontrol edilir. Dal adı main olarak belirlenmişse git switch main; aksi durumda mevcut ana dalın adı kullanılır. Ardından git merge menu-duzenle çalıştırılır. Aynı satırlarda başka bir değişiklik yoksa Git branch'teki commit'i ana geçmişe entegre eder.

Sonuç: Ana dal, yeni menü değişikliğini içerir; menü branch'i ise yapılan çalışmanın geçmişini ayrı bir yol olarak gösterir. Bir sorun fark edilirse git log ve git diff ile hangi commit'in değişiklik getirdiği incelenebilir. Bu örnekte git push kullanılmadığı için kayıtlar yalnızca yerel depodadır; ekip üyelerinin görmesi için uygun uzak depo tanımlanıp push yapılması gerekir.

Çözümlü örnek: uzak depoya commit gönderme ve güncel değişiklik alma

Verilenler: Bir geliştiricinin yerel Git deposunda açıklayıcı bir commit'i vardır. Ekip arkadaşları da uzak depoda değişiklik yapmaktadır. Amaç, yerel çalışmayı paylaşırken uzak depodaki yeni geçmişi de göz önünde bulundurmaktır.

1. Yerel çalışma durumunu kontrol etme

Önce git status çalıştırılır. Commit edilmemiş değişiklik varsa bunlar gözden geçirilir; çünkü çalışma dizini temiz değilken uzak değişiklikleri almak, hangi farkın hangi kaynaktan geldiğini anlamayı zorlaştırabilir.

2. Uzak geçmişi alma

git fetch ile uzak depodaki yeni commit bilgileri alınabilir. Bu adım, yerel dosyaları doğrudan değiştirmeden uzak geçmişi incelemeye yarar. Alternatif olarak git pull, uzak değişiklikleri alıp mevcut branch'e entegre etmeyi deneyen daha birleşik bir akıştır.

3. Çakışma varsa çözme

Eğer yerel ve uzak çalışmalar aynı satırlarda farklı değişiklikler içeriyorsa Git çatışma bildirir. git status ile dosyalar belirlenir; dosyanın gereksinime uygun sürümü hazırlanır, çatışma işaretleri kaldırılır ve dosya git add ile işaretlenir. Ardından birleştirme süreci tamamlanır ve proje çalıştırılarak kontrol edilir.

4. Uzak depoya gönderme

Yerel geçmiş güncel uzak geçmişle uyumlu hâle geldikten sonra git push çalıştırılır. Push reddedilirse bu genellikle uzak depoda yerelde bulunmayan yeni commit'ler olduğu anlamına gelebilir. Bu durumda önce uzak değişiklikler alınır, gerekirse çatışma çözülür ve tekrar push denenir.

Sonuç: Push, yalnızca bilgisayardaki dosyaları yüklemek değildir; yerel commit geçmişini uzak depoyla paylaşmaktır. Pull ise tek başına bir "güvenli birleştirme" garantisi vermez; gelen değişiklikler incelenmeli ve proje test edilmelidir.

Sık yapılan hatalar ve karıştırılan Git kavramları

Git ile GitHub'ı aynı sanmak: Git, sürüm kontrol yazılımıdır. GitHub ise Git depolarını barındıran çevrim içi bir hizmettir. GitHub olmadan yerel Git deposu kullanılabilir; GitHub hesabı da Git'in kendisi değildir.

Kaydetmek ile commit etmeyi karıştırmak: Dosyayı metin düzenleyicide kaydetmek yalnızca çalışma dizinini değiştirir. Değişiklik Git geçmişine girmeden önce hazırlama alanına alınmalı ve commit edilmelidir.

Her değişikliği tek commit'e doldurmak: Bir commit'in amacı anlaşılır bir değişiklik grubunu açıklamaktır. Birkaç ilgisiz özelliği tek kayda koymak, geçmişte hatanın kaynağını bulmayı ve belirli bir değişikliği incelemeyi zorlaştırabilir.

git add . komutunu kontrol etmeden kullanmak: Bu komut, bulunduğu konuma göre birçok değişikliği hazırlama alanına alabilir. Gizli anahtar, parola, büyük geçici dosya veya kişisel veri içeren dosyalar yanlışlıkla commit'e eklenebilir. Commit öncesinde git status ve git diff --staged ile hazırlanmış içerik kontrol edilmelidir.

Branch açınca ana dalın otomatik korunduğunu düşünmek: Branch, ana dalı doğrudan değiştirmeyi önlemeye yardımcı olur; ancak yanlış branch'te çalışmak veya merge sırasında hatalı seçim yapmak yine mümkündür. Dal adı ve aktif branch işlem öncesinde kontrol edilmelidir.

Merge conflict'i sadece bir tarafı seçerek çözmek: Çatışmanın üst veya alt bölümünü rastgele silmek, iki değişiklikten birinin gerekli kısmını kaldırabilir. Gereksinim incelenmeli, son dosya çalıştırılmalı ve ilgili testler yapılmalıdır.

Git'i otomatik yedek sanmak: Yerel commit'ler bilgisayar arızasına karşı tek başına yeterli değildir. Uzak depoya push edilmemiş çalışma başka bir kopyada bulunmayabilir. Tersine, uzak depoya parola veya gizli anahtar göndermek de güvenli değildir.

pull sonrası test yapmamak: Git'in metinsel olarak başarılı birleştirme yapması, uygulamanın davranış olarak doğru olduğu anlamına gelmez. Özellikle Python, JavaScript veya SQL dosyalarında birleşimden sonra ilgili program, sorgu ya da test akışı çalıştırılmalıdır.