Git Nedir?

Git Nedir? Yeni Başlayanlar İçin Sürüm Kontrolüne Giriş

Yazılımlar neredeyse hiçbir zaman olduğu gibi kalmaz. Bir geliştirici yeni bir özellik ekler, bir hatayı düzeltir, bağımlılıkları günceller, eski kodları kaldırır veya yeni bir fikri dener. Her değişiklik projenin yeni bir durumunu oluşturur. Güvenilir bir geçmiş olmadığında ise neyin, neden değiştiğini anlamak ve bir sorun çıktığında önceki hâle dönmek zorlaşır.

Git, projenin anlamlı sürümlerini kaydederek ve geliştiricilere değişiklikleri karşılaştırma, düzenleme, birleştirme ve geri yükleme araçları sunarak bu sorunu çözer. Bu yazıda Git'i en temelden ele alacağız; Git'in hangi ihtiyacı karşıladığını, dağıtık sürüm kontrolünün nasıl çalıştığını, repository ve commit gibi temel kavramları ve Git ile GitHub gibi platformlar arasındaki önemli farkı açıklayacağız.

Sürüm Kontrolü Nedir?

Sürüm kontrolü, dosyalarda zaman içinde yapılan değişiklikleri kaydeden bir sistemdir. Bir projenin yalnızca güncel hâlini saklamak yerine, seçilmiş değişikliklerden oluşan düzenli ve izlenebilir bir geçmiş oluşturur.

Bu geçmiş sayesinde bir geliştirici veya ekip şu tür pratik sorulara yanıt verebilir:

• Dünkü sürüm ile bugünkü sürüm arasında ne değişti?

• Projenin belirli bir bölümünü kim değiştirdi?

• Bir kod satırı neden eklendi veya kaldırıldı?

• Hataya hangi değişiklik neden oldu?

• Daha önceki kararlı bir sürüme dönebilir miyiz?

• İki geliştirici birbirinin çalışmasını ezmeden farklı özellikler üzerinde çalışabilir mi?

Sürüm kontrolü en çok kaynak kod için kullanılır; ancak dokümantasyon, yapılandırma dosyaları, altyapı tanımları, betikler, akademik projeler ve metin tabanlı diğer içerikler için de uygundur.

Temel fikir oldukça basittir: Projeyi sürekli kopyalanıp yeniden adlandırılan bir klasör olarak görmek yerine, incelenebilir bir geçmişe sahip ve zaman içinde gelişen bir çalışma olarak ele almak.

Sürüm Kontrolünden Önceki Sorun

Küçük bir uygulama geliştirdiğinizi düşünün. Başlangıçta tek bir proje klasörünüz var. Riskli bir değişiklik yapmadan önce klasörü kopyalıyorsunuz:

my-app
my-app-backup
my-app-final
my-app-final-2
my-app-final-working
my-app-final-really-working

Bu yöntem ilk bakışta güvenli görünebilir; ancak kısa sürede birçok soruna yol açar:

• Klasörler arasında tam olarak neyin değiştiğini bilemezsiniz.

• Her değişikliği kimin yaptığını kolayca belirleyemezsiniz.

• Birden fazla geliştirici aynı dosyanın farklı kopyalarını düzenleyebilir.

• Değişiklikleri birleştirmek manuel ve hataya açık bir sürece dönüşür.

• Eski klasörler net bir geçmiş sunmadan depolama alanı tüketir.

• final ve latest gibi adlar bir süre sonra anlamını yitirir.

Bir yedek klasörü yalnızca şu soruya cevap verir: “Bu kopya oluşturulduğunda dosyalar nasıl görünüyordu?” Sürüm kontrol sistemi ise çok daha fazlasını kaydeder: değişikliklerin sırasını, her kaydın neden oluşturulduğunu, değişikliği yapan kişiyi ve farklı geliştirme kolları arasındaki ilişkiyi.

Git Nedir?

Git; ücretsiz, açık kaynaklı ve dağıtık bir sürüm kontrol sistemidir. Bir projedeki değişiklikleri takip eder ve geliştiricilerin çalışma geçmişini kaybetmeden bireysel veya ekip hâlinde çalışmasını sağlar.

Git, 2005 yılında Linux çekirdeğinin geliştirilmesi sırasında oluşturuldu. Hız, dağıtık çalışma, paralel geliştirme desteği ve büyük projeleri verimli biçimde yönetebilme gibi hedefler gözetilerek tasarlandı.

Günümüzde Git, bir öğrencinin ilk uygulamasından farklı ülkelerdeki ekiplerin geliştirdiği büyük sistemlere kadar her ölçekteki projede kullanılmaktadır.

