تحديث الجهاز الفرعي git

Question

لست واضحًا فيما يعنيه ما يلي (من تحديث الجهاز الفرعي git توثيق):

... سيجعل رأس العداوة الفرعية منفصلة ، ما لم يكن --rebase أو --merge محدد...

كيف --rebase/--merge تغيير الأشياء؟

حالة الاستخدام الرئيسية الخاصة بي هي أن يكون لديك مجموعة من المستودعات المركزية ، والتي سأدمجها عبر العارض الفرعي في مستودعات أخرى. أود أن أكون قادرًا على تحسين هذه المستودعات المركزية ، إما مباشرة في موقعها الأصلي ، أو من داخل مستودعات التضمين الخاصة بهم (تلك التي تستخدمها عبر الجهاز الفرعي).

• من داخل هذه العارض الفرعي ، هل يمكنني إنشاء فروع/تعديلات واستخدام الدفع/السحب تمامًا كما أود في المستودعات العادية ، أم أن هناك أشياء يجب أن تكون حذرة؟
• كيف يمكنني تعزيز الجهاز الفرعي الذي أشار إليه الالتزام من Say (الموسومة) 1.0 إلى 1.1 (على الرغم من أن رأس المستودع الأصلي هو بالفعل في 2.0) ، أو اختيار التزام الفرع المستخدم على الإطلاق؟

Answer 1

هذه صفحة gitpro هل يلخص نتيجة تحديث الجهاز الفرعي GIT بشكل جيد

عند الركض git submodule update, ، يتحقق من الإصدار المحدد من المشروع ، ولكن ليس داخل الفرع. وهذا ما يسمى وجود رأس منفصل - فهذا يعني أن ملف الرأس يشير مباشرة إلى الالتزام ، وليس إلى مرجع رمزي.
تكمن المشكلة في أنك لا ترغب عمومًا في العمل في بيئة رأس منفصلة ، لأنه من السهل فقدان التغييرات.
إذا قمت بإجراء تحديث أولي للوحدة الفرعية ، ارتكب في دليل الجهاز الفرعي هذا دون إنشاء فرع للعمل فيه ، ثم قم بتشغيل تحديث الجهاز الفرعي GIT مرة أخرى من المشروع الفائق دون الالتزام في هذه الأثناء ، ستقوم GIT بتكوين تغييراتك دون إخبارك. من الناحية الفنية ، لن تفقد العمل ، لكن لن يكون لديك فرع يشير إليه ، لذلك سيكون من الصعب إلى حد ما استرداده.

---

ملاحظة مارس 2013:

كما ذكر في ""تتبع الجهاز الفرعي git الأحدث"، يمكن الآن توسيع نطاق فرعي (Git1.8.2) تتبع فرعًا.

# 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

نرى "git submodule update --remote ضد git pull".

Mindtooth'س إجابه توضيح تحديث يدوي (بدون تكوين محلي):

git submodule -q foreach git pull -q origin master

في كلتا الحالتين ، سيغير ذلك المراجع الفرعية ( gitlink, ، أ إدخال خاص في فهرس الريبو الأصل) ، وستحتاج إلى إضافة وارتكاب ودفع المراجع المذكورة من الريبو الرئيسي.
في المرة القادمة التي ستستنسخ فيها ريبو الوالدين ، ستقوم بملء العروض الفرعية لتعكس مراجع SHA1 الجديدة.

تفاصيل بقية هذه الإجابة ميزة الجهاز الفرعي الكلاسيكي (إشارة إلى أ مُثَبَّت الالتزام ، والتي هي كل النقطة وراء فكرة الجهاز الفرعي).

---

لتجنب هذه المشكلة ، قم بإنشاء فرع عند العمل في دليل وحدة فرعية مع عمل GIT Checkout -B أو أي شيء مكافئ. عندما تقوم بتحديث المواد الفرعية للمرة الثانية ، فإنه سيظل يعود عملك ، ولكن على الأقل لديك مؤشر للعودة إليه.

