7.11 Git Araçları - Alt Modüller

Eğer yalnızca bir alt projeyi tüketiyorsanız ve zaman zaman ondan güncellemeler almak istiyorsanız, ancak gerçekte kopyanızda hiçbir şeyi değiştirmiyorsanız; alt modülleri bir projede kullanmanın en basit modelini uygulayabilirsiniz. Bir örnek ile üzerinden basitçe geçelim.

Eğer bir alt modüldeki yeni çalışmayı kontrol etmek istiyorsanız, dizine gidip yerel kodu güncellemek için git fetch ve git merge komutlarını kullanabilirsiniz.

Şimdi ana projeye geri döner ve git diff --submodule komutunu çalıştırırsanız, alt modülün güncellendiğini ve ona eklenen katkıların bir listesini görebilirsiniz. git diff komutunu her çalıştırdığınızda --submodule yazmak istemiyorsanız, diff.submodule yapılandırma değerini ``log`` olarak değiştirerek bu formatı varsayılan olarak ayarlayabilirsiniz.

Bu noktada bir katkı işlerseniz, başkaları güncellediğinde alt modülü yeni koda kilitlenmiş olursunuz.

Alt dizinde manuel olarak çekme ve birleştirme yapmak istemiyorsanız, bunu yapmanın daha kolay bir yolu daha vardır. git submodule update --remote komutunu çalıştırırsanız, Git sizin için alt modüllere çekip, güncelleyecektir.

Bu komut, varsayılan olarak alt modül reposunun master dalını izlemek istediğinizi varsayar. Ancak dilerseniz, bunu farklı bir şeye de ayarlayabilirsiniz. Örneğin, DbConnector alt modülünün o reposunun ``stable`` dalını izlemesini istiyorsanız, bunu ya .gitmodules dosyanızda (böylece diğer herkes de izleyebilir) ya da sadece yerel .git/config dosyanızda ayarlayabilirsiniz. Şimdi bunu .gitmodules dosyasına ayarlayalım:

-f .gitmodules seçeneğini kullanmazsanız, sadece sizin için değişiklik yapar, ancak muhtemelen bu bilgiyi herkesin takip etmesi daha mantıklı olacaktır.

Bu noktada git status komutunu çalıştırdığınızda, Git alt modülde "yeni katkılar" olduğunu gösterecektir.

status.submodulesummary yapılandırmasını ayarlarsanız, Git ayrıca alt modüllerinizdeki değişikliklerin kısa bir özetini de gösterecektir:

Bu noktada git diff komutunu çalıştırırsanız, hem .gitmodules dosyasını değiştirdiğimizi hem de indirdiğimiz bir dizi katkının alt modül projemize işlenmeye hazır olduğunu görebilirsiniz.

Alt modülümüze işleyebileceğimiz katkıların günlüğünü görebilmemiz harika. Bir kez katkılandıktan sonra, git log -p komutunu çalıştırdığınızda, sonradan bu bilgiyi de görebilirsiniz.

git submodule update --remote komutunu çalıştırdığınızda Git, (varsayılan olarak) tüm alt modüllerinizi güncellemeye çalışacaktır, bu yüzden birçok alt modülünüz varsa, sadece güncellemek istediğiniz alt modülün adını geçirmek isteyebilirsiniz.

Alt modüller kullanıyorsanız bunun sebebi muhtemelen, ana projedeki kodla aynı anda alt modüldeki (veya birkaç alt modüldeki) kod üzerinde de çalışmak istemenizdir. Aksi takdirde, muhtemelen daha basit bir bağımlılık yönetim sistemi kullanıyor olurdunuz (örneğin Maven veya Rubygems gibi).

Şimdi, ana projede olduğu gibi alt modülde değişiklik yapma ve bu değişiklikleri aynı anda katkılama ve yayınlama örneğini inceleyelim.

