Git Submodule Nedir, Nasıl Kullanılır?

Git Submodule Nedir?

Git submodule, bir Git deposunun içine başka bir Git deposunu bağımlılık olarak bağlayan yapıdır. Ana depo (üst proje) alt depodaki dosyaları kendi içine kopyalamaz; sadece o alt deponun hangi commit'te durduğuna dair bir işaretçi tutar. Bu işaretçiyi Git, .gitmodules dosyasında ve özel bir dizin girdisinde saklar.

Üst projeyi klonlayan biri, submodule klasörünün yolunu ve hangi commit'i beklediğini görür; ama o commit'in dosyalarını ayrı bir adımda siz indirirsiniz. Bu ayrım kafa karıştırıcı görünse de, aslında iki farklı geçmişi birbirine karıştırmadan bir arada tutmanın yoludur. Alt depo, üst projeden bağımsız olarak kendi dallarına, etiketlerine ve katkı sürecine sahip kalır.

Gitmodules Dosyası Ne İşe Yarar?

.gitmodules, her bir git submodule kaydının yerel yolunu ve uzak depo adresini eşleştiren düz metin dosyasıdır. Bu dosyayı üst projeyle birlikte commit edersiniz; böylece depoyu klonlayan herkes, hangi alt projenin hangi URL'den geleceğini aynı yerden görür. Dosyayı elle düzenlemek mümkündür, ancak biz ekip olarak git submodule komutlarının üretmesini öneriyoruz.

• Path: Alt deponun üst projedeki klasör adı.
• Url: Alt deponun klonlanacağı uzak adres.
• Branch (opsiyonel): Güncelleme sırasında takip ettiğiniz dal adı.

Birden fazla submodule içeren büyük bir projede .gitmodules dosyası tek bakışta tüm bağımlılık haritasını gösterir. İç içe geçmiş submodule'ler, yani bir submodule'ün kendi içinde başka bir submodule barındırması da mümkündür; bu durumda --recursive bayrağı her katmanı sırayla işler.

Bu yapının resmi davranışını merak eden geliştiriciler için Git projesinin kendi dokümantasyonu en sağlam kaynaktır; Git Tools: Submodules bölümü her komutun tam davranışını ve sürümler arasındaki farkları ayrıntılı açıklar. Biz de bu rehberdeki komutları hazırlarken aynı kaynağı doğruluk kontrolü için kullandık.

Git Submodule'ü Ne Zaman Kullanmalısınız?

Git submodule, üzerinde ayrıca çalışmanız gereken ama ayrı bir geçmişte tutulması gereken bir bileşen söz konusu olduğunda mantıklı bir seçimdir. Örneğin paylaşılan bir arayüz kitaplığını birkaç farklı projede kullanıyorsanız ve o kitaplığa zaman zaman kendiniz katkı veriyorsanız, submodule işe yarar. Buna karşılık yalnızca tüketilen, hiç dokunulmayan bir bağımlılık için paket yöneticisi genelde daha basit bir yoldur.

Örnek senaryo olarak, aynı doğrulama kurallarını birden fazla web projesinde kullanan bir ekip düşünelim. Kurallar ayrı bir depoda tutulur, her proje o depoyu submodule olarak çeker ve ihtiyaç oldukça güncelleme adımını çalıştırır. Bu düzen, kuralların tek bir yerden yönetilmesini sağlarken her projenin ayrı hızda güncellenmesine de izin verir.

Git Submodule ile Paket Yöneticisi Arasındaki Fark Nedir?

Bir paket yöneticisi (npm, Composer, pip gibi) bağımlılığı sürüm numarasıyla indirir ve siz onun kaynak kodunu genelde değiştirmezsiniz. Git submodule ise tam bir Git deposu getirir; dolayısıyla alt projenin kendi dalları, commit geçmişi ve değişiklik yapma imkanı vardır. Bu yüzden sadece "kullanmak" istiyorsanız paket yöneticisi, "birlikte geliştirmek" istiyorsanız git submodule daha uygundur.

