Sürüm Kontrol Araçları

Sürüm Kontrol Araçları

Modern yazılım projeleri sürekli değişir. Geliştiriciler özellikler ekler, hataları düzeltir, mevcut kodu yeniden düzenler, bağımlılıkları günceller ve bazen bir şeyler ters gittiğinde daha önceki bir sürüme geri dönme ihtiyacı duyarlar. Bu değişiklikleri izlemek için yapılandırılmış bir yöntem olmadan, küçük bir proje bile hızla yönetilmesi zor hale gelebilir.

Sürüm kontrol araçları, bir projenin geçmişini kaydederek ve bireylerin ve ekiplerin aynı kod tabanı üzerinde güvenli bir şekilde çalışmasına yardımcı olarak bu sorunu çözer. Ancak Git, GitHub, GitLab, Bitbucket, depolar (repositories), dallar (branches), commit'ler ve pull request'ler gibi terimler sıklıkla birbirine karıştırılır. Bu rehber, bu kavramların nasıl birleştiğini açıklamakta ve en yaygın bilinen sürüm kontrol araçlarını ve işbirliği platformlarını tanıtmaktadır.

Sürüm Kontrolü Nedir?

Sürüm kontrolü, zaman içinde dosyalarda yapılan değişiklikleri kaydeden bir sistemdir. Geliştiricilerin önceki sürümleri incelemesine, kimin neyi değiştirdiğini anlamasına, revizyonları karşılaştırmasına, silinen kodu geri yüklemesine ve bir ekip içinde çalışmayı koordine etmesine olanak tanır.

Sürüm kontrolü ile yönetilen bir proje genellikle yalnızca mevcut dosyalarından fazlasını içerir. Aynı zamanda yapılandırılmış bir değişiklik geçmişi de barındırır. Her önemli değişiklik, bir anlık görüntü olarak commit şeklinde kaydedilebilir.

Sürüm kontrolü, aşağıdaki gibi pratik soruların yanıtlanmasına yardımcı olur:

• Projenin iki sürümü arasında ne değişti?

• Belirli bir kod satırını kim ekledi?

• Bir dosya neden değiştirildi?

• Projeyi kararlı bir duruma geri yükleyebilir miyiz?

• Birden fazla geliştirici birbirinin üzerine yazmadan nasıl çalışabilir?

• Yeni bir özellik, üretime geçmeden önce nasıl incelenebilir?

Sürüm kontrolü, yazılım geliştirme ile güçlü bir şekilde ilişkilendirilse de, yapılandırma dosyalarını, dokümantasyonu, altyapı tanımlamalarını, script'leri, araştırma projelerini ve diğer metin tabanlı varlıkları da yönetebilir.

Sürüm Kontrolü Neden Temeldir?

Dosyaları project-final, project-final-2 ve project-final-really-final gibi isimlerle kaydetmek güvenilir bir versiyonlama stratejisi değildir. Bu, yinelenen dosyalar oluşturur ancak anlamlı bir geçmiş sağlamaz veya bir sürümün diğerinden nasıl farklı olduğunu açıklamaz.

Uygun bir sürüm kontrol sistemi, birkaç önemli yetenek sunar:

• Geçmiş: Kaydedilen her değişiklik, bir yazar, tarih, mesaj ve tam dosya farklarını içerebilir.

• Kurtarma: Gerekirse önceki sürümler incelenebilir veya geri yüklenebilir.

• Paralel Geliştirme: Geliştiriciler, ana kodu hemen değiştirmeden ayrı dallar üzerinde çalışabilirler.

• İşbirliği: Ekipler, değişiklikleri inceleyebilir, tartışabilir, onaylayabilir ve birleştirebilir (merge).

• Sorumluluk: Geçmiş, bir değişikliğin projeye ne zaman ve neden girdiğini gösterir.

• Otomasyon: Commit'ler ve önerilen değişiklikler, testleri, derlemeleri (builds), güvenlik kontrollerini ve dağıtımları (deployments) tetikleyebilir.

