UNITY İLE GİT VE VERSİYONLAMA AKIŞI KURMAK VE ÇAKIŞMALARI AZALTMAK

Unity projelerinde doğru bir Git ve versiyonlama akışı, sahne ve prefab değişikliklerinde bile ekibi daha az sürtüşmeyle ilerletir; bu yazıda hangi klasörlerin sürümleneceğini, .gitignore ve Git LFS kurulumunu, Editor ayarlarını, branch ve PR kurallarını ile YAML merge yapılandırmasını kurarak çakışmaları azaltmayı öğreneceksiniz.

1. Unity Git versiyonlama akışını netleştirmek ve standartlaştırmak

Başlıktan türeyen ana odak, Unity Git versiyonlama akışı kurmaktır. Burada amaç; dosya tiplerine göre doğru stratejiyi seçmek, branch düzenini belirlemek ve ekipçe uygulanabilir kuralları yazılı hale getirmektir; bu düzeni pratikte hızla standarda dönüştürmek isteyenler için kapsamlı Unity eğitimi içerikleri ekip standardı oluşturmayı destekler.

Kuralları yazılı hale getirmek

“Kuralların yazılı olması” genelde hafife alınır; ama bir hafta sonra aynı tartışmayı tekrar yaşamamak için küçük bir doküman bile büyük fark yaratır. Örneğin “hangi dosyalar commitlenir, hangi dosyalar asla eklenmez, sahne değişiklikleri nasıl paylaşılır” gibi maddeler netleşince çatışma sayısı düşmeye başlar.

Proje deposu yapısını sade tutmak ve okunabilir kılmak

Unity tarafında depoya sadece gerekli klasörleri almak temel adımdır. Genellikle Assets, Packages ve ProjectSettings sürümlemeye girer; derleme çıktıları ve önbellekler dışarıda kalır. Bu yaklaşım, depo boyutunu şişirmeden ekip senkronunu korur.

2. .gitignore düzenini doğru kurmak ve gereksizi dışarıda bırakmak

Unity projelerinde en yaygın hatalardan biri, Library ve Temp gibi klasörlerin yanlışlıkla depoya girmesidir. Bu durum hem repo boyutunu büyütür hem de “bende çalışıyor sende çalışmıyor” tartışmalarını artırır. İyi bir .gitignore ile daha baştan gereksizi elemek gerekir.

Unity için tipik .gitignore kalıbını uygulamak ve güncel tutmak

Aşağıdaki örnek, sık kullanılan bir başlangıç noktasıdır. Proje ihtiyaçlarına göre küçük eklemeler yapılabilir; önemli olan, ekipte herkesin aynı kurala uymasıdır.

# Unity cache / generated
[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Bb]uild/
[Bb]uilds/
[Ll]ogs/
[Uu]ser[Ss]ettings/

# IDE
.vscode/
.idea/
*.csproj
*.sln
*.user
*.userprefs

# OS
.DS_Store
Thumbs.db

Bu listeyi kullanırken “neden dışarıda bırakıyoruz?” sorusuna kısa bir yanıt eklemek işe yarar: Bu klasörler yeniden üretilebilir, makineden makineye değişir ve sürümleme yerine tekrar üretmek daha doğrudur.

3. Git LFS ile büyük dosyaları yönetmek ve depo boyutunu kontrol etmek

Unity’de texture, ses, video ve bazı 3D dosyalar hızla büyür. Bu tür dosyalar normal Git takibiyle depo boyutunu şişirebilir ve clone/pull sürelerini uzatabilir. Bu noktada Git LFS kullanmak, büyük dosyaları ayrı bir depolama katmanında tutarak çalışma akışını rahatlatır.

Hangi dosyaları LFS’ye almak gerektiğini belirlemek ve listelemek

Her büyük dosyayı LFS’ye almak şart değildir; ama sık değişen ve büyük olan ikili dosyalar için LFS mantıklı olur. Örnek bir .gitattributes yaklaşımı aşağıdaki gibidir.

