git-pull - آنلاین در ابر

برنامه:

نام

git-pull - واکشی و ادغام با یک مخزن دیگر یا یک شعبه محلی

خلاصه

دستگاه گوارش کشیدن [گزینه ها] [ [ ...]]

شرح

تغییرات را از یک مخزن راه دور در شاخه فعلی گنجانده است. در حالت پیش فرض خود
حالت، git pull مخفف git fetch و سپس ادغام git FETCH_HEAD است.

دقیق تر، دستگاه گوارش کشیدن اجرا می شود دستگاه گوارش رفتن و آوردن با پارامترها و فراخوانی های داده شده دستگاه گوارش ادغام کردن به
سر شاخه های بازیابی شده را در شاخه فعلی ادغام کنید. با --rebase اجرا می شود دستگاه گوارش
تخفیف بجای دستگاه گوارش ادغام کردن.

باید نام یک مخزن راه دور باشد که به آن منتقل شده است git-fetch(1).
می تواند یک مرجع از راه دور دلخواه (مثلاً نام یک تگ) یا حتی الف را نامگذاری کند
مجموعه ای از مراجع با شاخه های ردیابی از راه دور مربوطه (به عنوان مثال،
refs/heads/*:refs/remotes/origin/*)، اما معمولاً نام یک شاخه در ریموت است.
مخزن

مقادیر پیش فرض برای و از "راه دور" و "ادغام" خوانده می شوند
پیکربندی برای شاخه فعلی همانطور که توسط git-branch(1) - آهنگ.

فرض کنید تاریخچه زیر وجود دارد و شاخه فعلی "master" است:

A---B---C استاد در مبدا
/
D---E---F---G استاد
^
مبدا/مستر در مخزن شما

سپس "git pull" تغییرات را از شاخه اصلی راه دور از آن زمان دریافت و دوباره پخش می کند
از Master محلی (یعنی E) تا commit فعلی آن (C) در بالای master و
نتیجه را در یک commit جدید به همراه نام دو کامیت والد و یک گزارش ثبت کنید
پیامی از طرف کاربر که تغییرات را توصیف می کند.

A---B---C مبدا/استاد
/\
D---E---F---G---H استاد

دیدن git-merge(1) برای جزئیات، از جمله نحوه ارائه و رسیدگی به تعارضات.

در Git 1.7.0 یا جدیدتر، برای لغو ادغام متناقض، از git reset --merge استفاده کنید. هشدار: که در
نسخه های قدیمی Git در حال اجرا هستند دستگاه گوارش کشیدن با تغییرات غیرمتعهد دلسرد می شود: در حالی که
ممکن است، شما را در حالتی قرار می دهد که در حالت a ممکن است عقب نشینی از آن سخت باشد
درگیری

اگر هر یک از تغییرات راه دور با تغییرات غیرمتعهد محلی همپوشانی داشته باشد، ادغام خواهد شد
به طور خودکار لغو شده و درخت کار دست نخورده است. به طور کلی بهتر است هر محلی را تهیه کنید
قبل از کشیدن یا پنهان کردن آنها در حالت کار تغییر می کند git-stash(1).

OPTIONS

-q، --آرام
این به هر دو گزارش زیربنایی git-fetch برای squelch در حین انتقال داده می شود.
و git-merge زیربنایی برای squelch خروجی در طول ادغام.

-v، -- پرحرف
عبور --verbose به git-fetch و git-merge.

--[no-]recurse-submodules[=yes|در صورت تقاضا|نه]
این گزینه کنترل می‌کند که آیا commit‌های جدید همه زیر ماژول‌های پر شده نیز باید واکشی شوند
(نگاه کنید به گیت(1) و gitmodules(5)). این ممکن است برای به دست آوردن داده های مورد نیاز ضروری باشد
برای ادغام commit های زیر ماژول، ویژگی Git در 1.7.3 آموخته شده است. توجه کنید که نتیجه
یک ادغام در زیر ماژول بررسی نمی شود، "git submodule update" باید باشد
پس از آن فراخوانی می شود تا درخت کار با نتیجه ادغام به روز شود.

گزینه مربوط به ادغام
--متعهد، --عدم تعهد
ادغام را انجام دهید و نتیجه را انجام دهید. از این گزینه می توان برای لغو استفاده کرد
--عدم تعهد

با --no-commit ادغام را انجام دهید اما وانمود کنید که ادغام ناموفق بوده و به صورت خودکار انجام ندهید.
به کاربر فرصتی برای بازرسی و تغییر بیشتر نتیجه ادغام قبل از آن داده شود
متعهد شدن

--ویرایش، -e، --بدون ویرایش
قبل از انجام ادغام مکانیکی موفق برای ویرایش بیشتر، یک ویرایشگر را فراخوانی کنید
پیام ادغام تولید شده به صورت خودکار، به طوری که کاربر بتواند ادغام را توضیح و توجیه کند. در
گزینه --no-edit را می توان برای پذیرش پیام تولید شده به صورت خودکار استفاده کرد (به طور کلی
دلسرد).

اسکریپت های قدیمی ممکن است به رفتار تاریخی که به کاربر اجازه ویرایش نمی دهد بستگی داشته باشد
پیام گزارش ادغام هنگامی که git merge را اجرا می کنند، ویرایشگر باز شده را مشاهده خواهند کرد. ساختن
تنظیم چنین اسکریپت هایی با رفتار به روز شده، متغیر محیط، آسان تر است
GIT_MERGE_AUTOEDIT را می توان در ابتدای آنها روی "نه" تنظیم کرد.

--ff
هنگامی که ادغام به صورت یک فوروارد سریع حل می شود، فقط نشانگر شاخه را به روز کنید، بدون آن
ایجاد یک commit ادغام این رفتار به طور پیش فرض است.

-- بدون خاموش
حتی زمانی که ادغام به صورت فوروارد سریع حل می شود، یک ادغام commit ایجاد کنید. این است
رفتار پیش‌فرض هنگام ادغام یک برچسب مشروح (و احتمالاً امضا شده).

---فقط
از ادغام و خروج با وضعیت غیر صفر خودداری کنید، مگر اینکه HEAD فعلی قبلاً وجود داشته باشد
به روز یا ادغام را می توان به عنوان یک فوروارد سریع حل کرد.

--log[= ]، --no-log
علاوه بر نام شعب، پیام گزارش را با توضیحات یک خطی پر کنید
حداکثر تعهدات واقعی که در حال ادغام هستند. همچنین ببینید git-fmt-merge-msg(1).

با --no-log توضیحات یک خطی از commit های واقعی در حال ادغام را لیست نکنید.

--stat، -n، --no-stat
در پایان ادغام یک diffstat نشان دهید. diffstat نیز توسط
گزینه پیکربندی merge.stat.

با -n یا --no-stat یک diffstat در پایان ادغام نشان نمی دهد.

-- کدو حلوایی، -- بدون کدو
درخت کار و وضعیت شاخص را طوری تولید کنید که گویی یک ادغام واقعی اتفاق افتاده است (به جز
اطلاعات را ادغام کنید)، اما در واقع commit، حرکت HEAD یا ضبط نکنید
$GIT_DIR/MERGE_HEAD (برای اینکه دستور git commit بعدی یک commit ایجاد کند).
این به شما امکان می دهد یک commit را در بالای شاخه فعلی ایجاد کنید که اثر آن است
مانند ادغام شاخه دیگر (یا بیشتر در مورد هشت پا).

با --no-squash ادغام را انجام دهید و نتیجه را commit کنید. از این گزینه می توان استفاده کرد
نادیده گرفتن -- کدو حلوایی.

-s ، --استراتژی=
از استراتژی ادغام داده شده استفاده کنید. را می توان بیش از یک بار عرضه کرد تا آنها را در
دستور داد باید محاکمه شوند اگر گزینه -s وجود نداشته باشد، یک لیست داخلی از استراتژی ها وجود دارد
به جای آن استفاده می شود (دستگاه گوارش ادغام بازگشتی هنگام ادغام یک سر واحد، دستگاه گوارش ادغام-اختاپوس
در غیر این صورت).

-ایکس ، --strategy-option=
گزینه خاص استراتژی ادغام را به استراتژی ادغام منتقل کنید.

-- تأیید امضاها، --no-verify-signatures
بررسی کنید که تعهدات در حال ادغام دارای امضاهای خوب و قابل اعتماد GPG هستند و لغو می شوند
ادغام در صورت عدم انجام آنها.

-- خلاصه، -- بدون خلاصه
مترادف --stat و --no-stat. این موارد منسوخ شده و در قسمت حذف خواهند شد
آینده.

-r، --rebase[=false|true|Reserve]
وقتی درست است، پس از واکشی، شاخه فعلی را در بالای شاخه بالادست قرار دهید. اگر
یک شاخه ردیابی از راه دور مربوط به شاخه بالادست و
شاخه upstream از آخرین باری که واکشی شده است، مجدداً پایه گذاری شده است، rebase از آن اطلاعات استفاده می کند
از تغییر پایه تغییرات غیر محلی خودداری کنید.

هنگامی که روی حفظ تنظیم شده است، با گزینه --preserve-merges به git rebase منتقل کنید
که commit های ادغام محلی ایجاد شده صاف نمی شوند.

وقتی نادرست است، شاخه فعلی را در شاخه بالادست ادغام کنید.

به pull.rebase، شاخه مراجعه کنید. .rebase و branch.autoSetupRebase in گیت(1) اگر
شما می خواهید کاری کنید که git pull همیشه به جای ادغام از --rebase استفاده کند.

توجه داشته باشید:
این یک بالقوه است خطرناک حالت عملیات تاریخ را بازنویسی می کند، که این کار را می کند
زمانی که آن تاریخ را قبلا منتشر کردید، نوید خوبی نیست. انجام دادن نه از این گزینه استفاده کنید
مگر اینکه خوانده باشید git-rebase(1) با دقت

--بدون تغییر پایه
لغو قبلی -- rebase.

گزینه مربوط به واکشی
--همه
همه ریموت ها را واکشی کنید.

-a، --پیوست
نام های ref و نام اشیاء ref های واکشی شده را به محتویات موجود اضافه کنید
git/FETCH_HEAD. بدون این گزینه، داده های قدیمی در .git/FETCH_HEAD بازنویسی می شوند.

--عمق=
واکشی را به تعداد مشخصی از تعهدات از نوک هر شاخه راه دور محدود کنید
تاریخ. اگر واکشی به a کم عمق مخزن ایجاد شده توسط git clone با --depth=
گزینه (نگاه کنید به git-clone(1))، تاریخچه را به تعداد مشخص شده عمیق یا کوتاه کنید
متعهد می شود. برچسب‌ها برای تعهدات عمیق‌شده واکشی نمی‌شوند.

-- غیر سطحی
اگر مخزن منبع کامل است، یک مخزن کم عمق را به یک مخزن کامل تبدیل کنید.
حذف تمام محدودیت های تحمیل شده توسط مخازن کم عمق.

اگر مخزن منبع کم عمق است، تا آنجا که ممکن است واکشی کنید تا جریان
مخزن دارای تاریخچه ای مشابه با مخزن منبع است.

--به روز رسانی-کم عمق
به طور پیش فرض هنگام واکشی از یک مخزن کم عمق، git fetch آن را رد می کند
نیاز به به روز رسانی git/shallow دارد. این گزینه .git/shallow را به روز می کند و چنین مواردی را می پذیرد.

-f، -- نیرو
چه زمانی دستگاه گوارش رفتن و آوردن با استفاده می شود : refspec، از به روز رسانی آن خودداری می کند
شعبه محلی مگر اینکه شعبه راه دور آن را واکشی یک نسل است
از . این گزینه آن بررسی را لغو می کند.

-k، -- نگه داشتن
بسته دانلود شده را نگه دارید

--بدون برچسب
به طور پیش فرض، برچسب هایی که به اشیایی که از مخزن راه دور دانلود می شوند اشاره می کنند
به صورت محلی واکشی و ذخیره می شوند. این گزینه این تگ خودکار زیر را غیرفعال می کند. در
رفتار پیش فرض برای یک کنترل از راه دور ممکن است با کنترل از راه دور مشخص شود. تنظیم tagOpt.
دیدن گیت(1).

-u، --update-head-ok
به صورت پیش فرض دستگاه گوارش رفتن و آوردن از به روز رسانی هد مطابق با جریان خودداری می کند
شاخه. این پرچم چک را غیرفعال می کند. این صرفاً برای استفاده داخلی است دستگاه گوارش کشیدن
برای برقراری ارتباط با دستگاه گوارش رفتن و آوردن، و مگر اینکه شما در حال پیاده سازی پرسلن خود هستید
قرار نیست از آن استفاده کنند

-- آپلود-بسته
هنگامی که داده می شود، و مخزن برای واکشی توسط آن اداره می شود دستگاه گوارش واکشی بسته,
--exec= به دستور تعیین مسیر غیر پیش فرض برای
دستور در انتهای دیگر اجرا شود.

--پیش رفتن
وضعیت پیشرفت در جریان خطای استاندارد به‌طور پیش‌فرض زمانی گزارش می‌شود
به یک ترمینال متصل است، مگر اینکه -q مشخص شده باشد. این پرچم حتی وضعیت پیشرفت را تحمیل می کند
اگر جریان خطای استاندارد به یک ترمینال هدایت نشود.


مخزن "راه دور" که منبع عملیات واکشی یا کشش است. این
پارامتر می تواند یک URL (به بخش GIT URLs زیر مراجعه کنید) یا نام یک کنترل از راه دور باشد
(به بخش ریموت در زیر مراجعه کنید).


مشخص می‌کند کدام مرجع واکشی و کدام مرجع محلی به‌روزرسانی شود. وقتی نه س
در خط فرمان ظاهر می شود، refs برای واکشی از راه دور خوانده می شود. .رفتن و آوردن
در عوض متغیرها (نگاه کنید به git-fetch(1).

قالب الف پارامتر یک + اختیاری است که به دنبال آن منبع ref است
، و به دنبال آن یک علامت :، و به دنبال آن مرجع ref . روده بزرگ می تواند باشد
زمانی که حذف شد خالی است.

برچسب زدن یعنی همان refs/tags/ :refs/tags/ ; درخواست واکشی می کند
همه چیز تا تگ داده شده

داور از راه دور که مطابقت دارد واکشی شده است، و اگر رشته خالی نیست
داور محلی که با آن مطابقت دارد با استفاده از آن به سرعت جلو می رود . اگر مثبت + اختیاری باشد
استفاده می شود، مرجع محلی به روز می شود حتی اگر منجر به به روز رسانی سریع به جلو نباشد.

توجه داشته باشید:
زمانی که شاخه راه دوری که می‌خواهید واکشی کنید مشخص می‌شود که بازپیچیده شده و دوباره پایه‌گذاری می‌شود
به طور منظم، انتظار می رود که نوک جدید آن از نسل قبلی خود نباشد
نکته (همانطور که آخرین باری که واکشی کردید در شعبه ردیابی از راه دور ذخیره شده است). شما
می‌خواهد از علامت + برای نشان دادن به‌روزرسانی‌های غیرسریع استفاده کند
برای چنین شاخه هایی هیچ راهی برای تعیین یا اعلام اینکه یک شعبه خواهد بود وجود ندارد
با این رفتار در یک مخزن در دسترس قرار گرفته است. کاربر کشنده به سادگی باید
بدانید که این الگوی استفاده مورد انتظار برای یک شاخه است.

توجه داشته باشید:
بین فهرست کردن چندتایی تفاوت وجود دارد به طور مستقیم بر روی دستگاه گوارش کشیدن
خط فرمان و داشتن چندین ریموت واکشی ورودی ها در شما
پیکربندی برای a و در حال اجرا a دستگاه گوارش کشیدن دستور بدون هیچ
صریح مولفه های. s به صراحت در خط فرمان فهرست شده است
همیشه پس از واکشی در شاخه فعلی ادغام می شوند. به عبارت دیگر، اگر شما
بیش از یک مرجع از راه دور فهرست کنید، دستگاه گوارش کشیدن ادغام اختاپوس ایجاد می کند. از سوی دیگر
دست، اگر شما هر گونه صریح را لیست نکنید پارامتر در خط فرمان، دستگاه گوارش
کشیدن همه را واکشی خواهد کرد آن را در کنترل از راه دور پیدا می کند. .رفتن و آوردن
پیکربندی و فقط اولین مورد را ادغام کنید در شاخه فعلی یافت می شود.
این به این دلیل است که ساخت اختاپوس از رف های راه دور به ندرت انجام می شود، در حالی که نگهداری می شود
ردیابی چندین سر از راه دور در یک حرکت با واکشی بیش از یک اغلب است
مفید است

GIT آدرس های اینترنتی

به طور کلی، URL ها حاوی اطلاعاتی در مورد پروتکل حمل و نقل، آدرس آن هستند
سرور راه دور و مسیر مخزن. بسته به پروتکل حمل و نقل، برخی از
این اطلاعات ممکن است وجود نداشته باشد.

Git از پروتکل های ssh، git، http و https پشتیبانی می کند (علاوه بر این، می توان از ftp و ftps استفاده کرد.
for fetching و 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]/~[user]/path/to/repo.git/

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

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

برای مخازن محلی، که به صورت بومی توسط Git نیز پشتیبانی می‌شوند، سینتکس‌های زیر ممکن است وجود داشته باشند
استفاده شده:

· /path/to/repo.git/

· file:///path/to/repo.git/

این دو نحو عمدتاً معادل هستند، به جز هنگام شبیه‌سازی که اولی دلالت دارد
- گزینه محلی دیدن git-clone(1) برای جزئیات.

وقتی Git نمی داند چگونه با یک پروتکل حمل و نقل خاص مدیریت کند، سعی می کند از آن استفاده کند
از راه دور- کمک از راه دور، در صورت وجود. برای درخواست صریح کمک از راه دور،
ممکن است از نحو زیر استفاده شود:

· ::

جایی که ممکن است یک مسیر، یک سرور و مسیر، یا یک رشته URL مانند دلخواه باشد
توسط کمکی از راه دور خاص که فراخوانی می شود شناسایی می شود. دیدن gitremote-helpers(1) برای
جزئیات.

اگر تعداد زیادی مخزن راه دور با نام مشابه وجود دارد و می خواهید از a استفاده کنید
فرمت های مختلف برای آنها (مانند 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 as استفاده کرد بحث و جدل:

یک کنترل از راه دور در فایل پیکربندی Git: $GIT_DIR/config،

یک فایل در دایرکتوری $GIT_DIR/remotes یا

یک فایل در دایرکتوری $GIT_DIR/branches.

همه اینها همچنین به شما این امکان را می‌دهند که refspec را از خط فرمان حذف کنید زیرا هر کدام از آنها هستند
حاوی یک refspec است که git به طور پیش فرض از آن استفاده خواهد کرد.

تحت عنوان دور in پیکر بندی پرونده
می‌توانید نام کنترلی را که قبلاً با استفاده از آن پیکربندی کرده‌اید، ارائه کنید
git-remote(1) گیت(1) یا حتی با ویرایش دستی فایل $GIT_DIR/config. URL
از این ریموت برای دسترسی به مخزن استفاده خواهد شد. مشخصات این ریموت خواهد بود
زمانی که شما یک refspec در خط فرمان ارائه نمی کنید به طور پیش فرض استفاده می شود. ورود در
فایل کانفیگ به شکل زیر ظاهر می شود:

[از راه دور " "]
آدرس =
pushurl =
فشار =
واکشی =

در فقط برای هل استفاده می شود. اختیاری است و به صورت پیش فرض می باشد .

تحت عنوان پرونده in $GIT_DIR/ریموت
شما می توانید انتخاب کنید که نام یک فایل در $GIT_DIR/remotes ارائه شود. آدرس موجود در این فایل
برای دسترسی به مخزن استفاده خواهد شد. refspec در این فایل به عنوان پیش فرض استفاده خواهد شد
هنگامی که شما یک refspec در خط فرمان ارائه نمی کنید. این فایل باید موارد زیر را داشته باشد
قالب:

URL: یکی از قالب های URL بالا
فشار دادن:
کشیدن:

فشار: خطوط توسط دستگاه گوارش فشار و Pull: خطوط توسط استفاده می شود دستگاه گوارش کشیدن و دستگاه گوارش رفتن و آوردن.
خطوط فشار چندگانه: و کشش: ممکن است برای نگاشت شاخه های اضافی مشخص شوند.

تحت عنوان پرونده in $GIT_DIR/شاخه
می‌توانید انتخاب کنید که نام یک فایل در $GIT_DIR/شاخه‌ها ارائه شود. آدرس موجود در این فایل
برای دسترسی به مخزن استفاده خواهد شد. این فایل باید فرمت زیر را داشته باشد:

#

مورد نیاز است؛ # اختیاری است

بسته به عملیات، git از یکی از موارد زیر استفاده می کند، اگر این کار را نکنید
یکی را در خط فرمان ارائه کنید. نام این فایل در $GIT_DIR/branches است
و به طور پیش فرض به استاد می رسد.

کاربردهای git fetch:

refs/heads/ :refs/heads/

کاربردهای git push:

HEAD:refs/heads/

ادغام استراتژی ها

مکانیسم ادغام (دستورهای git merge و git pull) به backend اجازه می دهد ادغام کردن استراتژی ها
با گزینه -s انتخاب شود. برخی از استراتژی ها نیز می توانند گزینه های خود را انتخاب کنند، که می تواند باشد
با دادن -X گذشت آرگومان هایی برای ادغام git و/یا git pull.

تصمیم
این فقط می تواند دو سر را حل کند (یعنی شاخه فعلی و شاخه دیگری که کشیده اید
از) با استفاده از یک الگوریتم ادغام سه طرفه. سعی می کند ادغام متقاطع را با دقت تشخیص دهد
ابهامات و به طور کلی امن و سریع در نظر گرفته می شود.

بازگشتی
این فقط می تواند دو هد را با استفاده از یک الگوریتم ادغام سه طرفه حل کند. زمانی که بیشتر از
یکی از اجداد مشترک که می تواند برای ادغام 3 طرفه استفاده شود، درخت ادغام شده ای را ایجاد می کند
اجداد مشترک و از آن به عنوان درخت مرجع برای ادغام 3 طرفه استفاده می کند. این دارد
گزارش شده است که منجر به تداخل ادغام کمتری بدون ایجاد ادغام نادرست توسط آزمایش می شود
انجام شده در تعهدات ادغام واقعی برگرفته از تاریخچه توسعه هسته لینوکس 2.6.
علاوه بر این، این می‌تواند ادغام‌هایی را که شامل تغییر نام‌ها می‌شود، شناسایی و مدیریت کند. این پیش فرض است
استراتژی ادغام هنگام کشیدن یا ادغام یک شاخه.

La بازگشتی استراتژی می تواند گزینه های زیر را انجام دهد:

خرس
این گزینه باعث می‌شود که بخش‌های متضاد به‌طور خودکار با فایده‌سازی حل و فصل شوند ما
نسخه تغییرات از درخت دیگر که با طرف ما در تضاد نیست
به نتیجه ادغام منعکس می شود. برای یک فایل باینری، کل محتویات گرفته می شود
از طرف ما.

این را نباید با آن اشتباه گرفت خرس استراتژی ادغام، که حتی به نظر نمی رسد
در آنچه که درخت دیگر اصلاً حاوی آن است. هر کاری که درخت دیگر انجام داده را دور می اندازد،
اعلام کرد ما تاریخ شامل همه چیزهایی است که در آن اتفاق افتاده است.

خودشان
این برعکس است خرس.

صبر
با این گزینه ، ادغام بازگشتی برای جلوگیری از ادغام نادرست زمان کمی صرف می کند
که گاهی اوقات به دلیل خطوط تطبیق بی‌اهمیت (مثلاً مهاربندی‌های متمایز).
کارکرد). وقتی شاخه هایی که باید ادغام شوند به شدت از هم جدا شده اند از این استفاده کنید. همچنین ببینید
git-diff(1) - صبر.

diff-algorithm=[صبر|حداقل|هیستوگرام|مایرز]
می گوید ادغام بازگشتی برای استفاده از یک الگوریتم متفاوت متفاوت، که می تواند به جلوگیری از آن کمک کند
ادغام نادرست که به دلیل خطوط تطبیق بی اهمیت (مانند مهاربندها از
توابع متمایز). همچنین ببینید git-diff(1) الگوریتم-diff.

نادیده گرفتن-فضا-تغییر، نادیده گرفتن-همه-فضا، نادیده گرفتن-فضا-در-ایول
خطوط با نوع تغییر فضای خالی مشخص شده را بدون تغییر برای تلقی می کند
به خاطر ادغام سه طرفه تغییرات فضای خالی با سایر تغییرات یک خط ترکیب شده است
نادیده گرفته نمی شوند. همچنین ببینید git-diff(1) -b، -w، و --ignore-space-at-eol.

· اگر شان نسخه فقط تغییرات فضای خالی را به یک خط معرفی می کند، ما نسخه است
استفاده شده؛

· اگر ما نسخه تغییرات فضای خالی را معرفی می کند اما شان نسخه شامل a
تغییر اساسی، شان نسخه استفاده می شود؛

· در غیر این صورت، ادغام به روش معمول انجام می شود.

عادی سازی مجدد
این یک بررسی مجازی و ورود به هر سه مرحله از یک فایل را اجرا می کند
حل ادغام سه طرفه این گزینه برای ادغام شاخه ها استفاده می شود
با فیلترهای مختلف تمیز یا قوانین عادی سازی پایان خط. رجوع کنید به "ادغام
شعبه‌هایی با ویژگی‌های checkin/checkout متفاوت" در ویژگی های gitat(5) برای
جزئیات.

بدون عادی سازی
گزینه Renormalize را غیرفعال می کند. این merge.renormalize را لغو می کند
متغیر پیکربندی

rename-threshold=
آستانه شباهت مورد استفاده برای تشخیص تغییر نام را کنترل می کند. همچنین ببینید git-diff(1)
-م.

درخت فرعی[= ]
این گزینه یک شکل پیشرفته تر است زیر درخت استراتژی، جایی که استراتژی می سازد
حدس در مورد چگونگی جابجایی دو درخت برای مطابقت با یکدیگر هنگام ادغام.
در عوض، مسیر مشخص شده پیشوند (یا از ابتدا حذف شده) برای ساختن است
شکل دو درخت برای مطابقت.

اختاپوس
این موارد با بیش از دو سر را حل می کند، اما از انجام یک ادغام پیچیده آن خودداری می کند
نیاز به وضوح دستی دارد اساساً برای دسته بندی شاخه موضوعی استفاده می شود
سرها با هم این استراتژی ادغام پیش‌فرض هنگام کشیدن یا ادغام بیش از این است
یک شاخه

خرس
این هر تعداد سر را حل می کند، اما درخت حاصل از ادغام همیشه همین است
از سر شاخه فعلی، به طور موثری همه تغییرات را نسبت به سایر شاخه ها نادیده می گیرد.
قرار است از آن برای جایگزینی تاریخچه توسعه قدیمی شاخه های جانبی استفاده شود. توجه داشته باشید
که این با گزینه -Xours متفاوت است بازگشتی استراتژی ادغام

زیر درخت
این یک استراتژی بازگشتی اصلاح شده است. هنگام ادغام درختان A و B، اگر B مطابقت دارد
یک زیردرخت از A، B ابتدا برای مطابقت با ساختار درختی A، به جای تنظیم می شود
خواندن درختان در همان سطح این تعدیل در مورد مشترک نیز انجام می شود
درخت اجداد

با استراتژی هایی که از ادغام سه طرفه استفاده می کنند (از جمله پیش فرض، بازگشتی) در صورت تغییر
روی هر دو شاخه ساخته می شود، اما بعداً روی یکی از شاخه ها برگردانده می شود، این تغییر خواهد بود
موجود در نتیجه ادغام شده؛ برخی افراد این رفتار را گیج کننده می دانند. رخ می دهد زیرا
هنگام انجام ادغام فقط سرها و پایه ادغام در نظر گرفته می شوند، نه ادغام
فردی متعهد می شود بنابراین الگوریتم ادغام، تغییر معکوس‌شده را هیچ در نظر می‌گیرد
اصلاً تغییر کند و به جای آن نسخه تغییر یافته را جایگزین کند.

نمایندگی رفتار - اخلاق

اغلب افراد بدون دادن هیچ پارامتری از git pull استفاده می کنند. به طور سنتی، این بوده است
معادل گفتن git pull origin. با این حال، هنگامی که تنظیمات شاخه. ریموت است
هنگام حضور در شعبه ، از آن مقدار به جای مبدا استفاده می شود.

به منظور تعیین اینکه از چه URL برای واکشی استفاده کنید، مقدار پیکربندی
از راه دور. .url مورد بررسی قرار می گیرد و اگر چنین متغیری وجود نداشته باشد، مقدار URL:
خط در `$GIT_DIR/remotes/ فایل استفاده می شود.

به منظور تعیین اینکه چه شاخه های راه دور باید واکشی شود (و به صورت اختیاری در آن ذخیره شود
شاخه های ردیابی از راه دور) زمانی که دستور بدون هیچ گونه پارامتر refspec روی آن اجرا می شود
خط فرمان، مقادیر ریموت متغیر پیکربندی. واکشی هستند،
و اگر وجود ندارد، $GIT_DIR/remotes/ فایل مورد بررسی قرار می گیرد و آن 'کشش:'
خطوط استفاده می شود. علاوه بر فرمت های refspec که در بخش OPTIONS توضیح داده شده است، شما
می تواند یک refspec globbing داشته باشد که به شکل زیر است:

refs/heads/*:refs/remotes/origin/*

یک refspec globbing باید یک RHS غیر خالی داشته باشد (یعنی باید آنچه را که در آن واکشی شده است ذخیره کند.
شاخه های ردیابی از راه دور)، و LHS و RHS آن باید با /* ختم شود. بالا مشخص می کند که
همه شاخه های راه دور با استفاده از شاخه های ردیابی از راه دور در refs/remotes/origin/ ردیابی می شوند.
سلسله مراتب با همین نام

قانون تعیین اینکه کدام شاخه از راه دور باید پس از واکشی ادغام شود کمی درگیر است
به منظور عدم شکستن سازگاری با عقب.

اگر مشخصات صریح در خط فرمان git pull داده شود، همه آنها ادغام می شوند.

وقتی هیچ refspec در خط فرمان داده نشد، git pull از refspec از the استفاده می کند
پیکربندی یا $GIT_DIR/remotes/ . در چنین مواردی قوانین زیر اعمال می شود:

1. اگر شاخه. پیکربندی .merge برای شاخه فعلی وجود دارد، آن است
نام شعبه در سایت راه دور که ادغام شده است.

2. اگر refspec یک globbing باشد، هیچ چیز ادغام نمی شود.

3. در غیر این صورت شاخه راه دور refspec اول ادغام می شود.

مثال ها

· شاخه های ردیابی از راه دور را برای مخزنی که از آن شبیه سازی کرده اید به روز کنید، سپس یکی را ادغام کنید
از آنها به شعبه فعلی شما:

$ git pull، git pull مبدا

معمولاً شاخه ادغام شده در HEAD مخزن راه دور است، اما انتخاب این است
توسط شعبه تعیین می شود. .ریموت و شعبه. گزینه های ادغام. دیدن git-
پیکربندی(1) برای جزئیات.

· شعبه راه دور را در شاخه فعلی ادغام کنید:

$ git pull مبدا بعدی

این یک کپی از next به طور موقت در FETCH_HEAD باقی می‌گذارد، اما هیچ کدام را به‌روزرسانی نمی‌کند
شاخه های ردیابی از راه دور با استفاده از شاخه های ردیابی از راه دور، همین کار را می توان توسط
فراخوانی واکشی و ادغام:

$ git واکشی منبع
$ git ادغام مبدا/بعدی

اگر کششی را امتحان کردید که منجر به درگیری‌های پیچیده شد و می‌خواهید از نو شروع کنید، شما
می تواند با دستگاه گوارش تنظیم مجدد.

با استفاده از خدمات onworks.net از git-pull آنلاین استفاده کنید