Git bir programlama dili, framework, bulut servisi veya kod barındırma sitesi değildir. Kendi bilgisayarınızda çalışabilen bir sürüm kontrol aracıdır. İnternete bağlanmadan ve herhangi bir platformda hesap oluşturmadan yalnızca yerel olarak da kullanabilirsiniz.

Git Neden “Dağıtık” Olarak Tanımlanır?

Git'e dağıtık sürüm kontrol sistemi denmesinin nedeni, her geliştiricinin proje dosyaları ve tüm geçmişiyle birlikte eksiksiz bir yerel repository'ye sahip olabilmesidir.

Bu yapı, ana repository'nin tek bir sunucuda bulunduğu ve geliştiricilerin geçmişi incelemek veya değişiklik kaydetmek için büyük ölçüde bu sunucuya bağımlı olduğu geleneksel merkezi modellerden farklıdır.

Git'te birçok önemli işlem yerel olarak yapılır:

• Commit oluşturmak.

• Önceki commit'leri görüntülemek.

• Sürümleri karşılaştırmak.

• Branch oluşturmak veya branch değiştirmek.

• Branch'leri birleştirmek.

• Önceki bir durumu geri yüklemek.

Bu işlemler yerel repository üzerinde gerçekleştiği için genellikle hızlıdır ve çoğu zaman internet bağlantısı olmadan da yapılabilir.

Uzak bir sunucu; iş birliği, yedekleme, kod inceleme ve otomasyon açısından yine önemlidir. Ancak uzak sunucu yerel Git repository'sinin yerini almaz; geliştiricilerin değişiklik alışverişi yaptığı başka bir kopyadır.

Merkezi ve Dağıtık Sürüm Kontrolü Arasındaki Fark

Merkezi ve dağıtık sistemler arasındaki farkı anlamak, Git'in neden bu şekilde çalıştığını kavramayı kolaylaştırır.

Merkezi Sürüm Kontrolü

Merkezi bir sistemde ana repository merkezi bir sunucuda tutulur. Geliştiriciler dosyaları bu sunucudan alır ve yaptıkları değişiklikleri tekrar sunucuya gönderir.

Bu model tek ve net bir doğruluk kaynağı ile merkezi yönetim sağlayabilir. Buna karşılık geliştiriciler, geçmişe erişim ve ekip çalışması konusunda sunucuya daha fazla bağımlı olabilir.

Dağıtık Sürüm Kontrolü

Git gibi dağıtık sistemlerde her clone normalde repository geçmişinin tamamını içerir. Geliştiriciler yerel olarak çalışabilir, commit oluşturabilir, branch açabilir ve daha sonra çalışmalarını bir veya birden fazla uzak repository ile eşitleyebilir.

Dağıtık yapı, ekiplerin merkezi bir platform kullanmaması gerektiği anlamına gelmez. Çoğu ekip yine ortak bir uzak repository kullanır. Asıl fark, Git'in yararlı repository işlemlerini yalnızca o sunucuda yapılabilir hâle getirmemesidir.

Git Bir Projeyi Nasıl Ele Alır?

Git'i anlamak için projeyi, anlamlı anlık görüntülerden oluşan bir zaman çizelgesi olarak düşünebilirsiniz.

Bir commit oluşturduğunuzda Git, seçilen proje dosyalarının o andaki durumunu aşağıdaki bilgilerle birlikte kaydeder:

• Yazar.

• Tarih ve saat.

• Değişikliği açıklayan mesaj.

• Önceki commit veya commit'lere referans.

Birbirine bağlı bu commit'ler proje geçmişini oluşturur.

Commit A → Commit B → Commit C → Commit D

Her commit, projenin gelişim sürecindeki bilinen bir noktayı temsil eder. Git bu noktaları karşılaştırarak nelerin eklendiğini, kaldırıldığını veya değiştirildiğini gösterebilir.

Bu nedenle geçmiş yalnızca geri dönüş için değil, teknik dokümantasyon olarak da değerlidir. Düzenli bir geçmiş; bir özelliğin nasıl geliştirildiğini, bir kararın neden alındığını ve bir sorunun ilk kez ne zaman ortaya çıktığını anlatabilir.

Git Yalnızca Dosya Farklarını Değil, Anlık Görüntüleri Kullanır

Yeni başlayanların çoğu sürüm kontrolünü “şu satırı ekle” veya “bu satırı kaldır” gibi talimatların bir koleksiyonu olarak düşünür. Git değişiklikleri bu biçimde gösterebilse de iç yapısı proje anlık görüntülerine dayanır.

Bir commit oluşturulduğunda Git, projenin o andaki içeriğine referanslar kaydeder. Değişmemiş dosyalar gereksiz yere tam kopya olarak saklanmak yerine verimli biçimde yeniden kullanılabilir.

