Git ve GitHub Nasıl Kullanılır? Commit'ten Pull Request'e Sürüm Kontrolü

Git ve GitHub nedir, aralarındaki fark ne?

Git, dosyalardaki değişiklikleri zaman içinde kaydeden dağıtık bir sürüm kontrol sistemidir. Bilgisayarınızda çalışır; her kayıt noktası (commit), projenin o anki hâlini saklar ve istediğiniz noktaya geri dönmenize imkân verir. Aynı proje üzerinde birçok kişi, birbirinin dosyasını ezmeden çalışabilir.

GitHub ise Git depolarını barındıran, üzerine iş birliği araçları ekleyen bir platformdur: uzak depo, pull request, kod incelemesi, sorun takibi ve otomasyon. Kısacası Git araçtır, GitHub o aracın etrafındaki ortak çalışma ortamıdır. Başka barındırma hizmetleri de aynı Git'i kullanır.

Adım adım: temel Git akışı

• Depoyu oluşturun ya da kopyalayın: Yeni bir proje için boş bir depo başlatın, var olan projeyi ise uzak depodan klonlayın.
• Değişiklik yapın: Dosyaları düzenleyin; Git hangi dosyaların değiştiğini izler.
• Hazırlık alanına ekleyin (stage): Kaydetmek istediğiniz değişiklikleri seçin. Bu, ilgisiz değişiklikleri ayrı kayıtlara bölmenizi sağlar.
• Commit atın: Değişiklikleri açıklayıcı bir mesajla kaydedin. İyi bir mesaj, neyin neden değiştiğini anlatır.
• Uzak depoya gönderin (push) ve güncellemeleri alın (pull): Yerel çalışmanızı ekiple paylaşın.
• Geçmişe bakın: Kimin neyi ne zaman değiştirdiğini ve hatanın nerede başladığını geçmişten izleyin.

Branch, merge ve rebase

Branch (dal), ana kodu bozmadan yeni bir özellik ya da hata düzeltmesi üzerinde çalışmanın yoludur. Her iş kendi dalında ilerler; hazır olduğunda ana dala birleştirilir. Küçük, tek amaçlı dallar incelemeyi ve geri almayı kolaylaştırır.

Birleştirmenin iki yaygın yolu vardır. Merge, iki dalın geçmişini bir birleştirme kaydıyla bir araya getirir ve geçmiş olduğu gibi korunur. Rebase ise dalınızın başlangıç noktasını güncel ana dala taşıyarak geçmişi doğrusal hâle getirir. Rebase temiz bir geçmiş sağlar ama başkalarıyla paylaşılmış dallarda kullanılması karışıklığa yol açar; paylaşılmış geçmişi yeniden yazmaktan kaçının.

İki dal aynı satırı farklı değiştirdiğinde çakışma (conflict) oluşur. Git hangi yerlerin çakıştığını işaretler; hangi sürümün kalacağına siz karar verirsiniz. Çakışma bir hata değil, normal bir ekip çalışması durumudur.

GitHub ile iş birliği: pull request ve kod incelemesi

Pull request, dalınızdaki değişiklikleri ana dala almak için yaptığınız tekliftir. Takım arkadaşları değişiklikleri satır satır inceler, yorum bırakır, düzeltme ister ya da onaylar. Bu süreç hem hataları erken yakalar hem de bilgiyi ekipte paylaştırır.

Etkili bir pull request küçük ve tek konuludur, değişikliğin nedenini açıklar ve ilgili sorun kaydına bağlanır. GitHub'ın sorun takibi (issues) ve proje panoları, işlerin planlanması için de kullanılır. Ayrıca GitHub Actions ile değişiklik gönderildiğinde testlerin ve derlemenin otomatik çalışması sağlanabilir; böylece birleştirmeden önce temel kontroller yapılmış olur.

Somut örnek: ekip içinde bir hata düzeltmesi

Örneğin bir ekip üyesi giriş ekranında bir hata fark etsin. Güncel ana daldan yeni bir dal açar, düzeltmeyi yapar ve açıklayıcı bir mesajla kaydeder. Dalı GitHub'a gönderip pull request açar, hatanın nasıl tekrarlandığını yazar.

Bir meslektaşı değişikliği inceler, bir kenar durumuna dikkat çeker. Düzeltme aynı dala eklenir, otomatik testler geçer ve pull request ana dala birleştirilir. Hata kaydı kapanır; kimin neyi neden değiştirdiği geçmişte okunabilir şekilde kalır.

Yaygın sorun senaryoları ve çözümleri

Git kullanırken karşılaşılan birkaç durum, yeni başlayanlar için gerilim kaynağıdır ama çözümleri düzenlidir. Yanlış dalda çalıştığınızı fark ettiyseniz, henüz commit atmadıysanız değişiklikleri geçici olarak saklayıp (stash) doğru dala geçin ve oradan geri yükleyin. Commit attıysanız doğru dala geçip o commit'i tek başına alabilirsiniz.

Çakışma çıktığında panik gerekmez: Git, çakışan dosyayı işaretler, her iki tarafın sürümünü gösterir. Hangi parçanın kalacağını seçersiniz, dosyayı kaydeder, hazırlama alanına ekler ve birleştirmeyi tamamlarsınız. Çözüm sonrası uygulamayı çalıştırıp testleri koşmak, hatalı birleştirmeyi yakalar.

Yanlışlıkla bir gizli anahtarı depoya gönderdiyseniz, sadece dosyayı silmek yetmez, çünkü anahtar geçmişte kalır. Önce ilgili anahtarı iptal edip yenisini üretmek gerekir; geçmişi temizlemek ikinci adımdır. Bir de "ne zaman ne bozuldu" sorusu için geçmişte ikili arama yaklaşımı vardır: Git, iyi ve kötü olduğunu bildiğiniz iki nokta arasında adım adım sizi yönlendirir ve hatayı getiren commit'i bulur.

Öğrenme yolu ve sık yapılan hatalar

Başlangıç aşamasında depo, commit, push ve pull akışına odaklanın. Sonra dallanma, birleştirme ve çakışma çözmeyi öğrenin. Orta düzeyde pull request kültürü, etiketleme, geçici saklama (stash) ve değişiklikleri geri alma gelir. İleri düzeyde rebase ile geçmişi düzenleme, hata aramak için geçmişte ikili arama, dallanma stratejileri ve büyük depolarla çalışma (monorepo) yer alır.

• Anlamsız commit mesajları: Geçmişi okunmaz hâle getirir.
• Çok büyük commitler: Farklı konuları karıştırır, incelemeyi ve geri almayı zorlaştırır.
• Gizli bilgileri depoya koymak: Parola ve anahtarlar geçmişte kalır, silinse bile erişilebilir olabilir; bu bilgiler depo dışında tutulmalıdır.
• Paylaşılmış dalda zorla gönderim: Başkalarının çalışmasını ezebilir.
• Güncel olmayan daldan çalışmak: Birleştirme sırasında gereksiz çakışmalara yol açar.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Mindset kataloğundaki "GIT ve GITHUB Uzmanlığı Eğitimi" Git'e giriş ve temel kavramlar, branch yönetimi ve merge işlemleri, GitHub ile işbirliği ve proje yönetimi, ileri düzey Git teknikleri, GitHub Actions ile CI/CD ve açık kaynak katkı süreçlerini ele alır. "Git İleri Seviye: Branching, Rebase ve Monorepo" eğitimi ise Git nesne modeli ve referanslar, dallanma stratejileri ve birleştirme, geçmiş düzenleme ve sorun teşhisi ile monorepo iş akışları ve ekip standardı üzerine yoğunlaşır.