Sürüm kontrolü bu nedenle sadece bir yedekleme mekanizması değildir. Geliştirme iş akışının, kod inceleme sürecinin, yayın stratejisinin ve yazılım teslimat hattının (software delivery pipeline) bir parçasıdır.

Sürüm Kontrol Sistemi ve Barındırma Platformu Karşılaştırması

En yaygın başlangıç hatalarından biri, Git ve GitHub'ı aynı ürün olarak kabul etmektir. Birbiriyle ilişkilidirler, ancak farklı sorunları çözerler.

• Git, bir geliştiricinin bilgisayarına kurulu, dağıtık bir sürüm kontrol sistemidir.

• GitHub, Git depolarını barındıran ve işbirliği özelliklerini ekleyen çevrimiçi bir platformdur.

• GitLab, Bitbucket ve Azure Repos da Git depolarını barındırır ve ekip odaklı araçlar sunar.

Bir GitHub hesabı oluşturmadan Git'i yerel olarak kullanabilirsiniz. Bilgisayarınızda bir depo başlatabilir, commit'ler oluşturabilir, dallar yapabilir, değişiklikleri birleştirebilir ve proje geçmişini tamamen inceleyebilirsiniz.

Çevrimiçi bir barındırma platformu, aşağıdaki durumlarda kullanışlı hale gelir:

• Deponun uzak bir kopyasını depolamak.

• Projeyi diğer geliştiricilerle paylaşmak.

• Pull request veya merge request açmak.

• Kodu incelemek ve değişiklikleri tartışmak.

• Sorunları ve proje görevlerini takip etmek.

• Otomatik test ve dağıtımı yapılandırmak.

• İzinleri, ekipleri ve korumalı dalları yönetmek.

Farkı hatırlamanın basit bir yolu şudur:

Git, kodun geçmişini yönetir. Bir barındırma platformu ise bu geçmiş etrafındaki işbirliğini yönetir.

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

Merkezi Sürüm Kontrolü

Merkezi bir sistemde, ana depo merkezi bir sunucuda depolanır. Geliştiriciler, dosyaları almak ve değişiklikleri göndermek için bu sunucuya bağlanır.

Bu model, kolay bir yönetim ve net bir merkezi doğru kaynağı sağlayabilir. Ancak, geçmişe erişim ve işbirliği, merkezi sunucunun kullanılabilirliğine daha çok bağlı olabilir.

Yaygın olarak SVN olarak adlandırılan Apache Subversion, iyi bilinen merkezi bir sürüm kontrol sistemidir.

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

Dağıtık bir sistemde, her geliştiricinin genellikle deponun ve geçmişinin yerel bir kopyası bulunur. Commit oluşturma, geçmişi görüntüleme, revizyonları karşılaştırma ve dallar oluşturma gibi birçok işlem yerel olarak gerçekleşebilir.

Git ve Mercurial, dağıtık sürüm kontrol sistemleridir. Dağıtık modelleri, çevrimdışı çalışmayı, esnek işbirliği kalıplarını ve birden fazla uzak depoyu destekler.

Git: Temel Sürüm Kontrol Aracı

Git, ücretsiz, açık kaynaklı, dağıtık bir sürüm kontrol sistemidir. Proje geçmişini izlemek ve geliştiriciler ile ortamlar arasında değişiklikleri koordine etmek için kullanılır.

Git, depolarla çalışır. Bir depo, proje dosyalarını ve Git'in geçmişlerini izlemek için ihtiyaç duyduğu bilgileri içerir.

Önemli Git kavramları şunları içerir:

• Depo (Repository): Git tarafından yönetilen bir proje.

• Çalışma Dizini (Working directory): Şu anda düzenlenebilir durumda olan dosyalar.

• Hazırlık Alanı (Staging area): Bir sonraki commit'e nelerin dahil edileceğini seçmenizi sağlayan bir hazırlık alanı.

