Mobil geliştirmede Git ve sürüm kontrolü: nedir, temel komutlar ve nasıl çalışır

Sürüm kontrolü ve Git: nedir?

Git, 2005 yılında Linus Torvalds tarafından Linux çekirdeği geliştirmek için oluşturulmuş dağıtık bir sürüm kontrol sistemidir (VCS). Merkezi sistemlerin (SVN, CVS) aksine Git, proje geçmişinin tam bir kopyasını her geliştiricinin bilgisayarında depolar. Bu, internet bağlantısı olmasa bile commit yapabileceğiniz, geçmişe göz atabileceğiniz ve dallar oluşturabileceğiniz anlamına gelir.

Git, anlık görüntüler (snapshot) ile çalışır — her commit, kaydetme anındaki tüm proje dosyalarının durumunu kaydeder. Bir dosya değişmemişse Git, önceki sürüme referans oluşturarak yerden tasarruf sağlar. GitHub analizine (2025) göre, ortalama bir depo 1.200 commit ve 15 dal içerir.

IT Sectr'de, 2017'den beri tüm projelerde Git kullanıyoruz. Deneyimimiz, ilk günden itibaren doğru Git yapılandırmasının, birleştirme ve çakışma çözümünde ekibe %30'a kadar zaman kazandırdığını gösteriyor. Git fiili standart haline geldi — tüm modern IDE'ler (Android Studio, Xcode, VS Code) ve CI/CD sistemleri tarafından desteklenmektedir.

# Temel Git kurulumu
git config --global user.name "Adınız"
git config --global user.email "email@adresiniz.com"

# Yeni bir depo oluşturma
git init my-project
cd my-project

# Dosya ekleme ve commit
git add README.md
git commit -m "Initial commit"

# Uzak depo ile çalışma
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Yukarıdaki kod temel sırayı gösterir: depoyu başlatma, ilk commit ve uzak sunucuda yayınlama. git init komutu, tüm proje geçmişini depolayacak gizli bir .git klasörü oluşturur. Her git commit, istediğiniz zaman dönebileceğiniz bir geri yükleme noktası oluşturur.

Temel kavramlar: Repository, Branch, Commit

Üç temel kavramı — Repository, Branch ve Commit — anlamak, herhangi bir sürüm kontrol sistemiyle çalışmak için gereklidir. Depo, tüm proje için bir kapsayıcıdır. Commit, dosyaların kaydedilmiş bir durumudur. Branch, ayrı bir geliştirme çizgisidir.

Repository (depo) yerel (bilgisayarınızda) veya uzak (GitHub, GitLab sunucusunda) olabilir. Her geliştirici, uzak depoyu kendi makinesine kopyalar ve yerel bir kopya ile çalışır. Değişiklikler push (gönderme) ve pull (çekme) yoluyla senkronize edilir. Dağıtık sürüm kontrolünde, her geliştirici geçmişin tam bir kopyasını saklar.

Branch (dal), commit'lerden birini işaret eden bir işaretçidir. Dallar paralel geliştirmeye olanak tanır: bir geliştirici yeni bir özellik üzerinde (feature branch) çalışır, diğeri bir hatayı düzeltir (hotfix branch), üçüncüsü bir sürüm hazırlar (release branch). GitLab Flow'a (2025) göre, ortalama bir projede aynı anda 3–5 aktif dal bulunur.

Commit bir değişiklik birimidir. Her commit, benzersiz bir karma (SHA-1), mesaj, yazar ve zaman damgası içerir. İyi bir uygulama, açıklayıcı mesajlarla küçük anlamlı commit'ler yapmaktır — bu, Kod İncelemesini ve değişiklik geri almayı basitleştirir. Commit'ler aracılığıyla sürüm kontrolü size projenin tam geçmişini verir.

Feature Branch

Feature Branch (özellik dalı), belirli bir görevi geliştirmek için develop veya main'den oluşturulan geçici bir daldır. İş tamamlandıktan sonra dal, Pull Request aracılığıyla geri birleştirilir ve silinir. Bu uygulama, ana kod tabanının kararlılığını bozmadan değişiklikleri izole etmeye olanak tanır.

Tipik iş akışı: feature/add-login dalı oluştur → birkaç commit yap → Pull Request oluştur → Kod İncelemesinden geç → develop'a birleştir. IT Sectr'de tam olarak bu yaklaşımı kullanıyoruz: her Jira görevi ayrı bir özellik dalına karşılık gelir. Bu, değişiklik takibini ve gerektiğinde geri almayı basitleştirir.

Rebase vs Merge

Merge, iki dalı birleştiren bir birleştirme commit'i oluşturur. Paralel geliştirme çizgileri dahil olmak üzere tam geçmişi korur. Rebase geçmişi yeniden yazar: bir daldan commit'leri alır ve bunları başka bir dalın üzerine "yeniden uygulayarak" doğrusal bir geçmiş oluşturur.

Merge, kronolojinin önemli olduğu kamu dalları ve büyük ekipler için daha uygundur. Rebase, PR oluşturmadan önce kişisel özellik dalları için kullanışlıdır — geçmişi daha temiz ve anlaşılır hale getirir. Ancak rebase, geçmişi yeniden yazdığı için diğer geliştiricilerin üzerinde çalıştığı dallara asla uygulanmamalıdır.

# Özellik dalı oluşturma ve geçiş yapma
git checkout -b feature/add-login main

# Dalda çalışma
git add login-screen/
git commit -m "Add login screen layout"

# PR öncesi en son main'e Rebase
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Uzak depoya Push
git push origin feature/add-login

