git-pull - عبر الإنترنت في السحابة

برنامج:

اسم

git-pull - جلب من مستودع آخر أو فرع محلي والتكامل معه

موجز

طائرة نفاثة سحب [خيارات] [ [ ...]]

الوصف

يدمج التغييرات من مستودع بعيد إلى الفرع الحالي. في الافتراضي الخاص به
الوضع ، git pull هو اختصار لـ git fetch متبوعًا بـ git merge FETCH_HEAD.

أكثر دقة، طائرة نفاثة سحب يدير طائرة نفاثة جلب مع المعلمات والمكالمات المحددة طائرة نفاثة دمج إلى
دمج رؤوس الفروع المستردة في الفرع الحالي. مع - rebase ، يتم تشغيله طائرة نفاثة
rebase بدلا من طائرة نفاثة دمج.

يجب أن يكون اسم المستودع البعيد كما تم تمريره إلى بوابة الجلب(1).
يمكن تسمية المرجع البعيد التعسفي (على سبيل المثال ، اسم العلامة) أو حتى
مجموعة المراجع مع فروع التتبع عن بعد المقابلة (على سبيل المثال ،
refs / heads / *: refs / remote / origin / *) ، ولكن عادةً ما يكون هذا هو اسم فرع في جهاز التحكم عن بُعد
مستودع.

القيم الافتراضية لـ و تتم قراءتها من "عن بعد" و "دمج"
التكوين للفرع الحالي كما تم تعيينه بواسطة فرع بوابة(1) - المسار.

افترض أن السجل التالي موجود وأن الفرع الحالي هو "رئيسي":

أ - ب - ج سيد في الأصل
/
D - E - F - G سيد
^
الأصل / الماجستير في المستودع الخاص بك

ثم يقوم "git pull" بجلب التغييرات وإعادة تشغيلها من الفرع الرئيسي البعيد منذ ذلك الحين
تباعدت عن السيد المحلي (أي ، E) حتى الالتزام الحالي (C) أعلى الرئيسي و
سجل النتيجة في التزام جديد مع اسمي التعهدات الرئيسية والسجل
رسالة من المستخدم تصف التغييرات.

أ - ب - ج أصل / سيد
/ \
D - E - F - G - H سيد

يرى بوابة دمج(1) للحصول على التفاصيل ، بما في ذلك كيفية عرض النزاعات ومعالجتها.

في Git 1.7.0 أو أحدث ، لإلغاء الدمج المتعارض ، استخدم git reset --merge. تحذير: في
الإصدارات الأقدم من Git ، قيد التشغيل طائرة نفاثة سحب مع التغييرات غير الملتزم بها غير محبذ: while
ممكن ، فإنه يتركك في حالة قد يكون من الصعب التراجع عنها في حالة وجود ملف
نزاع.

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

OPTIONS

-Q ، - هادئ
يتم تمرير هذا إلى كل من git-fetch الأساسي لإخماد الإبلاغ أثناء النقل ،
و git-merge الأساسي لإسكات الإخراج أثناء الدمج.

-v ، - الإسراف
قم بتمرير - overbose إلى git-fetch و git-merge.

- [no-] recurse-subodules [= نعم | عند الطلب | لا]
يتحكم هذا الخيار في ما إذا كان يجب جلب الالتزامات الجديدة لجميع الوحدات الفرعية المأهولة أيضًا
(انظر بوابة التكوين(1) و وحدات gitmodules(5)). قد يكون ذلك ضروريًا للحصول على البيانات المطلوبة
لدمج التزامات الوحدة الفرعية ، وهي ميزة تعلمها Git في 1.7.3. لاحظ أن النتيجة
من الدمج لن يتم سحبها في الوحدة الفرعية ، "git subodule update" يجب أن يكون
تم استدعاؤه بعد ذلك لتحديث شجرة العمل مع نتيجة الدمج.

مزيد من الخيارات ذات صلة إلى دمج
- الالتزام ، - عدم الالتزام
تنفيذ الدمج وتنفيذ النتيجة. يمكن استخدام هذا الخيار للتجاوز
- لا تلتزم.