يمكن أن يكون تبديل الفروع مع العارض الفرعي فيها أمرًا صعبًا. إذا قمت بإنشاء فرع جديد ، وأضف عرضًا فرعيًا هناك ، ثم عد إلى فرع بدون هذا الجهاز الفرعي ، لا يزال لديك دليل الجهاز الفرعي كدليل غير مرغوب فيه:

---

لذا ، للإجابة على أسئلتك:

هل يمكنني إنشاء فروع/تعديلات واستخدام الدفع/السحب تمامًا كما أود في إعادة الشراء العادية ، أم أن هناك أشياء يجب أن تكون حذرة بشأنها؟

يمكنك إنشاء فرع ودفع التعديلات.

تحذير (من GIT Submodule البرنامج التعليمي): قم دائمًا بنشر (دفع) تغيير الجهاز الفرعي قبل نشر (دفع) التغيير إلى المشروع الفائق الذي يشير إليه. إذا نسيت نشر تغيير الجهاز الفرعي ، فلن يتمكن الآخرون من استنساخ المستودع.

كيف يمكنني تعزيز الجهاز الفرعي الذي أشار إليه الالتزام من Say (الموسومة) 1.0 إلى 1.1 (على الرغم من أن رأس الريبو الأصلي هو بالفعل في 2.0)

الصفحة "فهم النسيحات الفرعية" استطيع المساعدة

يتم تنفيذ العارض الفرعي GIT باستخدام جزأين متحركين:

• ال .gitmodules ملف و
• نوع خاص من كائن الأشجار.

هذه معا تتثليع مراجعة محددة لمستودع معين يتم فحصه في موقع معين في مشروعك.

---

من صفحة الجهاز الفرعي git

لا يمكنك تعديل محتويات الجهاز الفرعي من داخل المشروع الرئيسي

100 ٪ صحيح: لا يمكنك تعديل وحدة فرعية ، يرجى الرجوع فقط إلى واحدة من ارتكابها.

هذا هو السبب ، عندما تقوم بتعديل وحدة فرعية من داخل المشروع الرئيسي ، أنت:

• تحتاج إلى الالتزام والدفع داخل الجهاز الفرعي (إلى الوحدة النمطية المنبع) ، و
• ثم اصعد في مشروعك الرئيسي ، وأعد إلزامًا (من أجل أن يشير هذا المشروع الرئيسي إلى الجهاز الفرعي الجديد الذي قمت بإنشائه ودفعته للتو)

تمكنك وحدة فرعية من الحصول على ملف النهج القائم على المكون التطوير ، حيث يشير المشروع الرئيسي فقط إلى ارتباطات محددة للمكونات الأخرى (هنا "مستودعات GIT الأخرى التي تم إعلانها كوحدات فرعية").

الجهاز الفرعي هو علامة (تلتزم) بمستودع GIT آخر لا يرتبط بدورة تطوير المشروع الرئيسية: يمكن أن يتطور ("repo git الآخر") بشكل مستقل.
الأمر متروك للمشروع الرئيسي للاختيار من بين هذا الريبو الآخر مهما كان الالتزام الذي يحتاجه.

ومع ذلك ، إذا كنت تريد ، من الراحة, ، قم بتعديل واحدة من هذه العوامل الفرعية مباشرة من مشروعك الرئيسي ، تسمح لك GIT بالقيام بذلك ، بشرط عليك أول نشر تلك التعديلات الفرعية على ريبو GIT الأصلي ، و ومن بعد ارتكب مشروعك الرئيسي يشير إلى أ الجديد نسخة من الجهاز الفرعي المذكور.

لكن الفكرة الرئيسية تبقى: الرجوع إلى مكونات محددة:

• لديهم دورة حياتهم الخاصة
• لديهم مجموعة من العلامات الخاصة بهم
• لديهم تطورهم الخاص