• Commit: Seçilen değişikliklerin kaydedilmiş bir anlık görüntüsü.

• Dal (Branch): Bağımsız bir geliştirme hattı.

• Birleştirme (Merge): Farklı dallardaki değişiklikleri birleştirme süreci.

• Uzak (Remote): Deponun başka bir kopyasına referans, genellikle çevrimiçi barındırılır.

• Etiket (Tag): Bir sürümü işaretlemek için yaygın olarak kullanılan adlandırılmış bir referans.

Temel bir yerel Git iş akışı şöyle görünebilir:

git init
git add .
git commit -m "Create the initial project structure"

Bir özellik için ayrı bir dal oluşturmak için:

git switch -c feature/user-login

# Edit the project files

git add .
git commit -m "Add user login validation"

Özellik daha sonra test edildikten ve incelendikten sonra ana dala birleştirilebilir.

Git Ne Zaman Doğru Seçimdir?

Git, çoğu modern yazılım projesi için standart başlangıç noktasıdır. Bireysel geliştiriciler, açık kaynak projeler, startup'lar, dağıtık ekipler, kurumsal sistemler, altyapı depoları ve otomatik teslimat iş akışları için uygundur.

Bir şirket GitHub, GitLab, Bitbucket veya Azure DevOps kullanıyor olsa bile Git öğrenmek değerlidir, çünkü bu platformlar büyük ölçüde Git kavramlarına ve işlemlerine dayanır.

GitHub: Depo Barındırma ve Küresel İşbirliği

GitHub, Git depolarını barındırmak ve yazılım projeleri üzerinde işbirliği yapmak için bir platformdur. Açık kaynak geliştirme, herkese açık portföyler, özel şirket depoları, dokümantasyon ve topluluk odaklı projeler için yaygın olarak kullanılır.

Merkezi işbirliği özelliği pull request'tir. Bir pull request, bir daldaki değişikliklerin incelenmesini ve başka bir dala birleştirilmesini önerir.

GitHub genellikle aşağıdaki iş akışlarını destekler:

• Herkese açık ve özel Git depoları.

• Dallar (branches), çatallar (forks) ve pull request'ler.

• Satır içi kod incelemesi ve ekip tartışmaları.

• Sorunlar (issues), etiketler (labels), kilometre taşları (milestones) ve proje planlaması.

• Sürüm sayfaları (release pages) ve depo etiketleri (repository tags).

• Markdown dosyaları ve wikiler aracılığıyla dokümantasyon.

• GitHub Actions aracılığıyla otomatik iş akışları.

• Erişim kontrolleri ve dal koruma kuralları.

GitHub Pull Request Örneği

Bir geliştirici feature/payment-validation adında bir dal oluşturur, değişikliği uygular, dalı GitHub'a iter (push) ve bir pull request açar. İnceleyiciler değişen satırları inceleyebilir, yorum bırakabilir, iyileştirmeler isteyebilir ve çalışmayı onaylayabilir. Dalın birleştirilmesine izin verilmeden önce otomatik testler çalıştırılabilir.

GitHub Ne Zaman Güçlü Bir Seçimdir?

GitHub, özellikle kamuya açık görünürlük, açık kaynak işbirliği, geliştirici portföyleri, topluluk katkıları, entegrasyonlar ve geniş bir ekosistem önemli olduğunda özellikle kullanışlıdır.

GitLab: Depolar, Merge Request'ler ve Entegre Teslimat

GitLab, Git depoları etrafında inşa edilmiş bir başka büyük platformdur. Kaynak kodu barındırma, işbirliği, merge request'ler, proje planlama ve CI/CD yetenekleri sunar.

GitLab, pull request yerine merge request terimini kullanır. Konsept benzerdir: bir geliştirici değişiklikler önerir, ekip bunları inceler, otomatik kontroller çalışabilir ve onaylanan çalışma hedef dala birleştirilir.

Yaygın GitLab yetenekleri şunları içerir:

• Git depo barındırma.

