Git versiyon kontrolü nasıl sağlanıyor?

01 Tem 14:30

Git’in versiyon kontrolü, her değişikliği bir "commit" olarak kaydedip birbirinden bağımsız dallar (branches) üzerinden ilerliyor. Yerel deponuzda yaptığınız değişiklikler önce staging alanı (index) üzerinden commit’lendikten sonra `git push` ile uzak depoya (örneğin GitHub) gönderiliyor. Uzaktan çekmek içinse `git pull` veya `git fetch` + `git merge` kullanıyorum, böylece commit geçmişi otomatik ya da manuel olarak birleştiriliyor. Branching’de ise `git branch` ile yeni bir dal oluşturup `git checkout <branch>` ile geçiş yapıyorum. Değişiklikleri ana dala (main/master) taşımak için `git merge` ya da `git rebase` kullanırım—merge daha basit, rebase ise geçmişi temizliyor ama dikkat gerektiriyor. Tavsiyem, küçük projelerde bile branch kullanmaya başlamak, böylece hata yaptığında geri dönüşü kolay oluyor!

01 Tem 15:06

Geçen sene takım projesi için yazılım geliştiriyorduk, her şeyi elle klasörlere kopyalayıp "yedek_2" ya da "final_version" diye adlandırırken her seferinde bir şeyler kaybediyordum. Ekibin biri "Git denen bir şey var, denesen iyi olur" dedi. İlk başta kaptırdım, bir repo oluşturduk, commit attım, her şey güzeldi ama sonra branch'ler arasında kayboldum. Özellikle `git checkout` ve `git merge` komutlarını kullanırken conflits'lerle boğuşmak eğlenceli değildi. Sonunda branching mantığını çözdüm: Temel branch (main/master) asla bozulmayan, çalışan kodun olduğu yer. Yeni bir özellik ekleyeceksen `git checkout -b yeni_ozellik` ile yeni bir branch oluşturuyorsun, orada istediğin gibi denemeler yapıp commit atıyorsun. Özelliğin bittiğini düşündüğünde main branch'ine geçip `git merge yeni_ozellik` ile değişiklikleri birleştiriyorsun. Eğer conflicts çıkarsa, sadece dosyaları elle düzelttikten sonra commit atman gerekiyor. Uzun lafın kısası, Git'in versiyon kontrolü sayesinde artık kodumu kaybetmiyorum, değişiklikleri takip edebiliyorum ve takımla kolayca senkronize olabiliyorum.

01 Tem 16:54

Git’in versiyon kontrolü, kaynak kodunda yapılan her değişikliği zamana bağlı olarak izleyerek çalışır. Diğer sistemler (örneğin SVN gibi merkezi versiyon kontrol araçları) dosyaların anlık durumunu sunucuda depolarken, Git her geliştiricinin kendi yerel makinesinde tüm tarihçeyi (geçmiş commitleri, dalları, vs.) barındıran bir *yerel depo* (local repository) oluşturur. Bu, değişiklikleri işlemeye devam edebilmek, hata durumunda geri dönmek veya offline çalışabilmek için büyük bir avantaj. Uzak depoya (remote) değişiklikleri göndermek için `git push`, karşıdan almak için `git pull` veya `git fetch` komutları kullanılıyor. `git push`, yerel branch’ınızdaki commitleri uzak depoya aktarırken, `git pull` ya da `git fetch` + `git merge`, uzak depodaki değişiklikleri yerel deponuza çekip birleştiriyor. Branching ve merging mantığıysa Git’in kalbinde yer alıyor. Diğer sistemlerde (örneğin Perforce veya eski CVS gibi) dallar nadiren kullanılırken, Git’te her an yeni bir branch oluşturmak ucuz ve anlık. Bir branch, projenin belli bir noktasından dallanarak bağımsız bir gelişim hattı oluşturuyor — bu, yeni özellikleri denemek, hataları düzeltmek veya farklı fikirleri test etmek için ideal. Merging (birleştirme) ise iki branch’ı birleştirerek değişiklikleri ana hatta entegre etmek anlamına geliyor. Git’in `merge` ve `rebase` komutları arasındaki farksa önemli: `merge` birleştirme commit’i oluştururken, `rebase` branch’ı doğrusal olarak yeniden yazarak tarihçeyi temiz tutuyor. Genellikle projelerde "feature branch" isimli dallarda çalışılır, kod incelendikten ve test edildikten sonra ana branch’e (genellikle `main` veya `master`) merge edilir. Bu sistem, hem bireysel geliştiricilerin hem de takım çalışmasının verimliliğini ciddi şekilde artırır.