Merak ediyorum, distributed version control sistemleri içinde en yaygın olan Git’in nasıl çalıştığını tam olarak anlayamıyorum. Local ve remote repository’ler arasında kod değişikliklerinin nasıl senkronize edildiğini, commit’lerin ve branch’lerin arka planda nasıl yönetildiğini detaylarıyla açıklayabilir misiniz? Özellikle distributed yapının offline çalışma ve offline senkronizasyon avantajları neler?
Git’in distributed version control mantığı nasıl işliyor?
👁️ 5 görüntüleme💬 3 cevap❤️ 0 beğeni
3 Cevap
Git’in nasıl çalıştığını ilk öğrendiğimde kafamda bir ışık dağılımı gibi oldu aslında. Bir projemde offline çalışmak zorundaydım, uçak yolundayken sadece dizüstü bilgisayarla kodlama yapabiliyordum. Normalde SVN gibi merkezî sistemlerde internet olmadan bir şey yapamazdın, ama Git’te öyle değil! Hatta o uçak yolculuğunda yaptığım değişiklikleri commit’ledim, branch’ladım, notlar aldım. Sonra eve gidip internet olduğunda `git push` yaptım ve tüm değişiklikler remote’a senkronize oldu. Dağınık yapı sayesinde herkesin kendi lokalinde tam bir repository olması, değişiklikleri alıp gönderebilme özgürlüğü veriyor. Commit’ler de sanki bir zaman kapsülü gibi; her biri bir snapshot gibi geçmişe bakmanı sağlarken, branch’ler de farklı gelişim hatlarını paralel olarak yönetebilmeni kolaylaştırıyor. Offline senkronizasyonda da commit’leri lokalde saklayıp, internet varsa pushladığın için aslında hiçbir şey kaybolmuyor. Gerçekten dağıtılmış yapının en güzel yanı bu offline çalışma esnekliği.
Git'in distributed özelliklerini bizzat her gün kullanıyorum ve offline çalışma esnekliği benim için olmazsa olmaz. İlk olarak, her repository’nin (hem local hem remote) tam bir kopyası olduğunu unutma – yani bir commitle birlikte tüm tarihçeyi ve branch’leri de yerelinde saklıyorsun. Bu sayede ne WiFi’e bağlı olmana ne de server’a ulaşmana gerek kalmadan kodunda değişiklik yapabilir, commit’leri gerçekleştirebilirsin. Offline’da `git commit` yaptığında aslında sadece local repository’ne kaydediyorsun; sonrasında online olduğunda `git push` komutuyla sadece değişiklikleri (diff’leri) remote’a gönderiyorsun. Yani network bağlantısı olmadan bile çalışmaya devam edebiliyorsun, sadece senkronizasyonu geciktirmiş oluyorsun.
Remote’a erişim problemi olmayınca local commit’lerinin ne kadar dağınık olabileceğine şaşıyorsun – örneğin bir feature branch’inde çalışırken başka bir issue için hotfix branch’i açıp offline’da değişiklikler yapabiliyorsun. Remote’a bağlandığında ise `git pull` dediğinde sadece diğer branch’lerden yapılan değişiklikleri değil, tüm history’yi karşılaştırıp uyumlu hale getiriyor. Benzer şekilde push sırasında conflict’leri local’de çözüp tekrar remote’a gönderiyorsun. Bu distributed yapının bana en çok fayda sağladığı yer, uzun uçak yolculukları sırasında bile commit’lerimi düzenli bir şekilde yapabilmemdi – sonunda sadece bir `git push` ile her şeyi senkronize ediyorum.
Git’in distributed mantığı aslında en güzel yanı offline’dayken bile rahatça çalışabilmen. Tam senkronizasyon gereken yerdeyse yine sen karar veriyorsun. Local repo’nda commit atıyorsun mesela, diğerleriyle haberleşmeye gerek yok, offlineken de rahatça dallanıp budaklanabiliyorsun. Ben de uzun bir uçak yolculuğunda branch’ler üzerinde çalışıp tekrar buluştuğumda merge’i hallettim, offline avantajı burada ortaya çıkıyor.
Remote’lara itildiğindeyse aslında sadece local’de yapılmış değişiklikleri paylaşıyorsun - commit history’i ve branch’leri de beraberinde götürüyorsun. Mesela benim projede sıkça kendi local’de commit’lerim oluyor, sonra remote’a push’luyorum, böylece hem backup olmuş oluyor hem de takım arkadaşlarım değişiklikleri kendi local’lerinde çekebiliyor. Branch’leri de aynı şekilde local’de oluşturup remote’a gönderebiliyorsun, örneğin feature branch’imi geliştirip sonrasında PR’a açtım - Git’in distributed yapısı sayesinde herkesin local’inde kendi versiyonu var, senkronizasyonda esneklik sağlıyor.
Tartışmaya katılmak için giriş yap
Giriş Yap