• Merge request'ler ve kod incelemesi.

• Sorun takibi ve proje panoları.

• .gitlab-ci.yml aracılığıyla yapılandırılan yerleşik CI/CD pipeline'ları.

• Paket ve konteyner ile ilgili iş akışları.

• Korumalı dallar ve onay kuralları.

• Barındırma üzerinde daha fazla kontrol gerektiren kuruluşlar için kendi kendine yönetilen dağıtım seçenekleri.

GitLab Ne Zaman Güçlü Bir Seçimdir?

GitLab, genellikle depo yönetimi ve teslimat otomasyonunu yakından entegre bir ortamda isteyen ekipler tarafından tercih edilir. Birleşik bir iş akışı tercih eden veya kendi kendine yönetilen bir platforma ihtiyaç duyan kuruluşlar için faydalı olabilir.

Bitbucket: Atlassian Ekosisteminde Git İşbirliği

Bitbucket, Atlassian'ın Git depo barındırma platformudur. Dallar, pull request'ler, kod incelemeleri, depo izinleri ve otomatik pipeline'ları destekler.

Bitbucket, özellikle Jira ve Confluence gibi diğer Atlassian ürünlerini zaten kullanan ekipler tarafından sıkça değerlendirilir, çünkü geliştirme çalışmaları görevlere, gereksinimlere, dokümantasyona ve ekip süreçlerine bağlanabilir.

Yaygın Bitbucket özellikleri şunları içerir:

• Özel ve paylaşılan Git depoları.

• Dal tabanlı geliştirme.

• Pull request'ler ve birleştirme kontrolleri.

• Kod incelemesi ve inceleyici ataması.

• Otomatik derleme, test ve dağıtım görevleri için Bitbucket Pipelines.

• Depo düzeyinde izinler ve erişim belirteçleri.

• Jira iş öğeleri ve ekip iş akışlarıyla entegrasyon.

Bitbucket Ne Zaman Güçlü Bir Seçimdir?

Bitbucket, Atlassian ekosistemine zaten yatırım yapmış ekipler veya depolarının, sorun takibinin ve dokümantasyon iş akışlarının yakından bağlantılı kalmasını isteyen kuruluşlar için pratik bir seçenek olabilir.

Azure DevOps ve Azure Repos

Azure DevOps, Microsoft'un bir geliştirme hizmetleri koleksiyonudur. Depo bileşeni olan Azure Repos, Git depolarını ve pull request tabanlı işbirliğini destekler.

Azure DevOps, birkaç hizmeti tek bir organizasyonel iş akışında birleştirebilir:

• Azure Repos: Git depoları, dallar, politikalar ve pull request'ler.

• Azure Boards: İş öğeleri, birikimler (backlogs), sprint planlama ve görev takibi.

• Azure Pipelines: Derleme, test, doğrulama ve dağıtım otomasyonu.

• Azure Artifacts: Paket yönetimi.

• Testle ilgili hizmetler: Test faaliyetlerini düzenlemek ve takip etmek için araçlar.

Azure Repos'taki pull request'ler, inceleyicileri, yorumları, oylamayı, dal politikalarını, derleme doğrulamasını ve birleştirme gereksinimlerini içerebilir.

Azure DevOps Ne Zaman Güçlü Bir Seçimdir?

Azure DevOps, genellikle kurumsal ekipler, Microsoft odaklı ortamlar, yapılandırılmış iş öğesi süreçleri kullanan kuruluşlar ve depolar, panolar, pipeline'lar ve izinlere tek bir geliştirme paketi içinde ihtiyaç duyan projeler için uygundur.

Apache Subversion: Merkezi Sürüm Kontrolü

Genellikle SVN olarak adlandırılan Apache Subversion, açık kaynaklı merkezi bir sürüm kontrol sistemidir. Git'ten farklı olarak, proje geçmişinin birincil kaynağı olarak normalde merkezi bir depo kullanır.