Tabloda görülen fark, günlük iş akışına da yansır. Paket yöneticisiyle çalışan bir ekip sürüm numarasını yükseltip ilerler; submodule kullanan bir ekip ise hem üst projedeki işaretçiyi hem alt depodaki commit'i aynı anda yönetmek zorundadır. Bu ek sorumluluk, sağladığı esnekliğin bir bedelidir.

Git Submodule Nasıl Eklersiniz?

Bir git submodule eklemek için üst projenin köküne giderek git submodule add <depo-adresi> komutunu çalıştırırsınız. Farklı bir klasör adı istiyorsanız komuta yol parametresi eklersiniz, örneğin git submodule add <depo-adresi> kutuphaneler/arayuz. Komut çalıştıktan sonra Git, .gitmodules dosyasını oluşturur ya da günceller; bu dosyayı diğer değişikliklerle birlikte commit edersiniz.

1. Üst projenin kök dizinine geçin.
2. git submodule add komutunu uzak adresle çalıştırın.
3. Oluşan .gitmodules dosyasını ve yeni klasörü git add ile işaretleyin.
4. Değişikliği açıklayıcı bir mesajla commit edin.

Ekleme işlemi tamamlandığında, üst proje içinde yeni bir klasör ve o klasörün özel bir Git girdisi olarak göründüğünü fark edersiniz. Bu girdi normal bir klasörden farklıdır: içine girip durum kontrolü yaptığınızda kendi ayrı deposunun durumunu görürsünüz, üst projenin durumunu değil.

Birden fazla alt bağımlılığı tek tek ekleyip her birinde aynı komutları tekrarlamak yerine, git submodule foreach komutu tüm submodule'ler üzerinde aynı işlemi sırayla çalıştırmanıza izin verir. Bu, özellikle birçok bağımlılığı olan büyük projelerde zaman kazandırır ve her alt depoyu tek tek gezmeye gerek bırakmaz.

Submodule İçeren Bir Depoyu Nasıl Klonlarsınız?

Standart git clone komutu, submodule klasörlerini boş bırakır; çünkü ana klonlama alt depoların içeriğini otomatik indirmez. Bunun yerine git clone --recurse-submodules <adres> kullanmanız, iç içe geçmiş submodule'ler dahil her şeyin ilk seferde gelmesini sağlar. Depoyu zaten standart yöntemle klonladıysanız git submodule update --init --recursive komutu aynı işi sonradan tamamlar.

Büyük depolarda bu adım biraz zaman alabilir, çünkü her bir alt depoyu kendi tam geçmişiyle indirirsiniz. Yavaş bağlantılarda yalnızca gereken derinliği indirmek isteyen ekipler için sığ klonlama seçenekleri de vardır, ancak bu ayrı bir konu olduğundan burada detaya girmiyoruz.

Submodule Klasörü Neden Boş Geliyor?

Bu, ekiplerin en çok şikayet ettiği durumdur: biri depoyu klonlar, submodule klasörünü açar ve içinin boş olduğunu görür. Sebep nettir: klonlama sırasında --recurse-submodules bayrağını atlamışsınızdır ya da klonlama sonrasında init ve update adımlarını hiç çalıştırmamışsınızdır. Çözüm, git submodule update --init --recursive komutunu çalıştırmaktır; bu komut önce submodule yapılandırmasını başlatır, sonra işaretlenen commit'i indirir.

Bu sorunu kök çözümle önlemek isteyen ekipler, README dosyasına klonlama komutunu doğru bayrakla yazar ve kurulum betiğine aynı kontrolü ekler. Böylece yeni katılan bir geliştirici, elle hatırlaması gereken bir adımla karşılaşmaz.

Submodule Güncellemelerini Nasıl Çekersiniz?

Üst projeyi güncellediğinizde, submodule'ün işaretçisi de değişmiş olabilir; ancak bu, alt klasörün dosyalarını otomatik güncellemez. Üst projedeki kayıtlı commit'e geçmek için git submodule update --init --recursive komutunu çalıştırırsınız. Git 2.14 ve sonrasında git config submodule.recurse true ayarını bir kez yaptıktan sonra normal git pull işlemi de submodule'leri otomatik günceller.