Şimdiye kadar öğrendiğimiz üzere, alt modül repolarından değişiklikleri almak için git submodule update komutunu çalıştırdığımızda; Git değişiklikleri alır ve alt dizindeki dosyaları günceller ancak alt repoyu ``detached HEAD`` (bağlı olmayan bir HEAD) durumunda bırakır. Bu, yerel çalışma dalının (örneğin ``master`` gibi) değişiklikleri izlemediği anlamına gelir. Değişiklikleri izleyen bir çalışma dalı olmadığı için, alt modülde değişiklik yaparsanız bile, bu değişikliklerin bir sonraki git submodule update komutunu çalıştırdığınızda kaybolma olasılığı oldukça yüksektir. Bir alt modüldeki değişikliklerin izlenmesini istiyorsanız atmanız gereken ekstra adımlar bulunmaktadır.

Alt modülünüzü daha kolay bir şekilde düzenlemek için iki şey yapmanız gerekiyor. Her alt modüle gitmeli ve üzerinde çalışmak için bir dal açmalısınız. Sonra, eğer değişiklik yapmışsanız ve ardından git submodule update --remote ile yeni çalışmaları üst akımdan çekiyorsanız, Git’e ne yapması gerektiğini söylemelisiniz. Seçenekler, yeni değişiklikleri yerel işinize birleştirmek veya yerel işinizi yeni değişikliklerin üstüne tekrar temellemeyi denemektir.

İlk olarak, alt modül dizinine giderek bir dala geçelim.

Bunu ``merge`` seçeneğiyle deneyelim. Manuel olarak belirtmek için, update çağrımıza --merge seçeneğini ekleyebiliriz. İşte bu alt modül için sunucuda bir değişiklik olduğunu göreceğiz ve bu değişiklik birleştirilir.

DbConnector dizinine girdiğimizde, yeni değişikliklerin zaten yerel stable dalımıza birleştirildiğini göreceğiz. Şimdi kütüphanede kendi yerel değişikliğimizi yapalım ve aynı zamanda başka birinin üst akıma başka bir değişiklik gönderdiğinde ne olacağını görelim.

Şimdi alt modülümüzü güncellediğimizde, yerel bir değişiklik yaptığımız ve üst akımın da dahil edilmesi gereken bir değişikliğe sahip olduğumuzda ne olacağını görelim.

Eğer --rebase veya --merge seçeneklerini unutursanız, Git sadece alt modülü sunucuda bulunan herhangi bir duruma günceller ve projenizi bağlı bir HEAD durumuna (detached HEAD) sıfırlar.

Eğer böyle bir durumla karşılaşırsanız endişelenmeyin, sadece dizininize geri dönüp dalınıza tekrar geçebilirsiniz (ki bu hala çalışmanızı içerecektir) ve origin/stable (veya istediğiniz uzak dal) dalı manuel olarak birleştirebilir veya tekrar temelleyebilirsiniz.

Alt modüldeki değişikliklerinizi katkılamadıysanız ve bir alt modül güncellemesi çalıştırdığınızda sorunlara neden olabilecek değişiklikleri yapmadıysanız, Git değişiklikleri alır ancak alt modül dizininizde kaydedilmemiş çalışmanın üzerine yeniden yazmaz.

Eğer üst akımda yapılan bir değişiklikle çakışan değişiklikler yaptıysanız, güncelleme işlemini çalıştırdığınızda Git bunu size bildirecektir.

Alt modül dizinine gidip çakışmayı normal şekilde düzeltebilirsiniz.

Şimdi alt modül dizinimizde bazı değişikliklerimiz var. Bu değişikliklerden bazıları güncellemelerimizle üst akımdan getirildi, diğerleri ise yerel olarak yapıldı ama henüz itmediğimiz için başkaları tarafından erişilebilir durumda değil.