Geliştiriciler genellikle sunucudan bir çalışma kopyası (working copy) alır, dosyaları değiştirir, yerel kopyalarını günceller ve değişiklikleri merkezi depoya commit eder.

SVN, bazı kurumsal sistemlerde, uzun süreli iç projelerde, merkezi ortamlarda ve daha basit bir sunucu kontrollü modeli tercih eden iş akışlarında geçerliliğini korumaktadır.

Git ve SVN Yüksek Düzey Karşılaştırması

• Git dağıtıktır; SVN merkezidir.

• Bir Git kopyası (clone) genellikle depo geçmişini içerir; bir SVN çalışma kopyası (working copy) doğrudan merkezi depoya daha çok bağlıdır.

• Git, yerel commit'lere ve hafif dallanmaya (lightweight branching) büyük önem verir.

• SVN, katı bir merkezi sunucu iş akışı isteyen ekipler için anlaşılması daha kolay olabilir.

SVN, eski veya merkezi olduğu için otomatik olarak kötü bir seçim değildir. Doğru karar, proje kısıtlamalarına, mevcut altyapıya, dosya türlerine, organizasyonel politikalara ve ekip deneyimine bağlıdır.

Mercurial: Dağıtık Bir Alternatif

Mercurial, ücretsiz, dağıtık bir kaynak kontrol yönetim aracıdır. Git gibi, her klonun proje geçmişine erişimini sağlar ve dağıtık iş akışlarını destekler.

Mercurial, tutarlılık ve erişilebilirlik etrafında tasarlanmış bir komut satırı deneyimi ile bilinir. Komutları hg yürütülebilir dosyasını kullanır.

Temel bir Mercurial iş akışı şöyle görünebilir:

hg init
hg add
hg commit -m "Create the initial project"

Mercurial, birçok güncel web geliştirme topluluğunda Git'ten daha az görünür olsa da, kendi iş akışları, uzantıları ve proje geçmişi olan gerçek bir dağıtık sürüm kontrol sistemi olmaya devam etmektedir.

Popüler Sürüm Kontrol Araçları ve Platformlarının Karşılaştırılması

Modern Bir Sürüm Kontrol İş Akışı Nasıl Çalışır?

Her ekibin kendi süreci olsa da, yaygın bir Git tabanlı iş akışı şu adımları izler:

1. Bir geliştirici uzak depoyu (remote repository) klonlar (clone).

2. Geliştirici bir özellik veya hata düzeltmesi için bir dal (branch) oluşturur.

3. Kod değişiklikleri yerel olarak yapılır.

4. İlgili dosyalar hazırlık alanına (staging area) eklenir.

5. Geliştirici bir veya daha fazla net commit oluşturur.

6. Dal, bir barındırma platformuna itilir (push).

7. Bir pull request veya merge request açılır.

8. Otomatik testler ve kalite kontrolleri çalışır.

9. İnceleyiciler kodu inceler ve gerektiğinde değişiklikler ister.

10. Onaylanan dal hedef dala birleştirilir (merge).

11. Birleştirilen kod bir derlemeyi (build), sürümü (release) veya dağıtım pipeline'ını tetikleyebilir.

Bu süreç, bitmemiş işi kararlı koddan ayırır ve görünür bir inceleme geçmişi oluşturur.

Anlamanız Gereken Yaygın Terimler

Depo (Repository)

Depo, yönetilen proje ve onun sürüm geçmişidir.

Commit

Commit, kaydedilmiş bir değişiklik grubudur. Güçlü bir commit, anlamlı bir iş birimini temsil etmeli ve net bir mesaj içermelidir.

Dal (Branch)

Dal, bağımsız bir geliştirme hattıdır. Ekipler genellikle özellikler, hata düzeltmeleri, deneyler ve sürümler için dallar kullanır.

Birleştirme (Merge)

Bir birleştirme, ayrı dallardaki değişiklikleri bir araya getirir.

Birleştirme Çakışması (Merge Conflict)