Bu ayarı global olarak yapmak, ekibin tamamı için tekrarlanan hatayı ortadan kaldırır. Ayar yapılmadan çalışan eski bilgisayarlarda ise pull sonrası durum kontrolü yapıp submodule'ün değiştiğini görünce elle güncelleme çalıştırmak hâlâ gereklidir.

Bu adımları her geliştiricinin elle takip etmesini beklemek yerine, proje kurulum dokümanına kısa bir kontrol listesi eklemek pratikte daha sağlam sonuç verir. Yeni katılan bir geliştirici, listeyi takip ederek güncelleme adımını atlamadan kuruluma başlar.

Kontrol listesine ayrıca bir doğrulama adımı eklemek de işe yarar: güncelleme sonrası klasörün içinde beklenen dosyaların gerçekten bulunduğunu kısaca kontrol etmek. Bu küçük alışkanlık, boş ya da eksik kalmış bir alt klasörü ilerideki bir derleme hatasından önce yakalamanıza yardımcı olur.

Uzak Depodaki Yeni Commit'leri Submodule'e Nasıl Alırsınız?

Üst projenin işaretçisini değil, alt deponun kendi uzak dalındaki en yeni halini istiyorsanız git submodule update --remote komutunu kullanırsınız. Bu komut, .gitmodules dosyasında tanımlı dalın en son commit'ini çeker. Yalnızca belirli bir submodule'ü güncellemek isterseniz komuta o submodule'ün yolunu ekleyebilirsiniz; ardından üst projede yeni işaretçiyi commit etmeyi unutmayın, aksi halde diğer ekip üyeleri eski sürümde kalır.

Takip ettiğiniz dalı sabitlemek isterseniz git config -f .gitmodules submodule.<ad>.branch <dal> komutuyla bu bilgiyi dosyaya yazabilirsiniz. Böylece --remote bayrağı her çalıştığında hangi daldan çekileceği belirsiz kalmaz, ekip içinde aynı sonucu üretir.

Bu adımı ihmal eden ekiplerde, farklı geliştiricilerin bilgisayarlarında alt bağımlılık farklı dallara göre güncellenebilir ve sonuçta herkes aynı proje üzerinde farklı davranışlarla karşılaşır. Dalı bir kez .gitmodules dosyasına yazmak, bu tutarsızlığı kaynağında engeller.

Submodule İçinde Detached HEAD Sorunu Nedir?

git submodule update komutu, alt depoyu belirli bir commit'e "detached HEAD" halinde açar; yani herhangi bir dala bağlı değildir. Bu durumda doğrudan commit yaparsanız, bir sonraki güncelleme işlemi o commit'leri erişilemez bırakabilir. Dolayısıyla alt dizinde çalışma yapmadan önce git checkout <dal-adi> ile bir dala geçmeniz gerekir; ancak bu şekilde çalışırsanız yaptığınız değişiklikleri güvenle korursunuz.

Bu durumu fark etmeden commit yapmış bir geliştirici panik yapmamalı: Git o commit'leri hemen silmez, sadece dal referansı olmadan bunlara erişmek zorlaşır. Bu durumda git reflog komutu, detached HEAD halindeyken yapılan commit'lerin kimliğini bulmaya yardımcı olabilir; bulunan commit bir dala taşınarak kurtarılır.

Submodule Değişikliklerini Push Etmeden Önce Nelere Dikkat Edersiniz?

Üst projeyi push etmeden önce alt depodaki commit'lerin de uzak sunucuya gittiğinden emin olun. Aksi halde başka bir geliştirici üst projeyi çekse bile submodule'ün işaret ettiği commit'i bulamaz. Bu kontrolü otomatikleştirmek için git push --recurse-submodules=check komutunu kullanabilirsiniz; bu komut, henüz push etmediğiniz submodule commit'i varsa işlemi durdurur. Alternatif olarak git push --recurse-submodules=on-demand seçeneği, önce submodule'leri, sonra üst projeyi otomatik olarak gönderir.