# Large binary assets
*.psd filter=lfs diff=lfs merge=lfs -text
*.tga filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
*.mp4 filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text

Burada kritik nokta, ekipte herkesin LFS’yi kurmuş olmasıdır. Aksi halde bazı kişiler dosyaları “pointer” olarak görür ve çalışma bozulur. Onboarding dokümanına “LFS kurulumu ve doğrulaması” adımını eklemek gerekir.

4. Unity Editor ayarlarını ekipçe aynı hale getirmek ve merge’i kolaylaştırmak

Çakışmaları azaltmanın en etkili yöntemlerinden biri, Unity’nin metin tabanlı serileştirme ve görünür meta dosyası üretmesi için ayarlamaktır. Bu sayede sahne ve prefab değişiklikleri daha anlaşılır diff’ler üretir.

Force Text ve Visible Meta Files ile farkları okunur hale getirmek

Unity Editor’da Edit > Project Settings > Editor bölümünde şu iki ayar çok önemlidir:

• Asset Serialization: Force Text seçmek
• Version Control: Visible Meta Files seçmek

Bu ayarlar aktifken .meta dosyaları depoya girer, GUID eşleşmeleri stabil kalır ve “asset kayboldu” problemleri belirgin şekilde azalır.

5. Branch stratejisini belirlemek ve teslimata göre ilerlemek

Birçok ekipte çatışmaların asıl nedeni teknik değil, iş akışı belirsizliğidir. “Herkes main’e commit atıyor” gibi bir düzen, özellikle sahne dosyalarında çakışmayı kaçınılmaz yapar. Bu yüzden branch stratejisini proje ritmine göre seçmek gerekir.

Trunk tabanlı akışla küçük ve sık entegrasyon yapmak

Kısa süreli feature branch’ler, küçük commit’ler ve sık merge, çatışmaları daha yönetilebilir kılar. Temel yaklaşım şudur:

1. Feature branch açmak (ör. feature/ui-settings)
2. Küçük adımlarla commit atmak
3. Gün içinde main’den sık rebase/merge almak
4. Hazır olunca Pull Request ile ana dala girmek

Bu düzen, “iki hafta sonra devasa merge” yerine “günlük küçük uyumlama” yaratır. Ekip, değişimi erken görür ve sürpriz azalır.

6. Pull Request kuralları koymak ve kod incelemeyi netleştirmek

PR süreci sadece kod kalitesi için değil, Unity asset değişikliklerini görünür kılmak için de önemlidir. Özellikle sahne/prefab değişiklikleri tek kişinin elinde kalmayınca, sürpriz geri dönüşler azalır.

PR şablonu ile sahne, prefab ve ayar değişikliklerini açıklamak

Basit bir PR şablonu bile şu bilgileri ister hale getirebilir: “Hangi sahneler değişti, hangi prefab güncellendi, yeni paket eklendi mi, test edildi mi?” Bu sayede karar vericiler için de risk daha ölçülebilir olur.

Önerilen birkaç kural:

• PR başına tek ana amaç hedeflemek
• Scene/prefab değişikliklerini kısa maddelerle yazmak
• Derleme veya playmode test notunu eklemek
• Gerekirse ekran kaydı ya da kısa açıklama linki koymak

7. Unity sahne ve prefab çakışmalarını azaltmak ve kural koymak

En çok çatışma üreten alanlar çoğunlukla Scene ve Prefab dosyalarıdır. Bunun nedeni, birçok kişinin aynı anda aynı objeleri taşıması, referansları değiştirmesi ve düzeni bozmasıdır. Teknik ayarlar kadar, ekip davranışını yöneten kurallar da gerekir.

Sahneyi bölmek, additive yüklemek ve sorumluluğu paylaşmak

