Temel 1C Geliştirici Süreci: EDT + Git ile Kaostan Uzak Durun

EDT ve Git ile doğru çalışmak için şu kuralı benimseyin: 1 görev = 1 dal = anlaşılır commit'ler + kod incelemesi içeren Merge Request ve ana dal (main) her zaman kararlı kalsın. Aşağıda, bir ekip içinde hemen uygulanabilecek asgari takım süreci yer almaktadır.

Bir kez yapılacak ayarlar

1) Depo "yalnızca kaynak kodları" tutmalıdır. EDT projeyi dosya tabanlı biçimde (meta veriler/modüller) yönetir; bu nedenle önceden şunları düzenleyin:

• .gitignore — çalışma alanına/kache'lere ait hizmet dosyalarını hariç tutun;
• .gitattributes — satır sonlarını ve metin kurallarını sabitleyin ki dosyalarda toplu "yer değiştirme" sorunlarıyla karşılaşmayın.

2) Dallar konusunda anlaşın (asgari düzeyde).

• main — kararlıdır; doğrudan push yapmayın.
• feature/… — göreve özel dal.
• hotfix/… — main'den acil düzeltme.

3) "Dal → kendi bilgi tabanı" eşleşmesi. EDT'de her dal için ayrı bir bilgi tabanı (veya başlatma seçeneği) tutmak uygundur: geçişlerde "bende çalışıyor, sende çalışmıyor" sorunları daha az yaşanır.

Günlük döngü: dal → commit'ler → MR

Adım 1. Çalışmaya başlamadan önce main'den güncellenin

git checkout main
git pull

Adım 2. Görev için bir dal oluşturun

git checkout -b feature/TASK-123-short-name

Adım 3. Değişiklikleri küçük parçalar halinde yapın Kod incelemesini ve birleştirmeleri gerçekten kolaylaştıran uygulama:

• bir mantıksal parça = bir commit;
• commit'ten önce kontrol edin: proje derleniyor mu, diff'teki her değişikliği anlıyor musunuz?

Adım 4. Uygun mesajla commit yapın

git add -A
git commit -m "TASK-123: Satış belgesinde KDV hesaplaması düzeltildi"

Adım 5. Dalı gönderin ve MR/PR açın

git push -u origin feature/TASK-123-short-name

MR açıklamasında mutlaka şunlar olsun: ne yapıldığı, nasıl test edileceği, riskler (yeniden işleme, yetkiler, veri değişimi).

Adım 6. main'deki değişiklikleri düzenli olarak çekin Ekip için tek bir yaklaşım seçin:

• merge main — daha basit ve "geçmişi yeniden yazmaz";
• rebase main — doğrusal geçmiş sağlar ancak disiplin gerektirir.

EDT'de birleştirmeler ve çakışmalar

Altın kural: Çakışmaları "anlama göre" çözün, ardından derlemeyi ve bilgi tabanındaki asgari senaryoyu test edin.

Modülde çakışma varsa hızlı algoritma

1. Çakışmayı açın ve iki tarafın neyi değiştirdiğini anlayın.
2. Nihai sürümü manuel olarak oluşturun.
3. Kritik senaryonun derlenmesini/başlatılmasını kontrol edin.
4. merge/rebase işlemini tamamlayın ve sonucu commit'leyin.

Meta verilerde (form/nesne) çakışma varsa

• önce "olması gerekeni" geri yükleyin (öznitelikler, komutlar, olay işleyicileri);
• ardından formu işletme modunda açın ve kullanıcının temel eylemini kontrol edin.

Takım kuralları için kısa hatırlatma

Sık yapılan hatalar

• EDT biçimlendirmesi nedeniyle yüzlerce dosyayı kapsayan tek bir commit. Çözüm: git diff'i daha sık inceleyin, küçük parçalar halinde commit yapın, EDT ayarlarını/sürümlerini standartlaştırın.
• main ile senkronizasyon olmadan uzun ömürlü dal. Çözüm: main'i günlük (veya daha sık) çekin, aksi takdirde çakışmalar katlanarak artar.
• Refaktörleme ile iş mantığı düzeltmesini karıştırma. Çözüm: iki ayrı MR — "davranışı değiştirmeyen refaktörleme" ve "işlevsel değişiklikler".
• main'e doğrudan push. Çözüm: dal koruması + "yalnızca MR üzerinden" kuralı.

SSS

Her dal için ayrı bir bilgi tabanı oluşturmak gerekir mi?
Tercihen evet: geçişlerde yan etkiler daha az olur, hataları yeniden üretmek ve kod incelemesinden geçmek daha kolay hale gelir.

Hangisini seçmeli: merge mi rebase mi?
Başlangıç için feature dalına merge main yapmak daha basittir. Ekip kurallara uymaya hazır olduğunda (ve zaten birkaç kişi tarafından incelenen dalların geçmişini yeniden yazmadığınızda) rebase kullanın.

Ekip küçükse MR/PR olmadan çalışılabilir mi?
Önerilmez: MR bürokrasi değil, kalite kontrolüdür (bağlam, test adımları, değişiklik geçmişi) ve main'i kazara bozulmalardan korur.