Bu anlık görüntü yaklaşımı önemlidir; çünkü Git her commit'i birbirinden kopuk düzenleme talimatları olarak değil, projenin eksiksiz ve anlamlı bir durumu olarak ele alır.

Git Repository Nedir?

Git repository, Git tarafından takip edilen projedir. Çalışma dosyalarını ve .git adlı özel bir dahili klasörü içerir.

.git klasöründe Git'in iç verileri tutulur:

• Commit geçmişi.

• Branch'ler ve referanslar.

• Repository yapılandırması.

• Staging area bilgileri.

• Dosya, klasör ve commit'leri temsil eden nesneler.

.git klasörü bulunmayan bir dizin sıradan bir klasördür. Bu klasör eklendiğinde dizin bir Git repository'sine dönüşür.

Bir repository edinmenin iki yaygın yolu vardır:

1. Mevcut bir yerel proje içinde Git'i başlatmak.

2. Başka bir konumdaki mevcut repository'yi clone etmek.

Komutları sonraki uygulamalı yazılarda ayrıntılı biçimde ele alacağız. Kavramsal olarak fark şöyledir:

• Initialize: Bilgisayarınızda zaten bulunan bir projeyi takip etmeye başlamak.

• Clone: Mevcut bir Git repository'sinin ve geçmişinin yerel kopyasını oluşturmak.

Temel Git İş Akışındaki Üç Ana Alan

Değişikliklerin üç ana alan arasında ilerlediğini anladığınızda Git çok daha kolay hâle gelir:

1. Working directory.

2. Staging area.

3. Repository geçmişi.

1. Working Directory

Working directory, gördüğünüz ve düzenlediğiniz dosyaları içerir. Bir dosyayı değiştirdiğinizde bu değişiklik çalışma dizininde bulunur; ancak henüz bir commit'in parçası değildir.

2. Staging Area

Staging area bir hazırlık katmanıdır. Bir sonraki commit'e tam olarak hangi değişikliklerin ekleneceğini seçmenizi sağlar.

Bu özellik, birden fazla dosyada değişiklik yaptığınız ancak odaklı commit'ler oluşturmak istediğiniz durumlarda kullanışlıdır. Örneğin önce hata düzeltmesini stage edip, ilgisiz bir biçimlendirme değişikliğini başka bir commit'e bırakabilirsiniz.

3. Repository Geçmişi

Stage edilen değişiklikler commit edildiğinde repository geçmişinin bir parçası olur. Commit benzersiz bir kimlik alır ve Git'in daha sonra inceleyebileceği kayıtlı bir sürüme dönüşür.

Temel akış şu şekildedir:

Working Directory
       ↓
   git add
       ↓
  Staging Area
       ↓
  git commit
       ↓
Repository History

Bu ayrım, geçmişe hangi değişikliklerin gireceği konusunda geliştiriciye kontrol sağlar. Git, kaydettiğiniz her dosya değişikliğini otomatik olarak commit'e dönüştürmez.

Modified, Staged ve Committed Durumları

Git dokümantasyonunda takip edilen dosya içerikleri genellikle üç temel durumla açıklanır:

• Modified: Dosya working directory içinde değişmiştir; ancak yeni sürümü henüz stage edilmemiştir.

• Staged: Değişen sürüm bir sonraki commit'e eklenmek üzere seçilmiştir.

• Committed: Sürüm yerel Git geçmişine güvenli biçimde kaydedilmiştir.

Basit bir örnek üzerinden bakalım:

1. login.php dosyasını düzenlersiniz. Dosya artık modified durumundadır.

2. Değişikliği staging area'ya eklersiniz. Dosya staged olur.

3. Commit oluşturursunuz. Değişiklik committed hâle gelir.

Daha sonra aynı dosyayı yeniden düzenlerseniz yeni değişiklik modified durumuna geçer; daha önce commit edilen sürüm ise geçmişte korunmaya devam eder.

Commit Nedir?

Commit, projenin kaydedilmiş bir anlık görüntüsüdür ve Git'in en temel kavramlarından biridir.

Bir commit normalde şu bilgileri içerir:

• Proje içeriğine referans.

• Yazar ve commit işlemini yapan kişinin bilgileri.

• Zaman damgası.

• Commit mesajı.

• Bir veya daha fazla üst commit ile bağlantı.

Commit mesajı yalnızca düzenlenen dosyanın adını tekrarlamak yerine değişikliğin amacını açıklamalıdır.

Zayıf bir mesaj:

dosyaları güncelle

Daha açıklayıcı bir mesaj:

Kullanıcı hesabı oluşturmadan önce e-posta adreslerini doğrula

