Bu GitPro sayfası , git alt modül güncellemesinin sonuçlarını güzelce özetliyor
Çalıştırdığınızda git submodule update, projenin belirli bir sürümünü denetler, ancak bir şube içinde kontrol etmez. Buna bağımsız bir kafa olması denir - HEAD dosyası sembolik bir referansı değil, doğrudan bir taahhüdü işaret eder.
Mesele şu ki, genellikle bağımsız bir kafa ortamında çalışmak istemezsiniz, çünkü değişiklikleri kaybetmek kolaydır .
Bir başlangıç alt modül güncellemesi yaparsanız, çalışacak bir dal oluşturmadan bu alt modül dizininde işlem yapın ve sonra git alt modül güncellemesini bu arada taahhüt etmeden süper projeden tekrar çalıştırın, Git size bildirmeden değişikliklerinizin üzerine yazacaktır. Teknik olarak işi kaybetmeyeceksiniz, ancak ona işaret eden bir dalınız olmayacak, bu yüzden geri almak biraz zor olacak.
Not Mart 2013:
" Git submodule tracking latest " de belirtildiği gibi, şimdi bir alt modül (git1.8.2) bir dalı izleyebilir.
# add submodule to track master branch
git submodule add -b master [URL to Git repo];
# update your submodule
git submodule update --remote
# or (with rebase)
git submodule update --rebase --remote
Bkz. " git submodule update --remoteVsgit pull ".
MindTooth 'ın cevabı (yerel yapılandırma olmadan) manuel güncelleme göstermektedir:
git submodule -q foreach git pull -q origin master
Her iki durumda da, alt modül referanslarını ( gitlink , üst repo dizinindeki özel bir giriş) değiştirecek ve ana repodan bahsedilen referansları eklemeniz, taahhüt etmeniz ve aktarmanız gerekecektir.
Bir sonraki ana kopyayı kopyalayacağınız zaman, bu yeni SHA1 referanslarını yansıtacak şekilde alt modülleri dolduracaktır.
Bu cevabın geri kalanı klasik alt modül özelliğini detaylandırıyor (bir alt modül kavramının arkasındaki tüm nokta olan sabit bir işleme referans ).
Bu sorunu önlemek için, git checkout -b çalışma veya eşdeğeri bir alt modül dizininde çalışırken bir şube oluşturun. Alt modül güncellemesini ikinci kez yaptığınızda, yine de çalışmanızı geri döndürür, ancak en azından geri dönmek için bir işaretçiniz vardır.
İçlerinde alt modüller ile dalların değiştirilmesi de zor olabilir. Yeni bir dal oluşturursanız, oraya bir alt modül ekleyin ve ardından bu alt modül olmayan bir şubeye geri dönerseniz, yine de izlenmemiş dizin olarak alt modül dizininiz olur:
Yani, sorularınızı cevaplamak için:
dallar / modifikasyonlar oluşturabilir ve normal depolarda yaptığım gibi push / pull kullanabilir miyim, yoksa temkinli şeyler var mı?
Şube oluşturabilir ve değişiklikler yapabilirsiniz.
UYARI ( Git Alt Modül Öğreticisinden ): Değişikliği referans alan süper projeye yayınlamadan (itmeden) her zaman alt modül değişikliğini yayınlayın (itin). Alt modül değişikliğini yayınlamayı unutursanız, diğerleri depoyu klonlayamaz.
taahhüt edilen başvurulan alt modülün say (etiketli) 1.0'dan 1.1'e nasıl ilerlettiğini (orijinal repo başkanı zaten 2.0'da olsa bile)
" Alt Modülleri Anlama " sayfası yardımcı olabilir
Git alt modülleri iki hareketli parça kullanılarak uygulanır:
.gitmodulesdosya ve- özel bir ağaç nesnesi.
Bunlar birlikte, projenizdeki belirli bir yere teslim alınan belirli bir havuzun belirli bir revizyonunu üçgenler.
Gönderen git submodule sayfa
alt modülün içeriğini ana projeden değiştiremezsiniz
% 100 doğru: bir alt modülü değiştiremezsiniz, yalnızca taahhütlerinden birine bakın.
Bu nedenle, ana projenin içinden bir alt modülü değiştirdiğinizde:
- alt modül içinde (yukarı akım modülüne) taahhüt ve itme ihtiyacı ve
- daha sonra ana projenize gidin ve yeniden taahhüt verin (ana projenin yeni oluşturduğunuz ve ittiğiniz yeni alt modül taahhüdüne başvurması için)
Bir alt modül , ana projenin yalnızca diğer bileşenlerin belirli taahhütlerini (burada "alt modüller olarak bildirilen diğer Git depolarını" ifade ettiği) bileşen tabanlı bir yaklaşım geliştirmenize olanak tanır .
Bir alt modül, ana proje geliştirme döngüsüne bağlı olmayan başka bir Git deposuna bir işaretleyicidir (taahhüt): it ("diğer" Git repo) bağımsız olarak gelişebilir.
İhtiyacı ne olursa olsun diğer repodan seçmek ana projeye kalmıştır.
Bununla birlikte, kolaylık olması durumunda , bu alt modüllerden birini doğrudan ana projenizden değiştirmek isterseniz, önce bu alt modül değişikliklerini orijinal Git deposunda yayınlamanız ve ardından ana projenizi bir yeni adı geçen altmodülün sürümü.
Ancak ana fikir kalır: belirli bileşenlere atıfta bulunarak:
- kendi yaşam döngüsüne sahip olmak
- kendi etiketlerine sahip olmak
- kendi gelişimleri var
Ana projenizde bahsettiğiniz belirli taahhütlerin listesi yapılandırmanızı tanımlar ( yalnızca Sürüm Kontrol Sistemi'ni içeren Yapılandırma Yönetimi bununla ilgilidir )
Bir bileşen gerçekten ana projenizle aynı anda geliştirilebilseydi (çünkü ana projedeki herhangi bir değişiklik alt dizinin değiştirilmesini gerektirecektir ve tersi), o zaman artık bir "alt modül" olurdu, ama bir alt ağaç birleştirmesi (ayrıca eski kod tabanını cvs'den dağıtılmış depoya aktarma sorusunda da sunulmuştur ), iki Git deposunun geçmişini birbirine bağlar.
Bu, Git Alt Modüllerinin gerçek doğasını anlamaya yardımcı olur mu?