تحدد قائمة الالتزامات المحددة التي تشير إليها في مشروعك الرئيسي الخاص بك ترتيب (هذا هو ما ترتيب الإدارة تدور حولها ، إنجلوبينج مجرد نظام التحكم في الإصدار)

إذا كان من الممكن تطوير مكون حقًا في نفس الوقت نظرًا لأن مشروعك الرئيسي (لأن أي تعديل على المشروع الرئيسي سيتضمن تعديل الدليل الفرعي ، والعكس بالعكس) ، فإنه سيكون "عرضًا فرعيًا" لا أكثر ، ولكن دمج شجرة فرعية (معروضة أيضًا في السؤال نقل قاعدة التعليمات البرمجية القديمة من CVS إلى مستودع موزع) ، وربط تاريخ اثنين من الريبو git معا.

هل يساعد ذلك في فهم الطبيعة الحقيقية للفيروسات الفرعية للجيت؟

Answer 2

لتحديث كل وحدة فرعية ، يمكنك استدعاء الأمر التالي (بجذر المستودع):

git submodule -q foreach git pull -q origin master

يمكنك إزالة -q خيار لمتابعة العملية برمتها.

Answer 3

لمعالجة --rebase ضد. --merge اختيار:

دعنا نقول أن لديك مستودعًا فائقًا ووحدة فرعية B وترغب في القيام ببعض الأعمال في الجهاز الفرعي B.

git submodule update

أنت في حالة أقل من رأس ، لذلك يصعب العودة إلى أي ارتكاب في هذه المرحلة. لذلك ، لقد بدأت العمل على فرع جديد في الجهاز الفرعي B.

cd B
git checkout -b bestIdeaForBEver
<do work>

وفي الوقت نفسه ، قرر شخص آخر في Project A أن أحدث وأكبر إصدار من B هو حقًا ما يستحقه. أنت ، من العادة ، تقوم بدمج أحدث التغييرات في أسفل وتحديث العلامات الفرعية الخاصة بك.

<in A>
git merge develop
git submodule update

يا نوز! لقد عدت إلى حالة مقطوعة الرأس مرة أخرى ، ربما لأن B تشير الآن إلى SHA المرتبطة بنصيحة B الجديدة ، أو بعض الالتزام الآخر. إذا كان لديك فقط:

git merge develop
git submodule update --rebase

Fast-forwarded bestIdeaForBEver to b798edfdsf1191f8b140ea325685c4da19a9d437.
Submodule path 'B': rebased into 'b798ecsdf71191f8b140ea325685c4da19a9d437'

الآن ، تم إعادة تنفيذ أفضل فكرة على الإطلاق لـ B على الالتزام الجديد ، والأهم من ذلك أنك لا تزال في فرع التنمية الخاص بك لـ B ، وليس في حالة مقطوعة الرأس!

(ال --merge سوف يندمج التغييرات من قبل efferupdatesha إلى بعد updatesha في فرع العمل الخاص بك ، بدلاً من إعادة تغيير التغييرات الخاصة بك على بعد updatesha.)

Answer 4

يتميز Git 1.8.2 بخيار جديد ،--remote, سيمكن هذا بالضبط هذا السلوك. ادارة

git submodule update --rebase --remote

سوف تجلب آخر التغييرات من المنبع في كل وحدة فرعية ، وإعادة صياغة لها ، وتحقق من أحدث مراجعة للوحدة الفرعية. كما وثائق ضعها:

--التحكم عن بعد

هذا الخيار صالح فقط لأمر التحديث. بدلاً من استخدام SuperProject المسجل SHA-1 لتحديث الجهاز الفرعي ، استخدم حالة فرع التتبع عن بُعد للوحدة الفرعية.

هذا يعادل الجري git pull في كل وحدة فرعية ، وهو ما تريده بشكل عام.

(تم نسخ هذا من هذا الجواب.)