İkinci mesaj, gelecekte projeyle ilgilenen geliştiricilerin bu commit'in neden oluşturulduğunu anlamasını kolaylaştırır.

İyi bir commit genellikle tek bir mantıksal iş birimini temsil etmelidir. Odaklı bir commit; ilgisiz değişiklikler içeren büyük bir commit'e göre daha kolay incelenir, test edilir, anlaşılır ve geri alınır.

Commit Hash Nedir?

Her commit, genellikle kısaltılmış bir karakter dizisi olarak gösterilen benzersiz bir kimlik alır.

a4c29f1

Bu kimlik sayesinde Git geçmişteki belirli bir noktaya doğrudan referans verebilir. Bir commit'i incelemek, başka bir sürümle karşılaştırmak, o noktadan yeni bir branch oluşturmak veya ilgili içeriği geri yüklemek için kullanılabilir.

Geliştiriciler günlük komutlarda çoğunlukla kısaltılmış commit kimliklerini kullanır. Git ise arka planda nesnenin tam kimliğini saklar.

Branch Nedir?

Branch, bağımsız bir geliştirme koludur. Ana proje akışını hemen etkilemeden yeni bir özellik, hata düzeltmesi veya deneme üzerinde çalışmanızı sağlar.

Projenin şu anda üç commit'e sahip olduğunu düşünün:

A → B → C

Yeni bir branch oluşturup özellik için iki commit ekliyorsunuz:

A → B → C
                   D → E

Ana branch kararlı kalırken feature branch ayrı olarak gelişmeye devam edebilir. Özellik hazır olduğunda, yapılan çalışma merge veya başka bir entegrasyon yöntemiyle hedef branch'e aktarılabilir.

Branch'ler ekip çalışmasının merkezinde yer alır; çünkü farklı görevlerin aynı anda ilerlemesini sağlar:

• Bir geliştirici kimlik doğrulama üzerinde çalışır.

• Bir diğeri ödeme hatasını düzeltir.

• Üçüncü geliştirici dokümantasyonu günceller.

• Production branch korunmaya devam eder.

Branch kullanmak tüm çakışmaları otomatik olarak engellemez; ancak değişikliklerin kontrollü biçimde incelenmesini ve birleştirilmesini sağlayan düzenli bir çalışma yapısı sunar.

HEAD Nedir?

HEAD, Git'in o anda üzerinde çalıştığınız commit veya branch'i gösteren referansıdır.

Normal bir iş akışında HEAD mevcut branch'i, mevcut branch de kendi geliştirme kolundaki en son commit'i gösterir.

HEAD → feature/login → Commit E

Branch değiştirdiğinizde HEAD seçilen branch'e taşınır. Bu kavramı anlamak; branch'ler arasında geçiş yaparken, sürüm geri yüklerken, rebase uygularken veya detached HEAD durumlarıyla çalışırken özellikle önemlidir.

Merge Nedir?

Merge, farklı geliştirme geçmişlerini bir araya getirir. Genellikle bir feature branch'te tamamlanan çalışmayı başka bir branch'e aktarmak için kullanılır.

Örneğin:

main:          A → B → C
                        feature/login:           D → E

Merge işleminden sonra ana geliştirme kolu, feature branch'teki çalışmayı da içerir. Geçmişin yapısına bağlı olarak Git yalnızca branch işaretçisini ileri taşıyabilir veya özel bir merge commit oluşturabilir.

Git birbiriyle yarışan değişiklikleri güvenli biçimde nasıl birleştireceğini belirleyemediğinde merge conflict oluşabilir. Bu durum çoğunlukla farklı branch'lerin aynı dosyanın aynı bölümünü uyumsuz şekillerde değiştirmesiyle ortaya çıkar.

Conflict, Git'in başarısız olduğu anlamına gelmez. Git yalnızca güvenli ve otomatik biçimde veremeyeceği bir karar için geliştiriciden müdahale ister.

Remote Repository Nedir?

Remote repository, yerel repository'nizin iletişim kurabildiği başka bir Git repository'sidir. Çoğunlukla bir sunucuda veya iş birliği platformunda barındırılır.

Remote kullanarak şunları yapabilirsiniz:

• Commit'leri ekiple paylaşmak.

• Diğer geliştiricilerin yaptığı değişiklikleri almak.

• Ortak bir repository tutmak.

• Proje geçmişinin uzak bir kopyasını saklamak.

• Kod inceleme ve otomasyon süreçlerini tetiklemek.

Git'te sık kullanılan bazı komutlar şunlardır:

• Uzak bilgileri ve değişiklikleri almak için git fetch.

• Uzak değişiklikleri alıp mevcut çalışmayla birleştirmek için git pull.