باستخدام - no-الالتزام ، قم بإجراء الدمج ولكن تظاهر بأن الدمج فشل ولا يلتزم تلقائيًا ،
لمنح المستخدم فرصة لفحص نتيجة الدمج وتعديلها من قبل
يلتزم.

- تحرير ، -ه ، -لا تحرير
قم باستدعاء محرر قبل تنفيذ الدمج الميكانيكي الناجح لمزيد من التحرير لملف
رسالة دمج تم إنشاؤها تلقائيًا ، بحيث يمكن للمستخدم شرح وتبرير الدمج. ال
- لا يمكن استخدام خيار التحرير لقبول الرسالة التي يتم إنشاؤها تلقائيًا (هذا بشكل عام
محبط).

قد تعتمد النصوص البرمجية القديمة على السلوك التاريخي المتمثل في عدم السماح للمستخدم بالتحرير
رسالة سجل الدمج. سيرون محررًا مفتوحًا عند تشغيل git merge. ليصنع
من الأسهل ضبط مثل هذه البرامج النصية على السلوك المحدث ، متغير البيئة
يمكن تعيين GIT_MERGE_AUTOEDIT على "لا" في بدايتها.

- fff
عندما يتم حل الدمج كتقديم سريع ، فقط قم بتحديث مؤشر الفرع ، بدون
إنشاء التزام دمج. هذا هو السلوك الافتراضي.

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

- فقط
رفض الدمج والخروج بحالة غير صفرية ما لم يكن الرأس الحالي موجودًا بالفعل
محدث أو يمكن حل الدمج باعتباره التقديم السريع.

- مدونة [= ] ، - لا سجل
بالإضافة إلى أسماء الفروع ، قم بتعبئة رسالة السجل بأوصاف من سطر واحد من
في الغالب الالتزامات الفعلية التي يتم دمجها. أنظر أيضا بوابة-fmt- دمج-msg(1).

باستخدام - no-log ، لا تسرد أوصاف سطر واحد من الالتزامات الفعلية التي يتم دمجها.

--stat، -n، --لا إحصائيات
إظهار diffstat في نهاية الدمج. يتم التحكم أيضًا في diffstat بواسطة
خيار التكوين merge.stat.

مع -n أو - no-stat لا تُظهر diffstat في نهاية الدمج.

- سكواش ، - لا سكواش
قم بإنشاء شجرة العمل وحالة الفهرس كما لو حدث دمج حقيقي (باستثناء ملف
دمج المعلومات) ، ولكن لا تقم فعليًا بإجراء التزام أو تحريك الرأس أو التسجيل
GIT_DIR / MERGE_HEAD $ (لإحداث أمر git الالتزام التالي لإنشاء التزام دمج).
يتيح لك هذا إنشاء التزام واحد أعلى الفرع الحالي الذي يكون تأثيره
مثل دمج فرع آخر (أو أكثر في حالة الأخطبوط).

باستخدام - no-squash ، نفذ الدمج وقم بتنفيذ النتيجة. يمكن استخدام هذا الخيار ل
تجاوز - سكواش.

-س ، - الإستراتيجية =
استخدم استراتيجية الدمج المحددة ؛ يمكن توفيرها أكثر من مرة لتحديدها في ملف
تأمر بضرورة محاكمتهم. إذا لم يكن هناك خيار -s ، فستكون قائمة الاستراتيجيات المضمنة
تستخدم بدلا من ذلك (طائرة نفاثة دمج العودية عند دمج رأس واحد ، طائرة نفاثة دمج الأخطبوط
غير ذلك).

-X ، - خيار الإستراتيجية =
قم بتمرير خيار محدد لاستراتيجية الدمج إلى استراتيجية الدمج.

- التحقق من التوقيعات ، - عدم التحقق من التوقيعات
تحقق من أن الالتزامات التي يتم دمجها تحتوي على توقيعات GPG جيدة وموثوق بها وإجهاضها
الدمج في حال لم يفعلوا ذلك.

- ملخص ، - بدون ملخص
مرادفات لـ --stat و - no-stat ؛ هذه مهملة وستتم إزالتها في
مستقبل.