Tek bir büyük sahnede herkesin çalışması yerine, additive scene yaklaşımıyla sahneyi bölmek çatışmayı düşürür. Örneğin:

• Environment
• Gameplay
• UI
• Lighting

Bu bölümlerin ayrı sahnelerde tutulması, aynı dosyaya dokunan kişi sayısını azaltır. Özellikle seviyelendirme yapılan projelerde bu yaklaşım çok işe yarar.

8. Merge ayarlarını yapılandırmak ve YAML tabanlı diff’i iyileştirmek

Unity, metin tabanlı serileştirme kullandığında dosyalar YAML benzeri bir yapıya dönüşür. Yine de merge sırasında “sıralama değişiklikleri” gibi gürültüler çıkabilir. Bu noktada .gitattributes ile belirli dosyalar için merge davranışı tanımlamak yararlıdır.

.gitattributes ile Unity YAML merge aracını devreye almak

Unity’nin Smart Merge (UnityYAMLMerge) aracı doğru yapılandırıldığında özellikle prefab ve scene birleşimlerinde yardımcı olabilir. Bunun için depo dokümanında “hangi işletim sisteminde nerede bulunur” bilgisi de yer almalıdır. Temel örnek:

# Use Unity Smart Merge for scenes and prefabs
*.unity merge=unityyamlmerge eol=lf
*.prefab merge=unityyamlmerge eol=lf
*.asset merge=unityyamlmerge eol=lf

Ardından Git config tarafında merge driver tanımı yapılır. Bu ayar, ekip standardı olarak script ile dağıtılabilir. Önemli nokta: herkesin aynı aracı aynı şekilde çalıştırmasıdır; aksi halde sonuçlar tutarsız olur.

9. Commit mesajlarını standartlaştırmak ve izlenebilirliği artırmak

Proje yönetimi tarafında sürüm izlemek için commit mesajları çok değerlidir. “fix”, “feat”, “chore” gibi kısa etiketler, hangi değişikliğin ne amaçla yapıldığını netleştirir. Özellikle hata ayıklamada “hangi commit kırdı?” sorusu daha hızlı cevaplanır.

Conventional commits benzeri etiketlemeyi benimsemek ve uygulamak

Örnek bir düzen:

• feat: yeni özellik eklemek
• fix: hata düzeltmek
• refactor: davranışı değiştirmeden düzenlemek
• chore: yapılandırma ve bakım yapmak

Commit mesajını kısa tutmak, açıklamayı PR’da genişletmek iyi çalışır. Ayrıca sürüm notu çıkarmak gerektiğinde de bu yapı hız kazandırır.

10. Takım içi onboarding adımlarını yazmak ve süreklilik sağlamak

En iyi kurallar bile yeni gelen biri aynı düzeni kuramazsa boşa düşer. Bu nedenle “ilk gün yapılacaklar” listesini yazmak gerekir: depo klonlamak, LFS kurmak, Unity sürümünü ayarlamak, proje ayarlarını kontrol etmek ve ilk build almak gibi.

Kişiye bağlı bilgiyi ekip standardına çevirmek

Burada hedef, kişiye bağlı bilgi yerine ekipçe erişilebilir bir standart oluşturmaktır. Bu yaklaşım, teslim tarihleri sıkışıkken bile yeni katılan birinin hızlı üretime geçmesine yardım eder.

Özetle: Unity’de Git akışını kurmak sadece bir depo açmak değildir; hangi dosyaların sürümleneceğini seçmek, LFS ile büyük dosyaları yönetmek, Editor ayarlarını uyumlamak, branch ve PR kurallarıyla çakışmayı azaltmaktır. Bu yapı oturduğunda ekip, daha az zamanını sorun çözmeye daha çok zamanını üretmeye ayırır.

Bu yaklaşımı ekipçe uygulamak ve pratikte hızla standarda dönüştürmek için Unity eğitim programı içerikleri, sürümleme alışkanlığını sahaya taşımaya yardımcı olur.