• Yerel commit'leri uzak repository'ye göndermek için git push.

Bu komutların tamamı Git'e aittir. Remote repository; GitHub, GitLab, Bitbucket, Azure Repos, özel bir sunucu veya Git uyumlu başka bir hizmet üzerinde barındırılabilir.

Git ve GitHub Aynı Şey Değildir

Bu ayrım çok önemlidir:

• Git, sürüm kontrol sistemidir.

• GitHub, Git repository'lerini barındıran ve ekip çalışmasına yönelik ek özellikler sunan bir platformdur.

Git'i GitHub olmadan kullanabilirsiniz. Örneğin yalnızca yerel bir repository oluşturabilir, yüzlerce commit kaydedebilir, branch açabilir, branch'leri birleştirebilir ve herhangi bir GitHub hesabı oluşturmadan tüm geçmişi inceleyebilirsiniz.

GitHub özellikle şu özelliklere ihtiyaç duyduğunuzda yararlıdır:

• Uzak repository barındırma.

• Pull request.

• Kod inceleme.

• Issue takibi.

• Proje tartışmaları.

• Erişim yönetimi.

• Otomatik iş akışları.

• Release sayfaları.

Basit bir benzetmeyle Git, proje geçmişini yöneten motor; GitHub ise bu motorun yönettiği repository'lerin etrafında kurulmuş ortak çalışma alanıdır.

GitHub, GitLab ve Bitbucket

GitHub, Git repository'lerini barındırabilen tek platform değildir.

• GitHub: Açık kaynak projeler, portföyler, özel repository'ler, pull request'ler ve entegrasyonlar için yaygın olarak kullanılır.

• GitLab: Git barındırma, merge request, proje yönetimi ve entegre CI/CD özellikleri sunar.

• Bitbucket: Git repository barındırma hizmeti sunar ve özellikle Atlassian ekosistemiyle çalışan ekipler tarafından tercih edilir.

• Azure Repos: Azure DevOps iş akışları içinde Git repository hizmeti sağlar.

• Kendi sunucusunda barındırma: Kurumlar Git repository'lerini kendi yönettikleri altyapı üzerinde de barındırabilir.

Temel Git bilgisi tüm bu platformlara taşınabilir. Commit, branch, merge, fetch, pull ve push gibi kavramlar Git'e aittir; platformlar yalnızca çevresindeki iş birliği özellikleri için farklı adlar kullanabilir.

Gerçek Hayattan Basit Bir Git Senaryosu

Bir ekibin çevrimiçi mağaza geliştirdiğini düşünelim. Ana branch uygulamanın kararlı sürümünü içeriyor.

Bir geliştiriciye ödeme adımında kupon doğrulama özelliği ekleme görevi veriliyor.

Git tabanlı mantıklı bir süreç şu şekilde ilerleyebilir:

1. Kupon özelliği için yeni bir branch oluşturmak.

2. Ödeme kodunu düzenlemek.

3. Doğrulama mantığını test etmek.

4. Yalnızca özellikle ilgili dosyaları stage etmek.

5. Açık bir mesajla odaklı bir commit oluşturmak.

6. Branch'i ortak remote repository'ye push etmek.

7. Pull request veya merge request açmak.

8. Otomatik testlerin ve inceleyicilerin değişikliği kontrol etmesini sağlamak.

9. İnceleme sırasında belirlenen sorunları düzeltmek.

10. Onaylanan özelliği ana branch'e merge etmek.

Git; commit'leri, branch'leri ve merge geçmişini yönetir. Barındırma platformu ise bu Git geçmişinin etrafındaki inceleme görüşmelerini, izinleri ve otomatik kontrolleri yönetir.

Geliştiriciler Neden Git Kullanır?

1. Güvenilir Proje Geçmişi

Git, projenin kaydedilmiş durumlarını korur ve projenin zaman içinde nasıl geliştiğinin incelenmesini sağlar.

2. Daha Güvenli Denemeler

Bir geliştirici, kararlı çalışmayı doğrudan etkilemeden yeni bir deneme için ayrı branch oluşturabilir.

3. Paralel Geliştirme

Birden fazla geliştirici farklı görevler üzerinde çalışabilir ve değişikliklerini daha sonra birleştirebilir.

4. Daha Kolay Kod İnceleme

Git, commit'ler veya branch'ler arasında tam olarak neyin değiştiğini göstererek incelemeyi daha odaklı hâle getirir.

5. Sorunları Daha Hızlı Araştırma

Geliştiriciler geçmişi inceleyebilir, sürümleri karşılaştırabilir ve şüpheli davranışın projeye ne zaman girdiğini belirleyebilir.