Bu iki bayraktan birini ekip genelinde varsayılan haline getirmek isterseniz git config push.recurseSubmodules on-demand ayarını yapabilirsiniz. Böylece her geliştirici bayrağı elle hatırlamak zorunda kalmaz, push işlemi her zaman güvenli sırayla ilerler.

Dal Değiştirince Submodule Referansı Neden Değişir?

Farklı dallar farklı submodule commit'leri işaret edebilir. Dal değiştirdiğinizde Git, submodule içeriğini otomatik güncellemez; bu yüzden klasör eski commit'te kalmış gibi durur. Git 2.13 ve sonrasında git checkout --recurse-submodules <dal> komutu dal değişimiyle birlikte submodule'leri de doğru commit'e taşır. Ekip genelinde bu sorunu kökten çözmek için git config submodule.recurse true ayarını her geliştiricinin yapmasını öneririz.

Bu ayar olmadan çalışan bir ekipte, dal değiştirdikten sonra git status çıktısı submodule satırını "modified" olarak gösterir. Bu genelde bozukluk değildir; sadece klasörün henüz yeni dalın işaret ettiği commit'e güncellenmediğini gösterir ve bir update komutuyla düzelir.

Submodule Pointer Çakışmasını Nasıl Çözersiniz?

İki kişi aynı submodule'ün farklı commit'lerini işaretleyip farklı dallarda ilerlerse, birleştirme sırasında Git bu çakışmayı kendi başına çözemez. git diff çıktısında iki ayrı commit kimliği görürsünüz. Alt depoya girip hangi commit'in doğru olduğuna karar verir, gerekirse ikisini birleştirip yeni bir commit oluşturursunuz; ardından üst projeye dönüp o submodule yolunu git add ile işaretleyip çakışmayı kapatırsınız. Benzer bir birleştirme mantığı normal dosya çakışmalarında da geçerlidir; konuyu derinlemesine ele alan git merge conflict nasıl çözülür yazımıza da göz atabilirsiniz.

Çakışmayı çözerken yanlışlıkla her iki tarafın commit'ini de kaybetmemek için önce hangi değişikliğin daha güncel olduğunu, hangi özelliklerin korunması gerektiğini ekip içinde kısaca konuşmak faydalıdır. Alt depo kendi başına bir Git projesi olduğu için orada da normal dal birleştirme kuralları geçerlidir.

Bu tür bir çakışma, genelde iki geliştiricinin aynı bağımlılığı aynı anda farklı amaçlarla güncellemeye çalıştığında ortaya çıkar. Çakışma öncesinde kısa bir haberleşme, hangi tarafın değişikliğinin öncelikli olduğunu netleştirip birleştirme işini büyük ölçüde kolaylaştırır.

Var Olan Bir Klasörü Submodule'e Nasıl Dönüştürürsünüz?

Zaten üst projenin bir parçası olarak takip edilen bir klasörü submodule'e çevirmek istediğinizde Git doğrudan izin vermez; aynı yolda iki farklı takip mekanizması çakışır. Önce git rm -r <klasor> ile klasörü üst projenin takibinden çıkarır, ardından aynı yola git submodule add komutunu çalıştırırsınız. Bu adım öncesinde klasörün bir yedeğini almanız, olası veri kaybını önler.

Dönüştürme sırasında klasörün eski commit geçmişini alt depoya taşımak isterseniz, bu ayrı bir geçmiş birleştirme işlemidir ve dikkatli planlama gerektirir. Çoğu ekip pratikte yeni bir alt depo oluşturup geçmişi sıfırdan başlatmayı, karmaşık geçmiş taşıma işlemine girmekten daha kolay bulur.

Submodule URL'si Değişirse Ne Yaparsınız?

Alt deponun adresi değişirse, önce .gitmodules dosyasındaki url satırını güncellersiniz. Ardından git submodule sync --recursive komutu yerel yapılandırmayı yeni adrese eşitler. Son olarak git submodule update --init --recursive çalıştırarak her geliştiricinin bilgisayarında doğru kaynaktan içerik çekilmesini sağlarsınız.

