Git ve Versiyon Kontrolü: Ekip Çalışmasının Görünmeyen Altyapısı
Branch, merge, code review: bir ekip yazılım geliştirirken ortak dil budur.
Mert Celal Yılmaz · Full Stack Developer · Güncellendi:
İki geliştirici aynı dosyanın aynı satırına aynı anda dokunduğunda ne olur? Git tam olarak bunun cevabını veren bir versiyon kontrol sistemi: kod üzerindeki her değişikliği, kim ne zaman neyi değiştirdi bilgisiyle birlikte saklıyor. Branch mantığı sayesinde bir özellik üzerinde ana koddan bağımsız çalışabiliyorsun, iş bitince merge ile birleştiriyorsun.
ARCA'da GitLab üzerinden çalışıyoruz, görev takibini Jira ile yapıyoruz. Agile süreçte bir sprint başladığında hangi branch'in hangi task'a karşılık geldiği, merge request'in kim tarafından review edileceği net; bu düzen olmadan birkaç kişi bile aynı repoda çalışırken birbirinin işine çorap örer.
Bir apartman yönetim sisteminde iki kişilik bir ekipte hem sprint planlamayı hem code review sürecini yürüttüm. İki kişi bile olsa merge conflict'leri, review yorumları, commit mesajlarının anlamlı olması işin ilerleyişini doğrudan etkiliyor. BTK Akademi'nin 'Versiyon Kontrolleri: Git/GitHub' sertifikasını da bu süreçte aldım, günlük kullanımdaki boşlukları netleştirmek için.
Birkaç ay sonra hangi merge request'in hangi task'ı kapattığını hâlâ bulabiliyor olmak, iyi kurulmuş bir Git akışının en somut faydası.
Git aslında dosya farklarını değil, her commit'te dosya sisteminin o anki halinin bir anlık görüntüsünü (snapshot) tutuyor; değişmeyen dosyalar önceki commit'e referans veriyor, bu da geçmişe gidip belirli bir commit'i checkout etmeyi hızlı kılıyor. Rebase ile merge arasındaki fark da burada devreye giriyor: merge iki dalın geçmişini olduğu gibi birleştirip yeni bir commit oluşturuyor, rebase ise senin commit'lerini başka bir dalın ucuna taşıyıp geçmişi yeniden yazıyor. Ekipte paylaşılan bir branch'i rebase etmek, başkalarının o commit'lere dayanan işini bozabileceği için risk taşıyor; ben bunu genelde sadece kendi local branch'imde, henüz push etmeden temiz bir geçmiş için kullanıyorum.
Git'in conflict'leri otomatik çözdüğü izlenimi yanıltıcı; satır bazında çakışma yoksa merge sorunsuz geçer ama iki farklı satırda yapılan değişiklik birbirini mantıksal olarak bozuyorsa (örneğin bir metodun imzası değişmiş, diğer branch eski imzayı çağırıyor) Git bunu conflict olarak görmez, kod derlenir ama çalışma zamanında patlar. Bu yüzden code review'u sadece 'diff temiz mi' diye bakmak için değil, iki branch'in birbirini nasıl etkilediğini anlamak için de kullanıyorum; küçük, sık commit'ler bunu kolaylaştırıyor çünkü büyük bir merge request'te bu tür çakışmaları gözden kaçırmak çok daha kolay.