-r، --rebase [= خطأ | صحيح | حفظ]
عندما يكون هذا صحيحًا ، قم بإعادة تأسيس الفرع الحالي أعلى فرع المنبع بعد الجلب. لو
يوجد فرع تتبع عن بعد يتوافق مع فرع المنبع و
تم إعادة تأسيس فرع المنبع منذ آخر مرة تم جلبه ، ويستخدم rebase تلك المعلومات لـ
تجنب إعادة تأسيس التغييرات غير المحلية.

عند التعيين للمحافظة ، قم بإعادة الأسس باستخدام الخيار --preserve-merges الذي تم تمريره إلى git rebase
أن عمليات الدمج التي تم إنشاؤها محليًا لن يتم تسويتها.

عندما تكون خاطئة ، ادمج الفرع الحالي في فرع المنبع.

انظر pull.rebase ، الفرع. .rebase و Branch.autoSetupRebase بتنسيق بوابة التكوين(1) إذا
تريد أن تجعل git pull تستخدم دائمًا - rebase بدلاً من الدمج.

ملاحظات
هذا هو احتمال خطير طريقة التشغيل. إنه يعيد كتابة التاريخ ، وهو ما يفعله
لا يبشر بالخير عندما نشرت هذا التاريخ بالفعل. يفعل ليست استخدم هذا الخيار
إلا إذا كنت قد قرأت git-rebase(1) بعناية.

--لا إعادة قاعدة
تجاوز في وقت سابق - rebase.

مزيد من الخيارات ذات صلة إلى جلب
--الكل
إحضار كافة أجهزة التحكم عن بعد.

-a ، - إرفاق
قم بإلحاق أسماء المراجع وأسماء الكائنات للمراجع التي تم جلبها بالمحتويات الحالية لـ
.git / FETCH_HEAD. بدون هذا الخيار ، ستتم الكتابة فوق البيانات القديمة في .git / FETCH_HEAD.

- العمق =
حد الجلب إلى العدد المحدد من عمليات التنفيذ من طرف كل فرع بعيد
تاريخ. إذا كان الجلب إلى ملف ضحل تم إنشاؤه بواسطة git clone مع --depth =
الخيار (انظر استنساخ بوابة(1)) ، تعميق أو تقصير التاريخ إلى العدد المحدد من
يرتكب. لا يتم جلب العلامات الخاصة بعمليات الارتباطات المعمقة.

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

إذا كان مستودع المصدر ضحلًا ، فقم بإحضار أكبر قدر ممكن بحيث يكون التيار
المستودع له نفس تاريخ مستودع المصدر.

- تحديث ضحلة
بشكل افتراضي عند الجلب من مستودع ضحل ، يرفض git fetch ذلك
تتطلب تحديث .git / الضحلة. يقوم هذا الخيار بتحديث .git / الضحلة وقبول مثل هذه المراجع.

-f ، - القوة
متى طائرة نفاثة جلب يستخدم مع : refspec ، فإنه يرفض تحديث
الفرع المحلي ما لم يكن الفرع البعيد يجلب هو سليل
ل . يتجاوز هذا الخيار هذا الاختيار.

-ك ، - حفظ
احتفظ بالحزمة التي تم تنزيلها.

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

-u، -تحديث-رئيس-موافق
افتراضيا طائرة نفاثة جلب يرفض تحديث الرأس الذي يتوافق مع التيار
فرع. هذه العلامة تعطل الشيك. هذا محض للاستخدام الداخلي لـ طائرة نفاثة سحب
للتواصل مع طائرة نفاثة جلبوما لم تكن تقوم بتنفيذ البورسلين بنفسك
ليس من المفترض أن تستخدمه.

- حزمة التحميل
عند تقديمه ، يتم التعامل مع المستودع الذي سيتم الجلب منه طائرة نفاثة أحضر حزمة,
- exec = إلى الأمر لتحديد مسار غير افتراضي لملف
تشغيل الأمر على الطرف الآخر.

--تقدم
يتم الإبلاغ عن حالة التقدم في تدفق الخطأ القياسي افتراضيًا عندما يكون كذلك
متصل بمحطة ، ما لم يتم تحديد q-. هذا العلم يفرض حالة التقدم حتى
إذا لم يتم توجيه تدفق الخطأ القياسي إلى محطة طرفية.