Bu üç adımı sırayla uygulamadan sadece .gitmodules dosyasını değiştirmek yeterli olmaz; yerel yapılandırma dosyasında eski adres kayıtlı kalır ve güncelleme sessizce başarısız olabilir. Sync adımı tam olarak bu eski kaydı tazeler.

Git Submodule ile Monorepo Arasındaki Fark Nedir?

Git submodule, ayrı geçmişi olan birden fazla depoyu gevşek bağlarla birbirine bağlar; her alt proje kendi deposunda yaşar. Monorepo ise tam tersine, birçok projeyi tek bir depo ve tek bir commit geçmişinde tutar. Submodule, bağımsız sürümlenen fakat birlikte kullanılan bileşenler için uygundur; monorepo ise ekiplerin tüm kodu birlikte görmesini ve aynı anda değiştirmesini istediği durumlarda daha uygun bir seçim olur. İki yaklaşımın avantaj ve dezavantajlarını karşılaştırdığımız monorepo nedir, avantajları ve dezavantajları yazımızda bu tercihi daha ayrıntılı değerlendiriyoruz.

Bazı ekipler iki yaklaşımı birlikte kullanır: ana ürün kodunu monorepo içinde tutar, nadiren değişen ve başka projelerle paylaşılan bir bileşeni ise submodule olarak ekler. Bu karma kullanım, her yöntemin güçlü olduğu yerde devreye girmesini sağlar.

Submodule Kullanırken Ekip İçinde Nelere Dikkat Etmelisiniz?

Bir git submodule içeren proje üzerinde çalışan ekip, ortak bir kural seti benimsemelidir. Klonlama talimatlarına --recurse-submodules bayrağını mutlaka ekleyin, README dosyasında bu adımı açıkça belirtin. Submodule içinde doğrudan commit yapmadan önce bir dala geçmeyi standart haline getirin. Sürekli entegrasyon hattınızda da submodule init ve update adımlarının çalıştığından emin olun; aksi halde derleme eski koda göre ilerler.

• Klonlama komutlarını --recurse-submodules ile belgeleyin.
• submodule.recurse ayarını ekip genelinde zorunlu kılın.
• Alt depoda çalışmadan önce bir dala geçme alışkanlığı edinin.
• CI betiklerine submodule update --init --recursive adımını ekleyin.

Bu kuralları bir kerelik sözlü anlaşma olarak bırakmak yerine proje dokümantasyonuna yazılı şekilde eklemek, ekibe yeni katılan birinin aynı hataları tekrarlamasını önler. Küçük bir kurulum kontrol listesi, zamanla biriken karışıklığın önüne geçer.

Ekip büyüdükçe bu kuralların bir kişinin hafızasında kalması yetmez. Yeni katılan geliştiricilerin aynı hatayı tekrarlamaması için kuralları kısa, güncel bir dokümana yazmak ve zaman zaman gözden geçirmek, uzun vadede çok daha az sürpriz yaşanmasını sağlar.

Git Submodule Kullanmanın Yaygın Tuzakları Nelerdir?

En sık görülen tuzak, eski bir referansı fark etmeden geride bırakmaktır; üst projeyi çekersiniz ama alt klasör eski commit'te kalır, çünkü güncelleme adımını atlamışsınızdır. İkinci yaygın hata, klonlama sırasında --recurse-submodules bayrağını unutmaktır; bu durumda alt klasör tamamen boş kalır. Üçüncü tuzak, detached HEAD halindeyken submodule içinde doğrudan commit yapıp sonra o commit'leri kaybetmektir. Dördüncüsü ise submodule'deki değişikliği push etmeden üst projeyi push etmek; böylece başka bir geliştirici üst projeyi çekse bile ihtiyacı olan commit'i bulamaz.

Bu dört tuzağın ortak noktası, submodule'ün "iki katmanlı" doğasının göz ardı edilmesidir. Üst proje ve alt depo ayrı ayrı yönetilmesi gereken iki durumdur; biri güncellenirken diğerinin de güncellendiğinden emin olmak, submodule ile çalışmanın temel disiplinidir.

Git Submodule Alternatifleri Nelerdir?