6. Daha İyi Release Yönetimi

Ekipler önemli sürümleri işaretleyebilir, release branch'leri tutabilir ve yayındaki kodu belirli commit'lere kadar izleyebilir.

7. Otomasyon Entegrasyonu

Repository olayları, harici platformlar üzerinden testleri, build işlemlerini, kod kalitesi kontrollerini, güvenlik taramalarını ve deployment süreçlerini tetikleyebilir.

8. Tek Başına Çalışan Geliştiriciler İçin de Yararlıdır

Git yalnızca ekipler için değildir. Tek başına çalışan bir geliştirici de geçmiş takibi, güvenli refactoring, deneysel branch'ler ve önceki çalışmaları geri getirme imkânından yararlanır.

Git Nelerin Yerini Tutmaz?

Git güçlü bir araçtır; ancak bir projedeki her veri türü ve süreç için tek başına eksiksiz bir çözüm değildir.

Git Tam Bir Yedekleme Stratejisi Değildir

Remote repository kaynak kodun ek bir kopyasını sağlayabilir; ancak veritabanları, kullanıcıların yüklediği dosyalar, sunucu yapılandırmaları, gizli bilgiler veya production altyapısı için tek yedekleme yöntemi olarak kullanılmamalıdır.

Git Bir Proje Yönetim Sistemi Değildir

Git proje sürümlerini kaydeder. Görevler, son tarihler, görüşmeler, sprint planlaması ve issue takibi için genellikle ek araçlar veya barındırma platformlarının özellikleri kullanılır.

Git Tek Başına Bir Deployment Sistemi Değildir

Git deployment otomasyonunu tetikleyebilir; ancak production deployment için altyapı, yetkilendirme, ortam yapılandırması, build adımları, izleme ve rollback planı da gerekir.

Git Her Büyük Binary Dosya İş Akışı İçin İdeal Değildir

Git özellikle metin tabanlı dosyalarda çok etkilidir. Büyük binary dosyalar için özel uzantılar, ayrı depolama çözümleri veya bu dosya türlerine uygun farklı iş akışları gerekebilir.

Yeni Başlayanların Sık Yaptığı Yanlış Varsayımlar

“Dosyayı Kaydetmek Git Sürümü Oluşturur”

Dosyayı kaydetmek yalnızca çalışma dosyasını günceller. Git, değişiklikleri ancak siz bilinçli olarak stage edip commit ettiğinizde kaydeder.

“Git Kodumu Otomatik Olarak İnternete Yükler”

Commit'ler varsayılan olarak yereldir. Uzak repository'ye ancak push ettiğinizde gönderilir.

“Her Değişiklik Tek Bir Commit Olmalı”

İlgili değişiklikleri odaklı commit'ler hâlinde düzenleyebilirsiniz. Staging area, her commit'e hangi değişikliklerin gireceğini seçmenizi sağlar.

“Branch Proje Klasörünün Tam Bir Kopyasıdır”

Git branch'i, elle çoğaltılmış bir klasör değil; bir commit zincirini gösteren hafif bir referanstır.

“Git'in Sahibi GitHub'dır”

Git bağımsız ve açık kaynaklı bir sürüm kontrol sistemidir. GitHub ise Git repository'lerinin etrafında hizmet sunan platformlardan biridir.

“Sürüm Kontrolüne Yalnızca Proje Büyüdüğünde İhtiyaç Vardır”

Sürüm kontrolüne başlamak için en doğru zaman projenin başlangıcıdır. Küçük bir uygulama bile düzenli bir geçmişten yararlanır.

Temel Git Terimleri

Git İş Akışına İlk Bakış

Aşağıdaki komutlar yalnızca kısa bir ön izlemedir. Kurulum, yapılandırma, staging ve commit işlemleri sonraki yazılarda ayrıntılı biçimde ele alınacaktır.

# Yeni bir proje klasörü oluştur
mkdir git-introduction-demo
cd git-introduction-demo

# Git repository'sini başlat
git init

# Bir dosya oluştur
echo "# Git Introduction Demo" > README.md

# Repository durumunu kontrol et
git status

# Dosyayı bir sonraki commit için hazırla
git add README.md

# Stage edilen sürümü kaydet
git commit -m "Proje README dosyasını oluştur"

# Geçmişi görüntüle
git log --oneline

Kavramsal olarak bu komut dizisi beş işlem gerçekleştirir:

1. Normal bir proje klasörü oluşturur.

2. Bu klasörü Git repository'sine dönüştürür.

3. Bir proje dosyası oluşturur.

4. Dosyayı bir sonraki anlık görüntüye eklenmek üzere seçer.

5. Anlık görüntüyü geçmişe kaydeder.