Bu örnek tipik bir iş akışını gösterir: main'den özellik dalı oluşturma, birkaç commit ve incelemeye göndermeden önce temiz doğrusal geçmiş elde etmek için rebase. Bu yaklaşım birleştirme çakışmalarını en aza indirir.

Git Flow vs Trunk-Based Development

Git Flow ve Trunk-Based Development, bir ekibin Git ile çalışmayı nasıl organize edeceğini belirleyen iki ana sürüm kontrol stratejisidir. Seçim, ekip büyüklüğüne, sürüm sıklığına ve kararlılık gereksinimlerine bağlıdır.

Git Flow, birden çok kalıcı dalı olan katı bir modeldir: main (sürüm kodu), develop (mevcut geliştirme), feature/* (yeni özellikler), release/* (sürüm hazırlığı) ve hotfix/* (acil düzeltmeler). Bu model, net sürüm döngüleri olan projeler için iyidir (örneğin, 1.0, 2.0 sürümleri olan mobil uygulamalar).

Trunk-Based Development, tüm geliştiricilerin günde birkaç kez değişiklikleri birleştirdiği tek bir ana dal (trunk/main) yaklaşımıdır. Tamamlanmamış özellikleri gizlemek için özellik bayrakları kullanılır. Bu yaklaşım, teslimat hızının önemli olduğu web geliştirme ve startuplarda popülerdir.

Git Flow

Git Flow, 2010 yılında Vincent Driessen tarafından önerilmiş olup en popüler modellerden biri olmaya devam etmektedir. Başlıca avantajı, kodun yaşam döngüsü aşamalarına göre katı bir şekilde ayrılmasıdır. main dalı yalnızca sürüm kodunu içerir, develop mevcut geliştirmeyi içerir ve özellik dalları yeni özellikleri birbirinden ayırır.

Hotfix dalları acil düzeltmeler için main'den oluşturulur ve birleştirmeden sonra hem main'e hem de develop'a geri birleştirilir. Release dalları, ekip bir sürüme hazır olduğunda develop'dan oluşturulur. Bunlara yalnızca hata düzeltmeleri ve meta veriler (sürüm, derleme) eklenir. Sürümden sonra, release dalı main ve develop'a birleştirilir. JetBrains anketine (2024) göre, ekiplerin %37'si Git Flow kullanmaktadır. Bu sürüm kontrol modeli, sabit sürümlü projeler için standart olmaya devam etmektedir.

# Git Flow örneği: bir sürüm üzerinde çalışmaya başlama
git checkout -b release/1.2.0 develop

# release dalında hata düzeltme
git commit -m "Fix login button crash"

# Sürümü tamamlama — main ve develop'a birleştirme
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# release dalını silme
git branch -d release/1.2.0

Kod, bir release dalı oluşturmayı, kararlı hale getirmeyi ve ana dallara birleştirmeyi gösterir. --no-ff bayrağı, değişikliklerin release dalından geldiği bilgisini koruyan bir birleştirme commit'i garanti eder.

Pull Request ve Kod İncelemesi

Pull Request (PR), bir geliştiricinin kendi dalından ana dala değişiklik önermesi için kullanılan bir mekanizmadır. PR, ekip çalışmasında sürüm kontrolünün önemli bir öğesidir — sadece kodu birleştirmenin bir yolu değil, aynı zamanda tartışma, inceleme ve kalite kontrol sürecidir. GitLab'de benzer mekanizmaya Merge Request (MR) denir, ancak öz aynıdır: ekibi değişikliklerden haberdar etmek ve onay almak.

İyi bir PR küçük (300 satır koda kadar), tek bir göreve odaklanmış ve neyin neden yapıldığının açıklamasını içermelidir. Google araştırmasına (2025) göre, 400 satırı aşan PR'lerin incelenmesi iki kat daha uzun sürer ve hata tespit olasılığı %30 azalır. Kod İncelemesi (Code Review), birleştirmeden önce kodun başka bir geliştirici tarafından kontrol edilmesidir.

IT Sectr'de, her PR için zorunlu Kod İncelemesi uyguluyoruz. Bu sadece kod kalitesini artırmakla kalmaz, aynı zamanda ekip içinde bilgi yayılmasına da yardımcı olur. Kod İncelemesi şunları kontrol eder: kod mimari prensiplere uyuyor mu, hata var mı, yeterli test var mı, değişkenler doğru adlandırılmış mı. Tüm yorumlar birleştirmeye kadar PR'de tartışılır.

Platformlar: GitHub, GitLab, Bitbucket

Git bir protokoldür, ancak iş birliği için web arayüzü, erişim yönetimi, CI/CD ve inceleme araçları sağlayan bir sürüm kontrol platformu gerekir. Pazarda üç platform baskındır: GitHub, GitLab ve Bitbucket.

GitHub, 56 milyondan fazla geliştiriciyle en büyük platformdur. Microsoft'a aittir, Actions (CI/CD), Pages (barındırma), Discussions ve Copilot sunar. Ücretsiz plan, 3 kişiye kadar ekipler için sınırsız özel depo içerir. GitHub, açık kaynak topluluğunda popülerdir.

GitLab, entegre CI/CD, konteyner kaydı ve altyapı yönetimi ile tam bir DevOps platformudur. GitHub'ın aksine, GitLab kendi sunucunuza kurulabilir (Self-Managed). Atlassian'ın Bitbucket'ı, Jira ve Confluence ile sıkı entegrasyona sahiptir ve bu da onu halihazırda Atlassian ekosistemini kullanan ekipler için tercih haline getirir.