Çakışma, sürüm kontrol sisteminin çakışan değişikliklerin nasıl birleştirilmesi gerektiğine güvenli bir şekilde karar verememesi durumunda meydana gelir. Bir geliştiricinin etkilenen satırları incelemesi ve çözmesi gerekir.

Uzak Depo (Remote Repository)

Uzak depo, projenin başka bir kopyasıdır, genellikle bir sunucuda veya barındırma platformunda bulunur.

Klonlama (Clone)

Klonlama, bir deponun yerel bir kopyasını oluşturur.

Getirme (Fetch)

Getirme, uzak bir depodan bilgi ve değişiklikleri otomatik olarak mevcut dala entegre etmeden indirir.

Çekme (Pull)

Çekme, uzak değişiklikleri alır ve bunları mevcut yerel çalışmaya entegre etmeye çalışır.

İtme (Push)

İtme, yerel commit'leri uzak bir depoya gönderir.

Çatal (Fork)

Çatal (fork), bir deponun ayrı bir sunucu tarafı kopyasıdır ve genellikle doğrudan kontrol etmediğiniz bir projeye katkıda bulunurken kullanılır.

Pull Request veya Merge Request

Bir pull request veya merge request, bir dizi değişikliği inceleme ve birleştirme önerisidir.

CI/CD Pipeline

Bir pipeline, bağımlılıkları yükleme, testleri çalıştırma, kod kalitesini kontrol etme, derleme çıktıları (artifacts) oluşturma ve bir uygulamayı dağıtma gibi otomatik görevler dizisidir.

Doğru Aracı Nasıl Seçersiniz?

Her proje için otomatik olarak en iyi olan tek bir platform yoktur. Faydalı bir karar, sadece popülerlikten ziyade ekibin iş akışını dikkate almalıdır.

Git'i Sürüm Kontrol Temeli Olarak Seçin:

• Modern bir yazılım projesi geliştiriyorsanız.

• Dağıtık geliştirme ve yerel geçmiş istiyorsanız.

• Güçlü dallanma (branching) ve birleştirme (merging) iş akışlarına ihtiyacınız varsa.

• GitHub, GitLab, Bitbucket veya Azure Repos kullanmayı bekliyorsanız.

GitHub'ı Şu Durumlarda Düşünün:

• Açık kaynak görünürlüğü önemliyse.

• Herkese açık bir geliştirici portföyü istiyorsanız.

• Geniş bir işbirliği ve entegrasyon ekosistemine ihtiyacınız varsa.

• Ekibiniz pull request tabanlı geliştirmeyi tercih ediyorsa.

GitLab'ı Şu Durumlarda Düşünün:

• Depo barındırma ve CI/CD'yi yakından bağlantılı bir iş akışında istiyorsanız.

• Kuruluşunuz kendi kendine yönetilen barındırmaya ilgi duyuyorsa.

• Merge request merkezli geliştirmeyi tercih ediyorsanız.

Bitbucket'ı Şu Durumlarda Düşünün:

• Ekibiniz zaten Jira veya Confluence kullanıyorsa.

• Depo etkinliğinin Atlassian proje iş akışlarına bağlı olmasını istiyorsanız.

• Özel ekip işbirliğine ve entegre pipeline'lara ihtiyacınız varsa.

Azure DevOps'u Şu Durumlarda Düşünün:

• Şirketiniz Azure Boards, Azure Pipelines veya Microsoft kurumsal araçlarını kullanıyorsa.

• Ayrıntılı dal politikalarına ve yapılandırılmış onay iş akışlarına ihtiyacınız varsa.

• Kaynak kontrolü ve proje planlamasını tek bir pakette istiyorsanız.

Subversion'ı Şu Durumlarda Düşünün:

• Mevcut bir SVN tabanlı projeyi sürdürüyorsanız.

• İş akışınız bilerek merkezi kontrol gerektiriyorsa.

• Kuruluşunuzun SVN etrafında kurulmuş altyapısı ve politikaları varsa.