Asıl önemli beceri, komutları bağlamından kopuk biçimde ezberlemek değil; her komutun Git iş akışında neyi değiştirdiğini anlamaktır.

Git'te Neler Saklanmalıdır?

Bir repository, sürüm kontrolüne uygun olduğu sürece projeyi anlamak, oluşturmak ve sürdürmek için gereken dosyaları içermelidir.

Genellikle commit edilen dosyalar şunlardır:

• Uygulama kaynak kodu.

• Otomatik testler.

• Dokümantasyon.

• Bağımlılık tanım dosyaları.

• Veritabanı migration dosyaları.

• Yapılandırma şablonları.

• Infrastructure as Code dosyaları.

• Build ve CI/CD tanımları.

Genellikle repository dışında tutulan dosyalar ise şunlardır:

• Parolalar ve API secret'ları.

• Kimlik bilgisi içeren yerel ortam dosyaları.

• Geçici dosyalar.

• Editöre özel önbellek dosyaları.

• Ekosistemin zorunlu kılmadığı, otomatik üretilen bağımlılık klasörleri.

• Yeniden üretilebilen build çıktıları.

• Büyük yerel log dosyaları.

Git, normalde takip edilmemesi gereken dosya ve klasör kalıplarını tanımlamak için .gitignore adlı dosyayı kullanır.

Güvenlik: Gizli Bilgileri Asla Commit Etmeyin

En önemli Git alışkanlıklarından biri, gizli bilgileri repository geçmişinin dışında tutmaktır.

Şunları commit etmeyin:

• Veritabanı parolaları.

• Özel API anahtarları.

• Bulut hizmeti kimlik bilgileri.

• Özel SSH anahtarları.

• Erişim token'ları.

• Production ortam dosyaları.

Bir gizli bilgiyi daha sonraki commit'te silmek, onu geçmişteki commit'lerden otomatik olarak kaldırmaz. Bir secret commit edilmiş veya push edilmişse artık açığa çıkmış kabul edilmelidir. İlgili anahtar ya da parola iptal edilmeli veya değiştirilmelidir; ardından geçmiş, uygun ve dikkatle planlanmış bir yöntemle temizlenmelidir.

Başlangıçtan İtibaren Git İçin En İyi Uygulamalar

• Proje başlar başlamaz sürüm kontrolünü kullanın.

• Anlamlı iş birimleri için ayrı commit'ler oluşturun.

• Değişikliğin amacını açıklayan commit mesajları yazın.

• Commit etmeden önce stage edilen değişiklikleri gözden geçirin.

• Özellikler, hata düzeltmeleri ve denemeler için branch kullanın.

• Kimlik bilgilerini ve yerel ortam secret'larını repository dışında tutun.

• Projeye uygun bir .gitignore dosyası kullanın.

• Ekipteki değişikliklerle düzenli olarak senkronize olun.

• Birbiriyle ilgisiz değişiklikleri tek ve büyük bir commit'te birleştirmeyin.

• Yıkıcı seçenekler içeren bir komutu kullanmadan önce ne yaptığını anlayın.

Git Öğrenmek Zor mu?

Working directory, staging area, commit, branch, remote ve barındırma platformları gibi birçok katman aynı anda anlatıldığı için Git başlangıçta karmaşık görünebilir.

Çözüm, Git'i rastgele komutlardan oluşan bir liste olarak değil, bütünlüklü bir sistem olarak öğrenmektir.

Pratik bir öğrenme sırası şöyle olabilir:

1. Üç temel alanı anlayın: working directory, staging area ve repository.

2. status, add, commit ve log komutlarını uygulayın.

3. Branch ve merge işlemlerini önce yerel ortamda öğrenin.

4. Remote, fetch, pull ve push kavramlarını anlayın.

5. Pull request veya merge request üzerinden ekip çalışması pratiği yapın.

6. Geri alma komutlarını, her birinin neyi değiştirdiğini anladıktan sonra öğrenin.

7. Daha sonra rebase, cherry-pick, hook ve otomasyon gibi gelişmiş konulara geçin.

Günlük geliştirme çalışmalarının çoğu, Git'teki tüm gelişmiş komutları bilmeyi gerektirmez. Az sayıdaki temel komutu gerçekten anlamak, etkisini bilmeden onlarca komutu ezberlemekten çok daha değerlidir.

Git Ne Zaman Kullanılmalıdır?

Git, modern yazılım geliştirme projelerinin büyük bölümü için uygundur:

• Web uygulamaları.

• Mobil uygulamalar.

• API'ler ve backend servisleri.

• Frontend projeleri.

• Kütüphaneler ve paketler.

• Otomasyon betikleri.

• DevOps ve altyapı repository'leri.