Ana projeyi katkılayıp ittiğimizde ve alt modül değişikliklerini itmediğimizde; bağımlı olunan alt modül değişikliklerini almanın bir yolu olmayacağı için değişikliklerimizi çekmek isteyenler sıkıntı yaşayacaklar. Bu değişiklikler yalnızca bizim yerel kopyamızda var olacaktır.

Bunu önlemek için, ana projeyi itmeden önce, tüm alt modüllerinizin düzgün bir şekilde itildiğinden emin olmak için Git’ten istekte bulunabilirsiniz. git push komutu ``check`` ya da ``on-demand`` olarak ayarlanabilecek olan --recurse-submodules argümanını alır. ``check`` seçeneği, katkılanmış alt modül değişikliklerinden herhangi biri henüz itilmediyse push komutunu geçersiz kılar.

Gördüğünüz gibi, bize ne yapmamız gerektiği konusunda bazı yardımcı önerilerde bulunulmaktadır. En basit seçenek, her alt modüle gidip manuel olarak uzak sunuculara itmek ve sonra ana itme işlemini tekrar denemektir. Eğer bu denetleme davranışının tüm itmeler için gerçekleşmesini istiyorsanız, bu davranışı varsayılan olarak yapmak için git config push.recurseSubmodules check komutunu kullanabilirsiniz.

Diğer seçenek, bunu sizin için bunu yapmaya çalışacak olan ``on-demand`` değerini kullanmaktır.

Görüldüğü gibi, Git DbConnector modülüne girdi ve ana projeyi itmeden önce bu alt modülü itti. Eğer bu itme bir nedenle başarısız olursa, ana proje itmesi de başarısız olacaktır. Bu davranışı varsayılan olarak ayarlamak için git config push.recurseSubmodules on-demand komutunu kullanabilirsiniz.

Eğer bir başkasıyla aynı anda bir alt modül referansını değiştirirseniz, bazı sorunlarla karşılaşabilirsiniz. Yani, alt modül geçmişleri ayrışmış ve üstproje içinde ayrık (divergent) dallara katkı işlenmişse, bunu düzeltmeniz gerekebilir.

Eğer katkılardan biri diğerinin doğrudan önceliyse (bir hızlı ileri birleştirme), Git sadece birleştirme için sonuncuyu seçecektir, bu yüzden bu sorunsuz çalışır.

Ancak Git sizin için basit birleştirmeyi bile denemez. Eğer alt modül katkıları ayrıksa ve birleştirilmeleri gerekiyorsa, şuna benzer bir uyarı alırsınız:

Temelde burada olan olay şudur: Git, alt modülün geçmişinde ayrık ve birleştirilmesi gereken noktaları kaydeden iki dal olduğunu anlamıştır. Bu, "merge following commits not found" olarak açıklanmıştır, bu kafa karıştırıcıdır ancak birazdan neden böyle olduğunu açıklayacağız.

Sorunu çözmek için, alt modülün hangi durumda olması gerektiğini belirlemeniz gerekmektedir. Garip bir şekilde, Git size burada yardımcı olacak pek fazla bilgi vermez, hatta tarihin her iki tarafında katkıların SHA-1’lerini bile vermez. Neyse ki, bunu bulmak oldukça basittir. git diff komutunu çalıştırırsanız, birleştirmeye çalıştığınız iki dalda kaydedilen katkıların SHA-1’lerini alabilirsiniz.

Bu durumda, eb41d76 alt modüldeki bizim katkımızı ve c771610'ı yukarı akımın katkısını temsil etmektedir. Alt modül dizinimize gittiğimizde, birleştirme ona dokunmadığı için, eb41d76 üzerinde olması gerekir. Herhangi bir nedenden dolayı değilse bile, ona işaret eden bir dal oluşturabilirsiniz.