المستودع "البعيد" الذي يعد مصدر عملية الجلب أو السحب. هذا
يمكن أن تكون المعلمة إما عنوان URL (راجع قسم GIT URLS أدناه) أو اسم جهاز تحكم عن بعد
(انظر القسم عن بعد أدناه).


يحدِّد المراجع المطلوب جلبها والمراجع المحلية المراد تحديثها. عندما لا س
تظهر في سطر الأوامر ، تتم قراءة المراجع المطلوب إحضارها من جهاز التحكم عن بُعد. .أحضر
المتغيرات بدلا من ذلك (انظر بوابة الجلب(1)).

شكل ملف المعلمة اختيارية plus + ، متبوعة بالمرجع المصدر
، متبوعة بنقطتين: ، متبوعة بالوجهة المرجع . يمكن أن يكون القولون
حذفت عندما فارغ.

بطاقة شعار تعني نفس المراجع / العلامات / : المراجع / العلامات / ؛ يطلب الجلب
كل شيء حتى العلامة المحددة.

المرجع البعيد المطابق يتم جلبه ، وإذا ليست سلسلة فارغة ، فإن
المرجع المحلي الذي يطابق ذلك يتم إرساله سريعًا باستخدام . إذا كانت علامة الجمع الاختيارية هي
مستخدمًا ، يتم تحديث المرجع المحلي حتى لو لم ينتج عنه تحديث سريع التقديم.

ملاحظات
عندما يكون من المعروف أن الفرع البعيد الذي تريد جلبه سيتم إعادة لفه وإعادة تأسيسه
بانتظام ، من المتوقع ألا يكون طرفه الجديد منحدراً من سابقه
نصيحة (كما تم تخزينها في فرع التتبع عن بُعد في آخر مرة جلبت فيها). أنت
قد ترغب في استخدام علامة + للإشارة إلى أنه ستكون هناك حاجة إلى تحديثات غير سريعة التقديم
لمثل هذه الفروع. لا توجد طريقة لتحديد أو إعلان أن الفرع سيكون
يتم توفيرها في المستودع بهذا السلوك ؛ يجب على المستخدم الذي يقوم بالسحب ببساطة
تعرف أن هذا هو نمط الاستخدام المتوقع للفرع.

ملاحظات
هناك فرق بين قائمة متعددة مباشرة على طائرة نفاثة سحب
سطر الأوامر وبعد عدة أجهزة التحكم عن بعد. .إحضار الإدخالات في ملف
التكوين ل وتشغيل طائرة نفاثة سحب قيادة بدون أي
صريح حدود. s المدرجة بشكل صريح في سطر الأوامر
يتم دمجها دائمًا في الفرع الحالي بعد الجلب. بمعنى آخر ، إذا كنت
سرد أكثر من مرجع بعيد واحد ، طائرة نفاثة سحب سينشئ دمج الأخطبوط. من جهة أخرى
اليد ، إذا لم تدرج أي صريح المعلمة في سطر الأوامر ، طائرة نفاثة
سحب سيجلب كل ق يجدها في جهاز التحكم عن بعد. .أحضر
التكوين ودمج فقط الأول وجدت في الفرع الحالي.
هذا لأن صنع الأخطبوط من المراجع البعيدة نادرًا ما يتم القيام به مع الاحتفاظ به
تتبع عدة رؤوس بعيدة دفعة واحدة عن طريق جلب أكثر من واحد في كثير من الأحيان
مفيد.

GIT عناوين URL

بشكل عام ، تحتوي عناوين URL على معلومات حول بروتوكول النقل وعنوان ملف
الخادم البعيد ، والمسار إلى المستودع. اعتمادًا على بروتوكول النقل ، البعض
من هذه المعلومات قد تكون غائبة.

يدعم Git بروتوكولات ssh و git و http و https (بالإضافة إلى ذلك ، يمكن استخدام ftp و ftps
للجلب و rsync يمكن استخدامها للجلب والدفع ، ولكن هذه غير فعالة و
إهمال؛ لا تستخدمها).