Submodule tek başına bir seçenek değildir. Git subtree, alt projenin dosyalarını üst projenin geçmişine doğrudan birleştirir ve ayrı bir klonlama adımı gerektirmez; buna karşılık geçmiş daha karmaşıklaşır. Paket yöneticileri (npm, Composer, pip gibi) yalnızca tüketilen, üzerinde değişiklik yapılmayan bağımlılıklar için daha sade bir yoldur. Monorepo yaklaşımı ise ayrı depoları tamamen ortadan kaldırıp her şeyi tek depoda toplar. Hangi yöntemin uygun olduğu, bağımlılığa ne kadar sık dokunduğunuza ve ekibin alışkanlıklarına bağlıdır.

Küçük bir ekip için en basit yol, gerçekten gerekmediği sürece submodule'den kaçınmaktır. Submodule'ün sunduğu esneklik, ekstra komutları doğru sırayla hatırlama yükünü de getirir; bu yük, bağımlılığa ne kadar sık dokunulduğuyla dengelenmelidir.

Yeni bir proje kurarken bu değerlendirmeyi erkenden yapmak, ileride yöntem değiştirme zorunluluğundan kaynaklanan ekstra işi önler. Ekip küçükken basit tutmak, büyüdükçe ihtiyaç netleştiğinde doğru aracı seçmek genelde en sağlıklı yoldur.

Karar verirken basit bir soru sormak yardımcı olur: bağımlılığın kaynak koduna ne sıklıkla dokunacaksınız? Cevap "hiç" ise paket yöneticisi yeterlidir. Cevap "düzenli olarak" ise submodule ya da subtree değerlendirilmeye değer; "her gün, aynı anda" ise monorepo daha uygun bir yön olabilir.

Açık Kaynak Bir Bağımlılığı Submodule Olarak Kullanırken Nelere Dikkat Edersiniz?

Açık kaynak bir kitaplığı git submodule olarak projenize eklediğinizde, o projenin lisansını ve katkı kurallarını incelemeniz gerekir. Kitaplığa düzeltme göndermek isterseniz kendi fork'unuz üzerinden ilerlemeniz ve submodule'ün url alanını kendi fork adresinize yönlendirmeniz pratik bir yoldur. Açık kaynak projelere katkı sürecini adım adım ele aldığımız açık kaynak projelerine katkı rehberimiz rehberimiz, bu süreci daha ayrıntılı açıklıyor.

Fork üzerinden ilerlediğinizde, upstream projedeki güncellemeleri zaman zaman kendi fork'unuza almanız gerekir; aksi halde submodule'ünüz gerçek projeden giderek uzaklaşır. Bu senkronizasyonu düzenli bir alışkanlık haline getirmek, ileride büyük bir fark biriktirmeyi önler.

Fork'unuzu güncel tutmak için belirli aralıklarla upstream deposunu kontrol etmek ve önemli düzeltmeleri kendi kopyanıza taşımak yeterlidir. Bu küçük bakım adımını ihmal eden ekipler, aylar sonra fork ile asıl proje arasında köprü kurmanın çok daha zor olduğunu fark eder.

Submodule İçindeki .env Dosyası Yanlışlıkla Commit Edilirse Ne Olur?

Submodule kendi deposu olduğundan, kendi .gitignore kuralları geçerlidir ve üst projenin kuralları alt depoyu kapsamaz. Alt depoda bir .env dosyası yanlışlıkla commit edilirse, sızıntı o alt deponun geçmişinde kalır ve üst projeyi temizlemek yetmez. Bu konuyu ayrıntılı ele aldığımız .env dosyası sızıntı temizleme rehberimiz yazımızdaki adımları, bu durumda doğrudan submodule'ün kendi deposuna uygularsınız.

Bu yüzden her submodule'ün kendi .gitignore dosyasını da üst projeninkiyle aynı dikkatle hazırlamak gerekir. Yeni bir submodule eklerken önce yapmanız gereken işlerden biri, hassas dosyaların o alt depoda da doğru şekilde hariç tutulduğunu kontrol etmektir.