Mercurial'ı Şu Durumlarda Düşünün:

• Mevcut bir Mercurial projesine katkıda bulunuyorsanız.

• Ekibiniz dağıtık modelini ve komut yapısını tercih ediyorsa.

• Zaten Mercurial etrafında tasarlanmış araçlara veya altyapıya sahipseniz.

Yaygın Başlangıç Seviyesi Yanlış Anlaşılmaları

“GitHub, Git'tir”

GitHub, Git kullanır, ancak Git bağımsız olarak mevcuttur. Git sürüm kontrol motorudur; GitHub bir barındırma ve işbirliği platformudur.

“Commit, Dosya Kaydetmekle Aynı Şeydir”

Değişiklikleri kaydetmek, çalışma dizinindeki bir dosyayı günceller. Bir commit, seçilen değişiklikleri depo geçmişine bilerek kaydeder.

“Git Sadece Ekipler İçindir”

Git, geçmiş oluşturduğu, deneyleri desteklediği ve kurtarmayı kolaylaştırdığı için bireysel çalışmalar için değerlidir.

“Sürüm Kontrolü Tam Bir Yedekleme Stratejisidir”

Bir depo, proje geçmişinin önemli bir kopyasıdır, ancak veritabanları, yüklenen dosyalar, kimlik bilgileri, derleme çıktıları (build artifacts) veya üretim altyapısı için tek yedek olarak görülmemelidir.

“Her Dosya Commit Edilmelidir”

Oluşturulan dosyalar, geçici dosyalar, yerel ortam ayarları, bağımlılık klasörleri, derleme çıktıları ve sırlar genellikle depoya girmemelidir. Git projeleri bunları hariç tutmak için genellikle bir .gitignore dosyası kullanır.

“Daha Fazla Commit Her Zaman Daha İyi Geçmiş Demektir”

Amaç commit sayısını maksimuma çıkarmak değildir. Amaç, geçmişi kullanışlı hale getiren anlaşılır, odaklanmış commit'ler oluşturmaktır.

Sürüm Kontrolü İçin En İyi Uygulamalar

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

• Mümkün olduğunda commit'leri tek bir mantıksal göreve odaklayın.

• Özellikler, düzeltmeler ve deneyler için dallar kullanın.

• Riskli entegrasyonlara başlamadan önce en son değişiklikleri çekin (pull) veya getirin (fetch).

• Commit etmeden önce değişen dosyaları inceleyin.

• Asla şifreleri, API anahtarlarını, özel sertifikaları veya üretim sırlarını commit etmeyin.

• Önemli değişiklikler için pull request veya merge request kullanın.

• Birleştirmeden (merge) önce otomatik testleri çalıştırın.

• main veya sürüm dalları gibi önemli dalları koruyun.

• Kararlı sürümleri ve yayınları tutarlı bir şekilde etiketleyin.

• Ekibin dallanma, inceleme ve yayın stratejisini belgeleyin.

Pratik Bir Öğrenme Sırası

Yeni başlayanların her platformu aynı anda öğrenmelerine gerek yoktur. Pratik bir öğrenme yolu şöyledir:

1. Depoları, commit'leri, dalları ve birleştirmeleri anlayın.

2. Git'i kurun ve yerel bir depo oluşturun.

3. status, add, commit ve log'i uygulayın.

4. Dalların nasıl çalıştığını öğrenin.

5. Uzak depoları (remotes), klonlamayı (cloning), getirmeyi (fetching), çekmeyi (pulling) ve itmeyi (pushing) anlayın.

6. Bir GitHub veya GitLab deposu oluşturun.

7. Pull request veya merge request uygulamaları yapın.

8. Birleştirme çakışmalarını (merge conflicts) nasıl çözeceğinizi öğrenin.

9. Reset, restore, revert ve stash kavramlarını dikkatlice inceleyin.

10. Bir CI/CD iş akışı aracılığıyla otomatik testler ekleyin.