لا يقوم النقل الأصلي (على سبيل المثال git: // URL) بالمصادقة ويجب استخدامه مع
الحذر على الشبكات غير الآمنة.

يمكن استخدام الصيغ التالية معهم:

· ssh: // [user @] host.xz [: port] /path/to/repo.git/

· git: //host.xz [: port] /path/to/repo.git/

· http [s]: //host.xz [: port] /path/to/repo.git/

· ftp [s]: //host.xz [: port] /path/to/repo.git/

· rsync: //host.xz/path/to/repo.git/

يمكن أيضًا استخدام صيغة بديلة تشبه scp مع بروتوكول ssh:

· [user @] host.xz: path / to / repo.git /

يتم التعرف على بناء الجملة هذا فقط في حالة عدم وجود شرطات مائلة قبل علامة النقطتين الأولى. هذا يساعد
تمييز مسار محلي يحتوي على نقطتين. على سبيل المثال المسار المحلي foo: bar يمكن أن يكون
يتم تحديده كمسار مطلق أو ./foo:bar لتجنب إساءة تفسيره على أنه عنوان url ssh.

يدعم بروتوكولات ssh و git أيضًا توسيع اسم المستخدم:

· ssh: // [user @] host.xz [: port] / ~ [مستخدم] /path/to/repo.git/

· git: //host.xz [: port] / ~ [مستخدم] /path/to/repo.git/

· [مستخدم @] host.xz: / ~ [مستخدم] /path/to/repo.git/

بالنسبة للمستودعات المحلية ، المدعومة أيضًا بواسطة Git محليًا ، قد تكون الصيغ التالية
مستعمل:

· /المسار/إلى/repo.git/

· ملف: ///path/to/repo.git/

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

عندما لا يعرف Git كيفية التعامل مع بروتوكول نقل معين ، فإنه يحاول استخدام الامتداد
التحكم عن بعد- المساعد البعيد ، إن وجد. لطلب مساعد بعيد صراحة ،
يمكن استخدام الصيغة التالية:

· ::

أين قد يكون مسارًا أو خادمًا ومسارًا أو سلسلة عشوائية تشبه عنوان URL
يتعرف عليه المساعد البعيد المحدد الذي يتم استدعاؤه. يرى مساعدين gitremote(1) من أجل
تفاصيل.

إذا كان هناك عدد كبير من المستودعات البعيدة ذات الأسماء المتشابهة وتريد استخدام ملف
تنسيق مختلف لهم (مثل أن عناوين URL التي تستخدمها ستتم إعادة كتابتها في عناوين URL التي
work) ، يمكنك إنشاء قسم تكوين من النموذج:

[عنوان url " "]
بدلا من =

على سبيل المثال ، مع هذا:

[url "git: //git.host.xz/"]
بدلاً من ذلك = host.xz: / path / to /
بدلا من = العمل:

عنوان URL مثل "work: repo.git" أو مثل "host.xz: /path/to/repo.git" ستتم إعادة كتابته في أي
السياق الذي يأخذ عنوان URL ليكون "git: //git.host.xz/repo.git".

إذا كنت ترغب في إعادة كتابة عناوين URL للدفع فقط ، فيمكنك إنشاء قسم تكوين لملف
شكل:

[عنوان url " "]
pushInsteadOf =

على سبيل المثال ، مع هذا:

[url "ssh: //example.org/"]
pushInsteadOf = git: //example.org/

ستتم إعادة كتابة عنوان URL مثل "git: //example.org/path/to/repo.git" إلى
"ssh: //example.org/path/to/repo.git" لعمليات الدفع ، ولكن ستظل عمليات السحب تستخدم الأصل
URL.

أجهزة التحكم عن بعد

يمكن استخدام اسم أي مما يلي بدلاً من عنوان URL كـ دعوى:

جهاز تحكم عن بعد في ملف تكوين Git: $ GIT_DIR / config ،

ملف في الدليل $ GIT_DIR / ريموتات ، أو

ملف في الدليل $ GIT_DIR / الفروع.

كل هذه تسمح لك أيضًا بحذف refspec من سطر الأوامر لأن كل منها
تحتوي على refspec التي سيستخدمها git افتراضيًا.

عين عن بعد in ترتيب ملف
يمكنك اختيار تقديم اسم جهاز التحكم عن بُعد الذي قمت بتكوينه مسبقًا باستخدامه
بوابة التحكم عن بعد(1) بوابة التكوين(1) أو حتى عن طريق تعديل يدوي لملف $ GIT_DIR / config. عنوان URL
سيتم استخدام جهاز التحكم عن بُعد هذا للوصول إلى المستودع. سيكون refspec لجهاز التحكم عن بعد هذا
يتم استخدامه بشكل افتراضي عندما لا تقدم مرجعًا في سطر الأوامر. الإدخال في
سيظهر ملف التكوين بالشكل التالي:

[بعيد " "]
url =
pushurl =
دفع =
إحضار =

ال يستخدم للدفع فقط. إنه اختياري ويتم تعيينه افتراضيًا .

عين ملف in GIT_DIR دولار / عن بعد
يمكنك اختيار تقديم اسم الملف في $ GIT_DIR / remote. عنوان URL في هذا الملف
سيتم استخدامها للوصول إلى المستودع. سيتم استخدام المرجع في هذا الملف كافتراضي
عندما لا تقدم مرجعًا في سطر الأوامر. يجب أن يحتوي هذا الملف على ما يلي
شكل:

URL: أحد تنسيقات URL أعلاه
يدفع:
يحذب:

الدفع: يتم استخدام الخطوط بواسطة طائرة نفاثة دفع والسحب: يتم استخدام الخطوط بواسطة طائرة نفاثة سحب و طائرة نفاثة جلب.
الدفع المتعدد: والسحب: يمكن تحديد الخطوط لتعيينات الفروع الإضافية.

عين ملف in GIT_DIR دولار / الفروع
يمكنك اختيار تقديم اسم الملف في $ GIT_DIR / الفروع. عنوان URL في هذا الملف
سيتم استخدامها للوصول إلى المستودع. يجب أن يكون هذا الملف بالتنسيق التالي:

#

مطلوب؛ # هو اختياري.

اعتمادًا على العملية ، سيستخدم git أحد برامج refspecs التالية ، إذا لم تقم بذلك
توفير واحد في سطر الأوامر. اسم هذا الملف في $ GIT_DIR / الفروع
و الافتراضات لإتقان.

استخدامات git fetch:

المراجع / رؤساء / : المراجع / الرؤوس /

يستخدم git push:

الرأس: المراجع / الرؤوس /

دمج الاستراتيجيات

آلية الدمج (أوامر git merge و git pull) تسمح للواجهة الخلفية دمج استراتيجيات
ليتم اختياره بخيار -s. يمكن لبعض الاستراتيجيات أيضًا أن تتخذ خياراتها الخاصة ، والتي يمكن أن تكون كذلك
مرت بإعطاء -X الحجج لـ git merge و / أو git pull.

حل
يمكن أن يؤدي هذا إلى حل رأسين فقط (أي الفرع الحالي وفرع آخر قمت بسحبه
من) باستخدام خوارزمية دمج ثلاثية. يحاول الكشف بعناية عن الدمج المتقاطع
الغموض وتعتبر بشكل عام آمنة وسريعة.

العودية
هذا يمكن فقط حل رأسين باستخدام خوارزمية دمج ثلاثية. عندما يكون هناك أكثر من
سلف واحد مشترك يمكن استخدامه للدمج ثلاثي الاتجاهات ، فإنه ينشئ شجرة مدمجة من
أسلاف مشتركة ويستخدم ذلك كشجرة مرجعية للدمج ثلاثي الاتجاهات. هذا لديه
تم الإبلاغ عن أنها تؤدي إلى عدد أقل من تعارضات الدمج دون التسبب في أخطاء في الاختبارات
تم إجراؤه بناءً على التزامات الدمج الفعلية المأخوذة من سجل تطوير نواة Linux 2.6.
بالإضافة إلى ذلك ، يمكن أن يكتشف هذا ويعالج عمليات الدمج التي تتضمن عمليات إعادة تسمية. هذا هو الافتراضي
دمج الإستراتيجية عند سحب أو دمج فرع واحد.

ال العودية يمكن أن تتخذ الاستراتيجية الخيارات التالية:

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

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

لهم
هذا هو عكس لنا.

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

خوارزمية فرق = [الصبر | الحد الأدنى | المدرج التكراري | مايرز]
يقول دمج العودية لاستخدام خوارزمية فرق مختلفة ، والتي يمكن أن تساعد في تجنبها
الاختلالات التي تحدث بسبب خطوط مطابقة غير مهمة (مثل الأقواس من
وظائف متميزة). أنظر أيضا بوابة فرق(1) - خوارزمية مختلفة.

ignore-space-change، ignore-all-space، ignore-space-at-eol
يعامل الأسطر ذات النوع المشار إليه لتغيير المسافات البيضاء على أنها لم تتغير بالنسبة لـ
من أجل دمج ثلاثي. تتغير المسافات المختلطة مع التغييرات الأخرى على السطر
لا يتم تجاهلها. أنظر أيضا بوابة فرق(1) -b و -w و -ignore-space-at-eol.

· لو من مشاركة يقدم الإصدار فقط تغييرات المسافات البيضاء إلى سطر ، صفحة الإصدار هو
مستخدم؛

· لو صفحة يقدم الإصدار تغييرات المسافات البيضاء ولكن من مشاركة يتضمن الإصدار أ
تغيير جوهري ، من مشاركة الإصدار يستخدم

· خلاف ذلك ، يتم الدمج بالطريقة المعتادة.

أعد التطبيع
يؤدي هذا إلى تشغيل عملية سحب وإيداع ظاهرية لجميع المراحل الثلاث لملف عندما
حل دمج ثلاثي. من المفترض استخدام هذا الخيار عند دمج الفروع
باستخدام فلاتر نظيفة مختلفة أو قواعد تسوية نهائية. انظر "الدمج
الفروع ذات سمات الإيداع / الخروج المختلفة "في gitattributes(5) من أجل
تفاصيل.

لا إعادة التطبيع
لتعطيل خيار إعادة التسوية. هذا يتجاوز الدمج
متغير التكوين.

عتبة إعادة التسمية =
يتحكم في حد التشابه المستخدم لاكتشاف إعادة التسمية. أنظر أيضا بوابة فرق(1)
م.

الشجرة الفرعية [= ]
هذا الخيار هو شكل أكثر تقدمًا من الشجرة الفرعية الاستراتيجية ، حيث تجعل الإستراتيجية
تخمين حول كيفية إزاحة شجرتين لتتوافق مع بعضهما البعض عند الدمج.
بدلاً من ذلك ، يكون المسار المحدد مسبوقًا (أو تم تجريده من البداية) لعمله
شكل شجرتين لمطابقة.

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

لنا
هذا يحل أي عدد من الرؤوس ، ولكن الشجرة الناتجة من الدمج هي دائمًا كذلك
من رئيس الفرع الحالي ، يتجاهل بشكل فعال جميع التغييرات من جميع الفروع الأخرى.
من المفترض أن تستخدم لتحل محل تاريخ التطور القديم للفروع الجانبية. ملحوظة
أن هذا يختلف عن الخيار -Xours إلى العودية استراتيجية الدمج.

الشجرة الفرعية
هذه استراتيجية تكرارية معدلة. عند دمج الأشجار A و B ، إذا كان B يتوافق مع
يتم ضبط الشجرة الفرعية من A ، B أولاً لتتناسب مع بنية الشجرة A ، بدلاً من
قراءة الأشجار في نفس المستوى. يتم إجراء هذا التعديل أيضًا للمشترك
شجرة الجد.

مع الإستراتيجيات التي تستخدم الدمج ثلاثي الاتجاهات (بما في ذلك الإعداد الافتراضي ، العودية) ، إذا كان هناك تغيير
تم إجراؤه على كلا الفرعين ، ولكن تم إرجاعه لاحقًا على أحد الفروع ، سيكون هذا التغيير
موجودة في النتيجة المدمجة ؛ يجد بعض الناس هذا السلوك محيرًا. يحدث ذلك بسبب
فقط الرؤوس وقاعدة الدمج تؤخذ في الاعتبار عند إجراء الدمج ، وليس
الالتزامات الفردية. لذلك تعتبر خوارزمية الدمج التغيير المعاد لا
التغيير على الإطلاق ، واستبدال النسخة المعدلة بدلاً من ذلك.

DEFAULT سلوك

غالبًا ما يستخدم الأشخاص git pull دون إعطاء أي معلمة. تقليديا ، كان هذا
يعادل قول أصل git pull. ومع ذلك ، عندما فرع التكوين. .remote هو
الحاضر أثناء التواجد في الفرع ، يتم استخدام هذه القيمة بدلاً من الأصل.

لتحديد عنوان URL الذي يجب استخدامه للجلب منه ، قيمة التهيئة
بعيد. تتم استشارة .url وإذا لم يكن هناك أي متغير من هذا القبيل ، فإن القيمة الموجودة على عنوان URL:
سطر في "$ GIT_DIR / ريموتات / يستخدم الملف.

من أجل تحديد الفروع البعيدة المطلوب جلبها (وتخزينها اختياريًا في ملف
فروع التعقب عن بعد) عند تشغيل الأمر بدون أي معلمات refspec على ملف
سطر الأوامر ، قيم متغير التكوين البعيد. يتم استشارة .fetch ،
وإذا لم يكن هناك أي منها ، $ GIT_DIR / remotes / يتم استشارة الملف و `` Pull: '' الخاص به
يتم استخدام الخطوط. بالإضافة إلى تنسيقات refspec الموضحة في قسم OPTIONS ، فإنك تقوم بذلك
يمكن أن يكون لها ملف مرجعي متلألئ يشبه هذا:

المراجع / الرؤوس / *: المراجع / أجهزة التحكم عن بُعد / الأصل / *

يجب أن يحتوي الملف المرجعي المتلألئ على RHS غير فارغ (على سبيل المثال ، يجب تخزين ما تم جلبه فيه
فروع التعقب عن بعد) ، ويجب أن ينتهي LHS و RHS بـ / *. ما ورد أعلاه يحدد ذلك
يتم تتبع جميع الفروع البعيدة باستخدام فروع التتبع عن بعد في المراجع / أجهزة التحكم عن بعد / الأصل /
التسلسل الهرمي تحت نفس الاسم.

قاعدة تحديد الفرع البعيد المراد دمجه بعد الجلب متضمنة بعض الشيء
أمر بعدم كسر التوافق مع الإصدارات السابقة.

إذا تم تقديم refspecs الصريحة في سطر أوامر git pull ، فسيتم دمجها جميعًا.

عندما لا يتم إعطاء refspec في سطر الأوامر ، فإن git pull يستخدم refspec من ملف
التكوين أو $ GIT_DIR / أجهزة التحكم عن بعد / . في مثل هذه الحالات ، يتم تطبيق القواعد التالية:

1. إذا كان الفرع. تكوين دمج للفرع الحالي موجود ، هذا هو
اسم الفرع في الموقع البعيد الذي تم دمجه.

2. إذا كان المرجع (refspec) خافتًا ، فلن يتم دمج أي شيء.

3. وإلا يتم دمج الفرع البعيد من المرجع الأول.

أمثلة

قم بتحديث فروع التتبع عن بعد للمستودع الذي قمت باستنساخه منه ، ثم ادمج أحدها
منهم في فرعك الحالي:

$ git pull ، git pull origin

عادةً ما يكون الفرع المندمج هو رأس المستودع البعيد ، لكن الخيار هو
يحدده الفرع. . remote و Branch. خيارات الدمج يرى شخص سخيف-
التكوين(1) لمزيد من التفاصيل.

· دمج الفرع البعيد التالي في الفرع الحالي:

git سحب الأصل بعد ذلك

هذا يترك نسخة من التالي مؤقتًا في FETCH_HEAD ، لكن لا يتم تحديث أي منها
فروع التعقب عن بعد. باستخدام فروع التتبع عن بعد ، يمكن القيام بنفس الشيء عن طريق
استدعاء الجلب والدمج:

أصل إحضار $ git
أصل الدمج $ git / next

إذا حاولت سحبًا نتج عنه صراعات معقدة وتريد البدء من جديد ، فأنت
يمكن أن يتعافى مع طائرة نفاثة إعادة تعيين.

استخدم git-pull عبر الإنترنت باستخدام خدمات onworks.net