Git ile Sürüm Kontrolü: Projeniz Neden Depoda Olmalı?
Sitenizin veya yazılımınızın kodu yalnızca sunucuda ya da bir geliştiricinin bilgisayarında duruyorsa ciddi bir risk taşıyorsunuz. Git ile sürüm kontrolünün işletmenize ne kazandırdığını anlattım.
İçindekiler
Sitenizde küçük bir değişiklik yapıldı ve ardından iletişim formu çalışmaz hale geldi. Neyin değiştiğini kimse tam olarak hatırlamıyor; dosyalar sunucuda doğrudan düzenlenmiş, eski sürüm de yok. Ya da yıllardır çalıştığınız geliştiriciyle yollarınız ayrıldı ve kodun güncel hali yalnızca onun bilgisayarında duruyor. Bu iki durumun ortak çözümü Git ile sürüm kontrolü yapmaktır. Bu yazıda Git’in ne olduğunu, işletme sahibi olarak size neden önemli olduğunu ve iyi bir depo düzeninin nasıl olması gerektiğini anlatıyorum.
Sürüm kontrolü nedir?
Sürüm kontrolü, bir projedeki dosyalarda yapılan her değişikliğin kim tarafından, ne zaman ve neden yapıldığını kayıt altına alan sistemdir. Her kayıt bir “anlık görüntü” gibidir; istediğiniz zaman geçmişteki herhangi bir noktaya bakabilir, iki sürümü karşılaştırabilir veya hatalı bir değişikliği geri alabilirsiniz.
Bir belge üzerinde “son_hali”, “son_hali_2”, “gercek_son_hali” diye dosya kopyaları biriktirdiğiniz oldu mu? Sürüm kontrolü bu dağınıklığın düzenli ve güvenilir halidir.
Git nedir?
Git, bugün yazılım dünyasında en yaygın kullanılan açık kaynak sürüm kontrol sistemidir. Dağıtık yapıdadır; yani projenin tam geçmişi her geliştiricinin bilgisayarında ve merkezi depoda birlikte bulunur. GitHub, GitLab ve Bitbucket gibi hizmetler ise Git depolarını çevrim içi barındıran, ekip çalışmasını kolaylaştıran platformlardır.
Git ile sürüm kontrolü işletmenize ne kazandırır?
Git, geliştiricinin aracı gibi görünse de faydaları doğrudan işletmeye yansır:
- Tam değişiklik geçmişi: Bir sorun çıktığında hangi değişikliğin buna yol açtığı hızla bulunur.
- Güvenli geri dönüş: Hatalı bir güncelleme dakikalar içinde geri alınabilir.
- Kaynak kodu sahipliği: Depo sizin hesabınızda olduğunda kodunuz tek bir kişinin bilgisayarına bağımlı kalmaz.
- Ekip çalışması: Birden fazla geliştirici aynı projede birbirinin işini bozmadan çalışabilir.
- Ek yedek katmanı: Kodun güncel hali hem depoda hem geliştiricilerin bilgisayarlarında bulunur.
- Şeffaflık: Ne üzerinde çalışıldığını ve neyin değiştiğini kayıtlardan görebilirsiniz.
Temel kavramlar: Commit, dal ve birleştirme
Git’i kullanmak için uzman olmanıza gerek yok, ama birkaç kavramı bilmek geliştiricinizle konuşmayı kolaylaştırır:
| Kavram | Anlamı |
|---|---|
| Depo (repository) | Projenin tüm dosyalarının ve geçmişinin tutulduğu yer |
| Commit | Bir grup değişikliğin açıklamasıyla birlikte kaydedilmesi |
| Dal (branch) | Ana koddan ayrılıp bağımsız çalışılan kopya; yeni özellikler burada geliştirilir |
| Birleştirme (merge) | Bir daldaki değişikliklerin ana koda eklenmesi |
| Etiket (tag) | Belirli bir sürümün işaretlenmesi, örneğin canlıya çıkan sürüm |
Günlük kullanımda bir geliştiricinin yaptığı işlem kabaca şöyle görünür:
git checkout -b iletisim-formu-duzeltme
git add .
git commit -m "İletişim formundaki doğrulama hatası düzeltildi"
git push origin iletisim-formu-duzeltme
Yani yeni bir dal açılır, değişiklik yapılır, açıklamasıyla kaydedilir ve depoya gönderilir. Ardından değişiklik gözden geçirilip ana koda birleştirilir.
İyi bir depo düzeni nasıl olmalı?
Git kullanmak tek başına yeterli değildir; deponun düzenli tutulması gerekir. Projelerimde dikkat ettiğim temel kurallar şunlardır:
- Anlamlı commit mesajları: “Düzeltme” yerine “Sepette kargo ücreti hesaplama hatası giderildi” gibi açıklayıcı mesajlar.
- Ana dalın korunması: Canlıdaki kod ana dalda durur; doğrudan oraya değil, ayrı dallarda çalışılır.
- Gizli bilgilerin depoya girmemesi: Şifreler, API anahtarları ve ortam dosyaları depo dışında tutulur.
- Gereksiz dosyaların dışlanması: Yüklenen görseller, önbellek ve bağımlılık klasörleri depoya eklenmez.
- Sürüm etiketleri: Canlıya çıkan her sürüm etiketlenir; gerekirse o sürüme tam olarak dönülebilir.
- Kısa bir README: Projenin nasıl kurulacağı ve çalıştırılacağı yazılı olur; yeni bir geliştirici günlerce uğraşmaz.
Gizli bilgi depoya girerse ne olur?
Bir şifre veya API anahtarı bir kez depoya gönderilirse, sonradan silinse bile geçmişte kalır. Bu durumda yapılması gereken, ilgili anahtarı hemen iptal edip yenisini oluşturmaktır. Önlemenin yolu ise baştan doğru bir dışlama listesi kullanmaktır.
Git, otomatik yayın ve test ortamı
Git ile sürüm kontrolü, modern yazılım sürecinin temelidir. Kod depoya gönderildiğinde testlerin otomatik çalışması ve onaylanan değişikliklerin sunucuya otomatik aktarılması mümkün hale gelir. Bu yaklaşımı CI/CD nedir yazısında anlattım. Değişikliklerin canlıya çıkmadan önce denendiği ayrı bir ortamın nasıl kurulacağını ise staging ortamı yazısında bulabilirsiniz.
Bu yapı kurulduğunda “sunucuya FTP ile bağlanıp dosya değiştirme” dönemi kapanır. Her değişiklik kayıtlıdır, gözden geçirilir ve geri alınabilir.
Kaynak kodu sahipliği: Depo kimin hesabında?
İşletme sahipleri için belki de en önemli konu budur. Yazdırdığınız yazılımın deposu yalnızca geliştiricinin kişisel hesabında duruyorsa, kodun fiilen kontrolü sizde değildir. İş ilişkisi sona erdiğinde ya da geliştiriciye ulaşılamadığında ciddi sorunlar yaşanabilir.
Önerim şudur: depo, işletmenin kendi hesabında ya da organizasyonunda açılsın, geliştirici bu depoya yetkili kullanıcı olarak eklensin. Bu konuyu sözleşme boyutuyla birlikte kaynak kodu teslimi yazısında ayrıca ele aldım.
Bu işi nasıl birlikte yaparız?
Mevcut projenizi Git’e taşımak ya da yeni projenizi baştan düzenli bir depo yapısıyla başlatmak istiyorsanız birlikte şöyle ilerleriz:
- Mevcut durumu inceleme: Kodun nerede durduğunu, canlıdaki sürümle aynı olup olmadığını ve içinde gizli bilgi bulunup bulunmadığını kontrol ederim.
- Kapsam ve teklif: Deponun hangi hesapta açılacağını, dal düzenini ve gerekiyorsa otomatik yayın kurulumunu içeren bir plan ve teklif sunarım.
- Taşıma ve düzenleme: Kodu depoya aktarır, gizli bilgileri ayırır, dışlama listesini ve README dosyasını hazırlarım.
- Teslim: Depo erişimini size teslim eder, değişiklik geçmişini nasıl takip edebileceğinizi kısaca gösteririm.
Projenizi değerlendirmek için bana yazabilirsiniz.
Sık sorulan sorular
Git ile sürüm kontrolü küçük projeler için de gerekli mi?
Evet. Tek sayfalık bir tema düzenlemesi bile hatalı bir değişiklikten sonra geri alınmak istenebilir. Küçük projelerde Git’in kurulumu birkaç dakika sürer, sağladığı güvence ise kalıcıdır.
Git ile GitHub aynı şey mi?
Hayır. Git, sürüm kontrol yazılımının kendisidir. GitHub, GitLab ve Bitbucket ise Git depolarını çevrim içi barındıran ve ekip çalışması için ek özellikler sunan platformlardır.
WordPress sitesi Git ile yönetilebilir mi?
Evet. Özellikle özel tema ve eklenti kodları Git ile yönetilmelidir. Yüklenen görseller ve veritabanı ise Git’e değil, yedekleme sistemine aittir.
Depoyu kendi hesabıma almak için ne yapmalıyım?
Kendi adınıza bir hesap veya organizasyon açıp geliştiricinizden depoyu oraya aktarmasını isteyebilirsiniz. Geliştirici çalışmaya yetkili kullanıcı olarak devam eder, sahiplik ise sizde kalır.
Sonuç
Git ile sürüm kontrolü; kodunuzun geçmişini kayıt altına alır, hataları geri almayı kolaylaştırır ve yazılımınızın sahipliğini güvence altına alır. Projenizi düzenli bir depoya taşımak için destek isterseniz iletişim sayfasından ulaşabilirsiniz.