11. Özellik dalları (feature branches) veya trunk-based development gibi gerçek bir ekip iş akışını öğrenin.

Git temeli netleştikten sonra, GitHub, GitLab, Bitbucket ve Azure Repos arasında geçiş yapmak çok daha kolay hale gelir çünkü birçok temel kavram ortaktır.

Sıkça Sorulan Sorular

Git Kullanmak İçin GitHub'a İhtiyacım Var mı?

Hayır. Git, bir depoyu tamamen yerel bilgisayarınızda yönetebilir. GitHub, barındırma ve işbirliği için yalnızca bir seçenektir.

Aynı Git Deposu Birden Fazla Uzak Platform Kullanabilir mi?

Evet. Bir Git deposu birden fazla uzak (remote) depoya sahip olabilir. Örneğin, bir ekip birincil depoyu GitHub'da tutarken, bir kopyasını (mirror) başka bir sunucuda tutabilir.

Pull Request'ler Git'in Bir Parçası mı?

Hayır. Pull request'ler ve merge request'ler, barındırma platformları tarafından sağlanan işbirliği özellikleridir. Git'in kendisi dallar, commit'ler, farklar (diffs), birleştirmeler ve diğer depo işlemlerini sağlar.

Bir Başlangıç Seviyesi İçin Hangi Aracı Öğrenmeli?

Git temelleriyle başlayın, ardından uzak depoları ve kod incelemesini uygulamak için GitHub veya GitLab'ı kullanın. Git'i anlamadan bir platform öğrenmek, dallar, commit'ler, uzak depolar ve çakışmalar ortaya çıktığında genellikle kafa karışıklığına neden olur.

SVN Hala Kullanılıyor mu?

Evet. Bazı kuruluşlar ve uzun süredir devam eden projeler Subversion kullanmaya devam etmektedir. Ancak, birçok yeni yazılım projesi, özellikle Git olmak üzere dağıtık sürüm kontrolünü tercih etmektedir.

Git Sadece Kaynak Kod İçin midir?

Hayır. Git birçok dosya türünü takip edebilir, ancak özellikle metin dosyalarıyla iyi çalışır. Büyük ikili dosyalar ek araçlar veya farklı bir depo stratejisi gerektirebilir.

Sonuç

Sürüm kontrolü, modern yazılım geliştirmesinin tarihsel temelini sağlar. Değişiklikleri kaydeder, proje geçmişini korur, paralel çalışmayı destekler ve ekiplerin kodu kontrollü bir şekilde incelemesine ve teslim etmesine olanak tanır.

Git, birçok güncel geliştirme iş akışının merkezindeki sürüm kontrol sistemidir. GitHub, GitLab, Bitbucket ve Azure DevOps, Git depoları etrafında uzak barındırma, izinler, kod incelemesi, proje yönetimi ve otomasyon ekler. Subversion merkezi modeli temsil ederken, Mercurial başka bir dağıtık yaklaşım sunar.

En önemli ilk adım, en uzun özellik listesine sahip platformu seçmek değildir. Temel iş akışını anlamaktır: odaklanmış değişiklikler oluşturmak, bunları açıkça kaydetmek, dallar aracılığıyla çalışmak, birleştirmeden önce incelemek ve gelecekteki geliştiricilerin güvenebileceği bir geçmişi sürdürmek.

Resmi Kaynaklar

• Git Dokümantasyonu: https://git-scm.com/docs/git

• Pro Git Kitabı: https://git-scm.com/book/en/v2

• GitHub Pull Request'leri: https://docs.github.com/pull-requests

• GitLab Merge Request'leri: https://docs.gitlab.com/user/project/merge_requests/

• Bitbucket Cloud Dokümantasyonu: https://support.atlassian.com/bitbucket-cloud/

• Azure Repos Pull Request'leri: https://learn.microsoft.com/azure/devops/repos/git/pull-requests

• Apache Subversion: https://subversion.apache.org/

• Mercurial SCM: https://www.mercurial-scm.org/