• Teknik dokümantasyon.

• Akademik programlama projeleri.

• Kişisel öğrenme projeleri.

Tek başınıza çalışırken bile Git; kontrollü biçimde deneme yapmanızı ve önceki çalışmalara dönebilmenizi sağlar. Ekip ortamında ise kod inceleme, entegrasyon, release ve otomatik teslim süreçlerinin temelini oluşturur.

Git'e Giriş Kontrol Listesi

Kurulum ve yapılandırma yazısına geçmeden önce aşağıdaki noktaların net olduğundan emin olun:

• Sürüm kontrolü, projedeki anlamlı değişiklikleri zaman içinde kaydeder.

• Git dağıtık bir sürüm kontrol sistemidir.

• Git ve GitHub birbiriyle ilişkilidir ancak aynı araç değildir.

• Bir repository, proje dosyalarını ve Git geçmişini içerir.

• Commit, projenin kaydedilmiş bir anlık görüntüsüdür.

• Staging area, değişiklikleri bir sonraki commit için hazırlar.

• Branch, bağımsız bir geliştirme kolunu temsil eder.

• Remote repository, değişiklik paylaşımı için kullanılan başka bir Git repository'sidir.

• Commit'ler push edilene kadar yerel kalır.

• Gizli bilgiler hiçbir zaman repository'ye commit edilmemelidir.

Sık Sorulan Sorular

Git'i GitHub Olmadan Kullanabilir miyim?

Evet. Git tamamen kendi bilgisayarınızda veya özel bir Git sunucusuyla kullanılabilir. GitHub zorunlu değildir.

Git İçin İnternet Bağlantısı Gerekir mi?

Hayır. Yerel commit, branch, karşılaştırma ve geçmiş inceleme işlemleri çevrimdışı çalışabilir. İnternet bağlantısı yalnızca çevrimiçi bir remote repository ile iletişim kurarken gerekir.

Git Yalnızca Profesyonel Geliştiriciler İçin mi?

Hayır. Öğrenciler, araştırmacılar, teknik yazarlar, sistem yöneticileri ve tek başına çalışan geliştiriciler de Git'ten yararlanabilir.

Git Her Dosyayı Otomatik Olarak Kaydeder mi?

Hayır. Git yalnızca sizin stage edip commit ettiğiniz değişiklikleri kaydeder.

Git Silinen Kodları Geri Getirebilir mi?

Git, daha önce commit edilmiş içerikleri geri yükleyebilir. Hiç kaydedilmemiş ve working directory'den kalıcı olarak silinmiş bir çalışmayı güvenilir biçimde kurtaramaz.

Git Repository Bir Yedek midir?

Özellikle uzak bir konuma kopyalandığında değerli bir proje geçmişi sağlar; ancak tek başına yedekleme çözümü olarak değil, daha geniş bir yedekleme stratejisinin parçası olarak kullanılmalıdır.

Önce Hangi Barındırma Platformunu Öğrenmeliyim?

Önce Git'in temel mantığını öğrenin. Ardından GitHub pratik bir başlangıç noktasıdır; ancak aynı Git bilgisi GitLab, Bitbucket, Azure Repos ve özel sunucularda da kullanılabilir.

Sonuç

Git, sürekli değişen bir projeyi düzenli ve incelenebilir bir geçmişe dönüştüren dağıtık bir sürüm kontrol sistemidir. Geliştiricilerin anlamlı anlık görüntüler oluşturmasına, branch'ler üzerinden güvenli denemeler yapmasına, sürümleri karşılaştırmasına, ekiplerle çalışmasına ve birçok yaygın hatadan geri dönmesine yardımcı olur.

En önemli nokta komutların kendisi değil, bu komutların arkasındaki çalışma modelidir: Dosyalar working directory içinde değiştirilir, staging area üzerinden seçilir ve repository'ye commit olarak kaydedilir. Branch'ler bağımsız geliştirme çalışmalarını düzenler; remote repository'ler ise bu geçmişlerin paylaşılmasını sağlar.

Bu zihinsel model netleştiğinde Git çok daha anlaşılır hâle gelir. Bir sonraki adım Git'i kurmak, kullanıcı kimliğinizi ve varsayılan ayarlarınızı yapılandırmak ve ilk uygulamalı repository için temiz bir çalışma ortamı hazırlamaktır.

Resmî Kaynaklar ve Ek Okumalar

• Resmî Git Dokümantasyonu

• Pro Git Kitabı

• Sürüm Kontrolü Hakkında

• Git'in Kısa Tarihi

• Git Nedir?

• GitHub Dokümantasyonunda Git Temelleri

• GitHub Dokümantasyonunda Git Hakkında