Git Submodule Hangi Geliştirme Araçlarıyla Birlikte İyi Çalışır?

Submodule içeren bir projeyi takım arkadaşlarınızla aynı şekilde çalıştırmak isterseniz, geliştirme ortamını da standartlaştırmak işinizi kolaylaştırır. Konteyner tabanlı bir geliştirme ortamı, submodule klonlama ve güncelleme adımlarını otomatik hale getirebilir; bu yaklaşımı VS Code dev container nedir yazımızda anlatıyoruz. Kod biçimlendirme araçlarının submodule'ler arasında tutarlı çalışması için de ekip genelinde aynı kurallar gerekir; bu konuda ESLint ve Prettier çakışmasını çözme rehberimiz başlıklı yazımız yol gösterici olur.

Paket kurulum araçlarını da unutmamak gerekir; bazı ekipler submodule'ü klonladıktan sonra pnpm install gibi bir komutu o alt dizinde ayrıca çalıştırır. Kurulum betiğine bu adımı da eklemek, yeni bir geliştiricinin elle hatırlaması gereken işlem sayısını azaltır.

Git Submodule Yapılandırmasını Kim Doğru Kurar?

Talha Aslan ve ekibi olarak özel yazılım projelerinde birden çok bileşenin ayrı depolarda yaşadığı durumlarla sık karşılaşırız. Bileşenler ortak bir çatı altında geliştirildiğinde git submodule yapısını kuruyor ve ekip içi dokümantasyonunu hazırlıyoruz. Bu tür bir proje ortamına ihtiyacınız varsa özel yazılım geliştirme hizmetimize göz atabilirsiniz. Doğru kurulan bir submodule yapısı, ekibin ileride karışıklığa düşmesini engeller.

Kurulum sırasında dikkat ettiğimiz nokta, teknik tercihin ekibin günlük iş akışına uyup uymadığıdır. Bazen submodule yerine daha basit bir çözüm yeterli olur; bu kararı vermek için önce ekibin hangi bileşene ne sıklıkla dokunduğunu anlamak gerekir.

Bu değerlendirmeyi proje başında birlikte yapıp kararı yazılı hale getirmek, ekip büyüdüğünde "neden bu şekilde kurulmuştu" sorusuna hazır bir yanıt bırakır. Küçük bir not, aylar sonra çok zaman kazandırabilir ve kararın arkasındaki gerekçeyi yeni gelen kişiye tekrar tekrar anlatma yükünü de ortadan kaldırır.

Kurulumu teslim ederken ekip için kısa bir kullanım notu da hazırlıyoruz; böylece proje bize bağlı kalmadan, herkesin anlayabileceği basit adımlarla ilerleyebiliyor. Bu şeffaflık, uzun vadeli bakımın kolaylaşmasında belirleyici rol oynar.

Git Submodule Komutlarını Hatırlamak İçin Ne Yapmalısınız?

Submodule komutlarının çoğu git submodule alt komutunun devamıdır: add, init, update, sync, foreach. Bu komutları ezbere bilmek zorunda değilsiniz; önemli olan hangi durumda hangi komuta ihtiyacınız olduğunu kavramaktır. Temel Git komutlarını ve günlük akışı tazelemek isterseniz Git ve GitHub kullanım rehberi yazımız, submodule'den önceki temel adımları özetliyor.

Bir ipucu olarak, sık kullandığınız komutları takma adlarla kısaltmak günlük işi hızlandırır. Örneğin uzun bir güncelleme komutunu kısa bir takma ada bağlamak, doğru bayrakları her seferinde yazmak zorunda kalmamanızı sağlar ve hata riskini azaltır.

Son olarak, bir git submodule yapısını ekibe tanıtırken küçük bir alıştırma yapmak faydalıdır. Yeni bir geliştirici depoyu klonlasın, güncellesin ve alt depoda kasıtlı olarak küçük bir değişiklik yapıp geri alsın. Bu kısa alıştırma, komutların kağıt üzerinde değil elde nasıl davrandığını gösterir ve ilk gerçek sorunla karşılaşıldığında paniği azaltır.