Önemli olan, diğer taraftan gelen katkının SHA-1’idir. Çözmeniz ve birleştirmeniz gereken budur. Doğrudan SHA-1 ile birleştirmeyi deneyebilirsiniz, veya onun için bir dal oluşturabilir ve ardından bunu birleştirmeyi deneyebilirsiniz. En azından daha güzel bir birleştirme katkı mesajı oluşturmak için, biz ikincisini öneriyoruz.

Bu nedenle, alt modül dizinimize gireceğiz, git diff ile alınan ikinci SHA-1’e dayalı bir dal oluşturacağız ve manuel olarak birleştireceğiz.

Burada gerçek bir birleştirme çakışması yaşadık, bu yüzden bunu çözer ve katkılarsak, bu sonuçla ana projeyi güncelleyebiliriz.

Bu biraz kafa karıştırıcı olabilir, ancak gerçekten çok zor değil.

İlginç bir şekilde, Git’in ele aldığı başka bir durum daha var. Eğer alt modül dizininde hem geçmişteki her iki katkıyı da içeren birleştirme katkısı varsa, Git size bunu olası bir çözüm olarak önerir. Alt modül projesinde, bu iki katkıyı içeren dalların birleştirildiği bir nokta olduğunu görür, bu yüzden belki de bunu isteyebileceğinizi düşünür.

Bu yüzden önceki hata mesajının nedeni "merge following commits not found" idi, çünkü bunu yapamadı. Karışık görünmesinin sebebi kimsenin bunu denemesini beklememesidir.

Eğer Git tek bir kabul edilebilir birleştirme katkısı bulursa, şuna benzer bir şey göreceksiniz:

Verilen komut, izlemi git add komutunu çalıştırmış gibi günceller (çakışmayı temizler) ve ardından katkıyı işler. Aslında bunu yapmanız pek önerilmez. Bunun yerine, alt modül dizinine girip farkın ne olduğunu görebilir, bu katkıya hızlı bir ileri sarma yapabilir, uygun şekilde test edebilir ve ardından katkınızı işleyebilirsiniz.

Bu da aynı şeyi yapar, ama en azından bu şekilde düzgün çalışıp çalışmadığını doğrulayabilir ve işiniz bittiğinde kodun alt modül dizinizde olduğunu görebilirsiniz.

Her bir alt modülde belirli bir komut çalıştırmak için foreach alt modül komutu bulunmaktadır. Aynı projede birkaç alt modülünüz varsa, bu gerçekten yardımcı olabilir.

Örneğin, yeni bir özellik başlatmak veya bir hata düzeltmek istediğimizi ve birkaç alt modülde çalışmamız olduğunu varsayalım. Tüm alt modüllerimizdeki çalışmamızı kolayca saklayabiliriz.

Daha sonra tüm alt modüllerimizde yeni bir dal oluşturabilir ve ona geçebiliriz.

Fikri anladınız. Yapabileceğiniz en faydalı şey, ana projenizde neyin değiştiğini ve tüm yan projelerinizde neyin değiştiğini gösteren güzel bir birleşik diff oluşturmaktır.

Burada, bir alt modülde bir fonksiyon tanımlıyoruz ve ana projede onu çağırıyoruz. Bu açıkça basitleştirilmiş bir örnek, ancak umarım bunun nasıl faydalı olabileceğine dair bir fikir verir.

Bazıları oldukça uzun olan bu komutlar için bazı kısaltmalar oluşturmak isteyebilirsiniz ancak bunları varsayılan yapmak isterseniz, çoğu yapılandırma seçeneğini değiştiremezsiniz. Git’te kısaltmalar kurmayı Komut Kısayolu (Alias) Ayarlama bölümünde ele almıştık, ancak alt modüllerle sıkça çalışmayı planlıyorsanızx kurmak isteyebileceğiniz bir örnek aşağıda verilmiştir.

Bu şekilde alt modüllerinizi güncellemek istediğinizde sadece git supdate komutunu çalıştırabilir veya alt modül bağımlılığı kontrolü ile itmek için git spush komutunu kullanabilirsiniz.