GIT-PULL(1) دستورات عمومی کاربر GIT-PULL(1)

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

git pull [<options>] [<repository> [<refspec>...]]

تغییرات را از یک مخزن دوردست در شاخه فعلی ادغام می‌کند.

ابتدا، git pull دستور git fetch را با همان آرگومان‌ها (به‌جز گزینه‌های ادغام) برای واکشی شاخه(های) دوردست اجرا می‌کند. سپس تصمیم می‌گیرد که کدام شاخه دوردست را ادغام کند: اگر git pull را بدون هیچ آرگومانی اجرا کنید، این مورد به‌طور پیش‌فرض شاخه بالادست (upstream) برای شاخه فعلی خواهد بود. سپس آن شاخه را در شاخه فعلی ادغام می‌کند.

برای ادغام شاخه دوردست، ۴ گزینه اصلی وجود دارد:

1.دستور git pull --ff-only تنها به‌روزرسانی‌های «فست‌فوروارد» (fast-forward) را انجام می‌دهد: اگر شاخه محلی شما از شاخه دوردست واگرا شده باشد، با شکست مواجه می‌شود. این حالت پیش‌فرض است.
2.دستور git pull --rebase دستور git rebase را اجرا می‌کند.
3.دستور git pull --no-rebase دستور git merge را اجرا می‌کند.
4.دستور git pull --squash دستور git merge --squash را اجرا می‌کند.

همچنین می‌توانید گزینه‌های پیکربندی pull.rebase، pull.squash یا pull.ff را با رفتار مورد نظر خود تنظیم کنید.

اگر در طول ادغام یا ری‌بیس با یک تداخل ادغام مواجه شدید که نمی‌خواهید آن را مدیریت کنید، می‌توانید با خیال راحت آن را با git merge --abort یا git rebase --abort لغو کنید.

<repository>

مخزن «دوردست» (remote) برای پول کردن از آن. این مقدار می‌تواند یک نشانی اینترنتی (بخش GIT URLS در زیر را ببینید) یا نام یک ریموت باشد (بخش REMOTES در زیر را ببینید).

پیش‌فرض آن بالادست پیکربندی‌شده برای شاخه کنونی، یا origin است. برای اطلاعات بیشتر در مورد نحوه پیکربندی بالادست‌ها، بخش UPSTREAM BRANCHES در زیر را ببینید.

<refspec>

کدام شاخه یا سایر ارجاع(ها) واکشی و در شاخه کنونی ادغام شوند؛ برای مثال main در git pull origin main. پیش‌فرض آن بالادست پیکربندی‌شده برای شاخه کنونی است.

این می‌تواند یک شاخه، تگ یا مجموعه دیگری از ارجاع(ها) باشد. برای نحو کامل، <refspec> در زیر تحت عنوان «گزینه‌های مربوط به واکشی» را ببینید، و برای نحوه استفاده git pull از این آرگومان جهت تعیین شاخه دوردستی که باید ادغام شود، بخش DEFAULT BEHAVIOUR در زیر را مشاهده کنید.

-q, --quiet

این گزینه به هر دو دستور زیربنایی git-fetch (جهت فرونشاندن گزارش‌ها حین انتقال) و git-merge (جهت فرونشاندن خروجی حین ادغام) ارسال می‌شود.

-v, --verbose

گزینه --verbose را به git-fetch و git-merge ارسال می‌کند.

--recurse-submodules[=(yes|on-demand|no)], --no-recurse-submodules

این گزینه کنترل می‌کند که آیا کامیت‌های جدید زیرماژول‌های مقداردهی‌شده باید واکشی شوند و آیا درخت‌های کاری زیرماژول‌های فعال نیز باید به‌روزرسانی شوند یا خیر (ببینید git-fetch(1)، git-config(1) و gitmodules(5)).

اگر بررسی و تحویل (checkout) از طریق ری‌بیس انجام شود، کامیت‌های محلی زیرماژول نیز ری‌بیس می‌شوند.

اگر به‌روزرسانی از طریق ادغام انجام شود، تداخل‌های زیرماژول حل و دریافت (checked out) می‌شوند.

--commit, --no-commit

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

با --no-commit ادغام را انجام داده و درست پیش از ایجاد کامیت ادغام متوقف می‌شود، تا به کاربر فرصت بازبینی و تغییر بیشتر نتیجه ادغام پیش از کامیت کردن داده شود.

توجه داشته باشید که به‌روزرسانی‌های فست‌فوروارد کامیت ادغام ایجاد نمی‌کنند و بنابراین راهی برای متوقف کردن آن ادغام‌ها با --no-commit وجود ندارد. از این رو، اگر می‌خواهید مطمئن شوید که شاخه شما توسط دستور ادغام تغییر یا به‌روزرسانی نمی‌شود، از --no-ff همراه با --no-commit استفاده کنید.

--edit, -e, --no-edit

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

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

--cleanup=<mode>

این گزینه تعیین می‌کند که پیام ادغام پیش از کامیت چگونه پاک‌سازی شود. برای جزئیات بیشتر git-commit(1) را ببینید. علاوه بر این، اگر به <mode> مقدار scissors داده شود، در صورت بروز تداخل ادغام، خط قیچی (scissors) پیش از ارسال به سازوکار کامیت به MERGE_MSG اضافه خواهد شد.

--ff-only

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

--ff, --no-ff

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

با --ff، در صورت امکان ادغام را به‌صورت فست‌فوروارد حل می‌کند (تنها اشاره‌گر شاخه را مطابق با شاخه ادغام‌شده به‌روزرسانی می‌کند؛ کامیت ادغام ایجاد نمی‌کند). در صورت عدم امکان (زمانی که تاریخچه ادغام‌شده از نوادگان تاریخچه کنونی نباشد)، یک کامیت ادغام ایجاد می‌کند.

با --no-ff، در تمام موارد یک کامیت ادغام ایجاد می‌کند، حتی زمانی که ادغام می‌توانست به‌صورت فست‌فوروارد حل شود.

-S[<key-id>], --gpg-sign[=<key-id>], --no-gpg-sign

کامیت ادغام حاصل را با GPG امضا می‌کند. آرگومان <key-id> اختیاری است و پیش‌فرض آن هویت کامیت‌کننده است؛ در صورت تعیین، باید بدون فاصله به گزینه متصل باشد. --no-gpg-sign برای باطل کردن هم متغیر پیکربندی commit.gpgSign و هم گزینه قبلی --gpg-sign مفید است.

--log[=<n>], --no-log

علاوه بر نام شاخه‌ها، پیام لاگ را با توضیحات یک‌خطی از حداکثر <n> کامیت واقعی که در حال ادغام هستند پر می‌کند. همچنین git-fmt-merge-msg(1) را ببینید. فقط هنگام ادغام کاربرد دارد.

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

--signoff, --no-signoff

یک دنباله (trailer) Signed-off-by توسط کامیت‌کننده در انتهای پیام لاگ کامیت اضافه می‌کند. معنای signoff به پروژه‌ای که به آن کامیت می‌کنید بستگی دارد. برای مثال، ممکن است گواهی دهد که کامیت‌کننده حق ارسال اثر تحت پروانه پروژه را دارد یا با برخی از بیانیه‌های مشارکت‌کنندگان، مانند «گواهی مبدا توسعه‌دهنده» (Developer Certificate of Origin) موافقت می‌کند. (برای نمونه مورد استفاده توسط هسته لینوکس و پروژه‌های گیت، https://developercertificate.org را ببینید.) برای درک نحوه استفاده از signoffها در پروژه‌ای که در آن مشارکت می‌کنید، با مستندات یا راهبری آن پروژه مشورت کنید.

گزینه --no-signoff می‌تواند برای باطل کردن گزینه قبلی --signoff در خط فرمان استفاده شود.

گیت یک متغیر پیکربندی برای فعال کردن گزینه خط فرمان --signoff به صورت پیش‌فرض ندارد (و نخواهد داشت)؛ برای جزئیات بیشتر ورودی commit.signoff را در gitfaq(7) ببینید.

--stat, -n, --no-stat

یک diffstat در پایان ادغام نمایش می‌دهد. این diffstat همچنین توسط گزینه پیکربندی merge.stat کنترل می‌شود.

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

--compact-summary

یک خلاصه فشرده (compact-summary) در پایان ادغام نمایش می‌دهد.

--squash, --no-squash

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

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

با --squash، استفاده از --commit مجاز نبوده و ناموفق خواهد بود.

فقط هنگام ادغام کاربرد دارد.

--verify, --no-verify

به‌طور پیش‌فرض، قلاب‌های pre-merge و commit-msg اجرا می‌شوند. وقتی --no-verify داده شود، این قلاب‌ها نادیده گرفته می‌شوند. همچنین githooks(5) را ببینید. فقط هنگام ادغام کاربرد دارد.

-s <strategy>, --strategy=<strategy>

از راهبرد ادغام داده‌شده استفاده می‌کند؛ می‌تواند بیش از یک بار مشخص شود تا به ترتیبی که باید امتحان شوند تعیین گردند. اگر گزینه -s مشخص نشود، یک فهرست درونی از راهبردها استفاده می‌شود (ort هنگام ادغام یک سر (head) منفرد، و در غیر این صورت octopus).

-X <option>, --strategy-option=<option>

گزینه خاص راهبرد ادغام را به راهبرد ادغام ارسال می‌کند.

--verify-signatures, --no-verify-signatures

بررسی و تأیید می‌کند که کامیت رأس شاخه جانبی در حال ادغام با یک کلید معتبر امضا شده باشد، یعنی کلیدی که دارای شناسه کاربری (uid) معتبر است: در مدل اعتماد پیش‌فرض، این بدان معناست که کلید امضاکننده توسط یک کلید مورد اعتماد امضا شده است. اگر کامیت رأس شاخه جانبی با کلید معتبر امضا نشده باشد، ادغام لغو می‌شود.

فقط هنگام ادغام کاربرد دارد.

--summary, --no-summary

مترادف‌هایی برای --stat و --no-stat؛ این گزینه‌ها منسوخ شده‌اند و در آینده حذف خواهند شد.

--autostash, --no-autostash

به‌طور خودکار پیش از شروع عملیات یک مدخل اندوخته (stash) موقت ایجاد کرده، آن را در ارجاع MERGE_AUTOSTASH ثبت می‌کند و پس از پایان عملیات اعمال می‌نماید. این بدان معناست که می‌توانید عملیات را روی یک درخت کاری با تغییرات ذخیره‌نشده (dirty) اجرا کنید. با این حال با احتیاط استفاده کنید: اعمال نهایی اندوخته پس از یک ادغام موفق ممکن است به تداخل‌های غیرساده منجر شود.

--allow-unrelated-histories

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

فقط هنگام ادغام کاربرد دارد.

-r, --rebase[=(true|merges|false|interactive)]

true

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

merges

ری‌بیس با استفاده از git rebase --rebase-merges به‌طوری که کامیت‌های ادغام محلی در ری‌بیس گنجانده شوند (برای جزئیات git-rebase(1) را ببینید).

false

شاخه بالادست را در شاخه کنونی ادغام می‌کند.

interactive

حالت تعاملی ری‌بیس را فعال می‌کند.

اگر می‌خواهید کاری کنید که git pull همواره به جای ادغام از --rebase استفاده کند، pull.rebase، branch.<name>.rebase و branch.autoSetupRebase را در git-config(1) ببینید.


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

--no-rebase

این فرم خلاصه --rebase=false است.

--all, --no-all

تمام مخازن دوردست را واکشی می‌کند، به جز مواردی که متغیر پیکربندی remote.<name>.skipFetchAll در آن‌ها تنظیم شده است. این گزینه متغیر پیکربندی fetch.all را نادیده می‌گیرد.

-a, --append

نام‌های مراجع و نام‌های اشیاء مربوط به مراجع واکشی‌شده را به محتویات موجود در .git/FETCH_HEAD الحاق می‌کند. بدون این گزینه، داده‌های قدیمی در .git/FETCH_HEAD بازنویسی خواهند شد.

--atomic

از یک تراکنش اتمیک (تجزیه‌ناپذیر) برای به‌روزرسانی مراجع محلی استفاده می‌کند. یا تمام مراجع به‌روزرسانی می‌شوند، یا در صورت بروز خطا، هیچ مرجعی به‌روزرسانی نمی‌شود.

--depth=<depth>

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

--deepen=<depth>

مشابه --depth است، با این تفاوت که تعداد کامیت‌ها را از مرز کم‌عمق فعلی به جای نوک تاریخچه هر شاخه دوردست مشخص می‌کند.

--shallow-since=<date>

تاریخچه یک مخزن کم‌عمق را عمیق‌تر یا کوتاه‌تر می‌کند تا شامل تمام کامیت‌های قابل دسترس پس از <date> شود.

--shallow-exclude=<ref>

تاریخچه یک مخزن کم‌عمق را عمیق‌تر یا کوتاه‌تر می‌کند تا کامیت‌های قابل دسترس از یک شاخه دوردست یا برچسب مشخص‌شده را مستثنی کند. این گزینه می‌تواند چندین بار مشخص شود.

--unshallow

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

اگر مخزن مبدأ کم‌عمق باشد، تا حد امکان داده‌ها را واکشی می‌کند تا مخزن فعلی همان تاریخچه مخزن مبدأ را داشته باشد.

--update-shallow

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

--negotiation-restrict=(<commit>|<glob>), --negotiation-tip=(<commit>|<glob>)

به‌طور پیش‌فرض، گیت برای یافتن کامیت‌های مشترک به منظور تلاش برای کاهش حجم فایل بسته (packfile) دریافتی، کامیت‌های قابل دسترس از تمام مراجع محلی را به سرور گزارش می‌دهد. در صورت مشخص شدن، گیت فقط کامیت‌های قابل دسترس از نوک‌های (tips) ارائه‌شده را گزارش خواهد داد. این کار برای افزایش سرعت واکشی‌ها زمانی مفید است که کاربر بداند احتمالاً کدام مرجع محلی کامیت‌های مشترکی با مرجع بالادست در حال واکشی دارد.

--negotiation-restrict نام ترجیحی برای این گزینه است؛ --negotiation-tip به‌عنوان یک مترادف پذیرفته می‌شود.

این گزینه ممکن است بیش از یک بار مشخص شود؛ در این صورت، گیت کامیت‌های قابل دسترس از هر یک از کامیت‌های داده‌شده را گزارش خواهد داد.

آرگومان این گزینه می‌تواند یک الگوی جستجو (glob) روی نام مراجع، یک مشخصه مرجع یا SHA-1 (احتمالاً کوتاه‌شده) یک کامیت باشد. مشخص کردن یک الگو معادل تعیین این گزینه به دفعات متعدد است، یکی به ازای هر نام مرجع منطبق.

همچنین متغیرهای پیکربندی fetch.negotiationAlgorithm و push.negotiate مستندشده در git-config(1)، و گزینه --negotiate-only در زیر را ببینید.

--negotiation-include=(<commit>|<glob>)

اطمینان حاصل می‌کند که کامیت‌های موجود در نوک‌های داده‌شده، بدون توجه به آنچه الگوریتم مذاکره انتخاب می‌کند، در طول مذاکره واکشی همیشه به‌عنوان خطوط "have" ارسال شوند. این کار برای تضمین این است که تاریخچه مشترک قابل دسترس از مراجع خاص همیشه در نظر گرفته شود، حتی زمانی که --negotiation-restrict مجموعه نوک‌ها را محدود کرده یا الگوریتم مذاکره در غیر این صورت آن‌ها را نادیده می‌گیرد.

این گزینه ممکن است بیش از یک بار مشخص شود؛ در این صورت، هر کامیت بدون قید و شرط ارسال می‌شود.

آرگومان می‌تواند یک نام دقیق مرجع (مانند refs/heads/release)، یک هش شیء یا یک الگوی glob (مانند refs/heads/release/{asterisk}) باشد. نحو الگو مانند --negotiation-restrict است.

اگر --negotiation-restrict استفاده شود، مجموعه have ابتدا توسط آن گزینه محدود شده و سپس گسترش می‌یابد تا شامل نوک‌های مشخص‌شده با --negotiation-include شود.

اگر این گزینه در خط فرمان مشخص نشده باشد، هرگونه مقادیر پیکربندی remote.<name>.negotiationInclude برای مخزن دوردست فعلی به جای آن استفاده می‌شود.

--negotiate-only

هیچ چیزی را از سرور واکشی نمی‌کند، و در عوض نیاکان آرگومان‌های ارائه‌شده به --negotiation-restrict= را که با سرور مشترک هستیم چاپ می‌کند.

این گزینه با --recurse-submodules=(yes|on-demand) ناسازگار است. در داخل گیت، از این گزینه برای پیاده‌سازی گزینه push.negotiate استفاده می‌شود، نگاه کنید به git-config(1).

--dry-run

بدون ایجاد هیچ تغییری، نشان می‌دهد چه کارهایی انجام خواهد شد.

--porcelain

خروجی را در خروجی استاندارد با قالبی آسان برای تجزیه توسط اسکریپت‌ها چاپ می‌کند. برای جزئیات به بخش OUTPUT در git-fetch(1) مراجعه کنید.

این گزینه با --recurse-submodules=(yes|on-demand) ناسازگار است و بر گزینه پیکربندی fetch.output اولویت دارد.

--filter=<filter-spec>

از قابلیت کلون جزئی بهره می‌گیرد و درخواست می‌کند که سرور زیرمجموعه‌ای از اشیاء قابل دسترس را بر اساس یک فیلتر شیء داده‌شده ارسال کند. هنگام استفاده از --filter، مقدار ارائه‌شده در <filter-spec> برای واکشی جزئی استفاده می‌شود.

اگر --filter=auto استفاده شود، مشخصات فیلتر به‌طور خودکار با ترکیب مشخصات فیلتر اعلام‌شده توسط سرور برای مخازن دوردست ضامن (promisor remotes) که کلاینت می‌پذیرد تعیین می‌شود (نگاه کنید به gitprotocol-v2(5) و گزینه پیکربندی promisor.acceptFromServer در git-config(1)).

برای جزئیات مربوط به تمام مشخصات فیلتر موجود دیگر، گزینه --filter=<filter-spec> در git-rev-list(1) را ببینید.

برای نمونه، --filter=blob:none تمام blobها (محتویات فایل‌ها) را تا زمانی که گیت به آن‌ها نیاز پیدا کند فیلتر می‌کند. همچنین، --filter=blob:limit=<size> تمام blobهای با اندازه دست‌کم <size> را فیلتر می‌کند.

-f, --force

هنگامی که git fetch با مشخصه مرجع (refspec) <src>:<dst> استفاده شود، ممکن است همان‌طور که در بخش <refspec> از مستندات git-fetch(1) بحث شده است، از به‌روزرسانی شاخه محلی خودداری کند. این گزینه آن بررسی را نادیده می‌گیرد.

-k, --keep

بسته (pack) دانلودشده را نگه می‌دارد.

--prefetch

مشخصه مرجع (refspec) پیکربندی‌شده را تغییر می‌دهد تا تمام مراجع را در فضای نام refs/prefetch/ قرار دهد. تسک prefetch در git-maintenance(1) را ببینید.

-p, --prune

قبل از واکشی، هرگونه مرجع ردگیری دوردست را که دیگر روی مخزن دوردست وجود ندارد حذف می‌کند. برچسب‌ها در صورتی که صرفاً به دلیل رفتار پیش‌فرض دنبال کردن خودکار برچسب یا به دلیل گزینه --tags واکشی شده باشند، مشمول هرس شدن نیستند. با این حال، اگر برچسب‌ها به دلیل یک مشخصه مرجع صریح واکشی شوند (چه در خط فرمان یا در پیکربندی مخزن دوردست، برای مثال اگر مخزن دوردست با گزینه --mirror کلون شده باشد)، آنگاه مشمول هرس شدن نیز خواهند بود. ارائه گزینه --prune-tags یک حالت کوتاه‌نویسی برای ارائه refspec برچسب است.

--no-tags

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

--refmap=<refspec>

هنگام واکشی مراجع فهرست‌شده در خط فرمان، به جای مقادیر متغیرهای پیکربندی remote.<name>.fetch برای مخزن دوردست، از مشخصه مرجع تعیین‌شده (می‌تواند بیش از یک بار داده شود) برای نگاشت مراجع به شاخه‌های ردگیری دوردست استفاده می‌کند. ارائه یک <refspec> خالی به گزینه --refmap باعث می‌شود گیت مشخصه‌های مرجع پیکربندی‌شده را نادیده بگیرد و کاملاً به مشخصه‌های مرجع ارائه‌شده به‌عنوان آرگومان‌های خط فرمان تکیه کند. برای جزئیات به بخش "Configured Remote-tracking Branches" مراجعه کنید.

-t, --tags

علاوه بر هر چیز دیگری که در غیر این صورت واکشی می‌شد، تمام برچسب‌ها را از مخزن دوردست واکشی می‌کند (یعنی واکشی برچسب‌های دوردست refs/tags/* به درون برچسب‌های محلی با همان نام). استفاده از این گزینه به تنهایی برچسب‌ها را مشمول هرس شدن نمی‌کند، حتی اگر --prune استفاده شده باشد (هرچند اگر برچسب‌ها مقصد یک مشخصه مرجع صریح نیز باشند ممکن است به هر حال هرس شوند؛ نگاه کنید به --prune).

-j <n>, --jobs=<n>

تمام انواع واکشی را به طور هم‌زمان تا سقف <n> پردازش موازی‌سازی می‌کند.

مقدار 0 از یک پیش‌فرض معقول استفاده خواهد کرد.

اگر گزینه --multiple مشخص شده باشد، مخازن دوردست مختلف به‌طور موازی واکشی خواهند شد. اگر چندین زیرماژول واکشی شوند، آن‌ها نیز به‌طور موازی واکشی خواهند شد. برای کنترل مستقل آن‌ها، از تنظیمات پیکربندی fetch.parallel و submodule.fetchJobs استفاده کنید (نگاه کنید به git-config(1)).

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

--set-upstream

اگر واکشی از مخزن دوردست با موفقیت انجام شود، مرجع بالادست (ردگیری) را اضافه می‌کند که توسط دستور بدون آرگومان git-pull(1) و سایر دستورات استفاده می‌شود. برای اطلاعات بیشتر، به branch.<name>.merge و branch.<name>.remote در git-config(1) مراجعه کنید.

--upload-pack <upload-pack>

در صورت ارائه، و زمانی که مخزن مورد نظر برای واکشی توسط git fetch-pack مدیریت می‌شود، آرگومان --exec=<upload-pack> به دستور ارسال می‌شود تا مسیر غیرپیش‌فرضی را برای دستوری که در طرف مقابل اجرا می‌شود مشخص کند.

--progress

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

-o <option>, --server-option=<option>

هنگام برقراری ارتباط با استفاده از نسخه ۲ پروتکل، رشته داده‌شده را به سرور منتقل می‌کند. رشته داده‌شده نباید حاوی کاراکتر NUL یا LF باشد. نحوه مدیریت گزینه‌های سرور، از جمله گزینه‌های ناشناخته، توسط سرور تعیین می‌شود. هنگامی که چندین --server-option=<option> داده شود، همه آن‌ها به همان ترتیبی که در خط فرمان ذکر شده‌اند به طرف مقابل ارسال می‌شوند. هنگامی که هیچ --server-option=<option> از خط فرمان داده نشود، در عوض از مقادیر متغیر پیکربندی remote.<name>.serverOption استفاده می‌شود.

--show-forced-updates

به‌طور پیش‌فرض، گیت بررسی می‌کند که آیا شاخه‌ای در حین واکشی با اجبار به‌روزرسانی (force-updated) شده است یا خیر. این بررسی را می‌توان از طریق fetch.showForcedUpdates غیرفعال کرد، اما گزینه --show-forced-updates تضمین می‌کند که این بررسی انجام شود. به git-config(1) مراجعه کنید.

--no-show-forced-updates

به‌طور پیش‌فرض، گیت بررسی می‌کند که آیا یک شاخه در حین واکشی با اجبار به‌روزرسانی شده است یا خیر. برای رد کردن این بررسی به دلایل عملکردی، گزینه --no-show-forced-updates را ارسال کنید یا fetch.showForcedUpdates را روی false تنظیم نمایید. در صورت استفاده در حین git-pull، گزینه --ff-only همچنان قبل از اقدام به به‌روزرسانی فست‌فوروارد، به‌روزرسانی‌های اجباری را بررسی خواهد کرد. به git-config(1) مراجعه کنید.

-4, --ipv4

فقط از نشانی‌های IPv4 استفاده می‌کند و نشانی‌های IPv6 را نادیده می‌گیرد.

-6, --ipv6

فقط از نشانی‌های IPv6 استفاده می‌کند و نشانی‌های IPv4 را نادیده می‌گیرد.

<repository>

مخزن «دوردستی» که منبع یک عملیات واکشی یا دریافت است. این پارامتر می‌تواند یک نشانی اینترنتی (بخش نشانی‌های گیت (GIT URLS) در ادامه را ببینید) یا نام یک مخزن دوردست (بخش مخازن دوردست (REMOTES) در ادامه را ببینید) باشد.

<refspec>

مشخص می‌کند که کدام مراجع باید واکشی شوند و کدام مراجع محلی باید به‌روزرسانی گردند. هنگامی که هیچ <refspec> در خط فرمان مشخص نشود، در عوض مراجع مورد نظر برای واکشی از متغیرهای remote.<repository>.fetch خوانده می‌شوند (بخش "CONFIGURED REMOTE-TRACKING BRANCHES" را در git-fetch(1) ببینید).

قالب یک پارامتر <refspec> به‌صورت یک علامت مثبت اختیاری +، به‌دنبال آن منبع <src>، به‌دنبال آن یک دو نقطه :، و به‌دنبال آن مقصد <dst> است. زمانی که <dst> خالی باشد می‌توان از دو نقطه صرف‌نظر کرد. <src> معمولاً یک مرجع (ref) یا یک الگوی سراسری (glob) با یک * منفرد است که برای تطبیق مجموعه‌ای از مراجع استفاده می‌شود، اما می‌تواند یک نام شیء هگزادسیمال کاملاً نوشته‌شده نیز باشد.

یک <refspec> می‌تواند حاوی یک * در <src> خود باشد تا تطبیق الگوی ساده را نشان دهد. چنین مشخصه مرجعی مانند یک glob عمل می‌کند که با هر مرجع دارای آن الگو مطابقت دارد. یک <refspec> الگویی باید دقیقاً یک * در هر دو بخش <src> و <dst> داشته باشد. این الگو با جایگزین کردن * با محتوای تطبیق‌یافته از منبع، مراجع را به مقصد نگاشت می‌کند.

اگر پیشوند ^ به یک refspec اضافه شود، به‌عنوان یک refspec منفی تفسیر می‌شود. چنین refspecی به‌جای تعیین اینکه کدام مراجع باید واکشی شوند یا کدام مراجع محلی باید به‌روزرسانی گردند، مراجع مورد نظر برای مستثنی شدن را مشخص می‌کند. یک مرجع در صورتی منطبق در نظر گرفته می‌شود که حداقل با یک refspec مثبت مطابقت داشته باشد و با هیچ refspec منفی مطابقت نداشته باشد. مشخصه‌های مرجع منفی می‌توانند برای محدود کردن دامنه یک refspec الگویی مفید باشند تا شامل مراجع خاصی نشود. خود refspecهای منفی نیز می‌توانند refspecهای الگویی باشند. با این حال، آن‌ها فقط می‌توانند شامل یک <src> باشند و مقصدی (<dst>) مشخص نمی‌کنند. همچنین نام‌های شیء هگزادسیمال کامل پشتیبانی نمی‌شوند.

عبارت tag <tag> همانند refs/tags/<tag>:refs/tags/<tag> است؛ این دستور درخواست واکشی همه‌چیز تا برچسب داده‌شده را دارد.

مرجع دوردستی که با <src> مطابقت دارد واکشی می‌شود، و اگر <dst> یک رشته خالی نباشد، تلاشی برای به‌روزرسانی مرجع محلی منطبق با آن انجام می‌گیرد.

اینکه آیا این به‌روزرسانی بدون گزینه --force مجاز است یا خیر، به فضای نام مرجعی که به آن واکشی می‌شود، نوع شیء در حال واکشی، و اینکه آیا به‌روزرسانی یک فست‌فوروارد محسوب می‌شود یا خیر بستگی دارد. به‌طور کلی، همان قوانینی که برای push اعمال می‌شوند در واکشی نیز برقرارند؛ برای مشاهده این قوانین، به بخش <refspec>... در git-push(1) مراجعه کنید. استثنائات این قوانین که مختص git fetch هستند در زیر ذکر شده‌اند.

تا نسخه ۲.۲۰ گیت، و برخلاف ارسال با git-push(1)، هرگونه به‌روزرسانی در refs/tags/* بدون علامت + در refspec (یا --force) پذیرفته می‌شد. هنگام واکشی، ما تمام به‌روزرسانی‌های برچسب از مخزن دوردست را بدون تفکیک به‌عنوان واکشی‌های اجباری در نظر می‌گرفتیم. از نسخه ۲.۲۰ گیت، واکشی برای به‌روزرسانی refs/tags/* به همان روش ارسال کار می‌کند. یعنی هرگونه به‌روزرسانی بدون + در refspec (یا --force) رد خواهد شد.

برخلاف ارسال با git-push(1)، هرگونه به‌روزرسانی خارج از refs/{tags,heads}/* بدون + در refspec (یا --force) پذیرفته می‌شود؛ خواه این کار مثلاً جابجایی یک شیء درخت با یک blob باشد، یا جابجایی یک کامیت با کامیت دیگری که کامیت قبلی را به‌عنوان والد خود ندارد، و غیره.

برخلاف ارسال با git-push(1)، هیچ پیکربندی‌ای برای تغییر این قوانین وجود ندارد، و هیچ چیزی شبیه به قلاب pre-fetch مشابه قلاب pre-receive وجود ندارد.

همانند ارسال با git-push(1)، تمام قوانین ذکرشده در بالا در مورد مواردی که به‌عنوان به‌روزرسانی مجاز نیستند، می‌توانند با افزودن یک + اختیاری در ابتدای یک refspec (یا استفاده از گزینه خط فرمان --force) لغو شوند. تنها استثنا این است که هیچ مقداری از اجبار باعث نمی‌شود که فضای نام refs/heads/* یک شیء غیرکامیت را بپذیرد.


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

نکته
تفاوتی وجود دارد میان فهرست کردن چندین <refspec> به‌طور مستقیم در خط فرمان git pull و داشتن چندین مدخل remote.<repository>.fetch در پیکربندی شما برای یک <repository> و اجرای یک دستور git pull بدون هیچ پارامتر صریح <refspec>. موارد <refspec> که به‌صورت صریح در خط فرمان فهرست شده‌اند، همیشه پس از واکشی در شاخه جاری ادغام می‌شوند. به عبارت دیگر، اگر بیش از یک مرجع دوردست را فهرست کنید، git pull یک ادغام هشت‌پا (Octopus merge) ایجاد خواهد کرد. از سوی دیگر، اگر هیچ پارامتر صریح <refspec> در خط فرمان فهرست نکنید، git pull تمام <refspec>هایی را که در پیکربندی remote.<repository>.fetch می‌یابد واکشی می‌کند و فقط اولین <refspec> یافت‌شده را در شاخه جاری ادغام می‌نماید. دلیل این امر این است که ایجاد یک ادغام Octopus از مراجع دوردست به‌ندرت انجام می‌شود، در حالی که ردیابی چندین سرشاخه دوردست به‌صورت یکجا با واکشی بیش از یک مرجع معمولاً مفید است.

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

گیت از پروتکل‌های ssh، git، http و https پشتیبانی می‌کند (علاوه بر این، ftp و ftps می‌توانند برای واکشی استفاده شوند، اما این کار ناکارآمد و منسوخ است؛ از آن‌ها استفاده نکنید).

انتقال بومی (یعنی نشانی git://) هیچ‌گونه احراز هویتی انجام نمی‌دهد و باید در شبکه‌های ناامن با احتیاط استفاده شود.

قالب‌های ساختاری زیر می‌توانند با آن‌ها استفاده شوند:

•ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>
•git://<host>[:<port>]/<path-to-git-repo>
•http[s]://<host>[:<port>]/<path-to-git-repo>
•ftp[s]://<host>[:<port>]/<path-to-git-repo>

همچنین می‌توان یک نحو جایگزین شبیه scp را با پروتکل ssh استفاده کرد:

•[<user>@]<host>:/<path-to-git-repo>

این نحو تنها در صورتی تشخیص داده می‌شود که هیچ اسلشی قبل از اولین دو‌نقطه نباشد. این امر به تمایز مسیر محلی که حاوی دو‌نقطه است کمک می‌کند. برای نمونه، مسیر محلی foo:bar می‌تواند به‌صورت یک مسیر مطلق یا ./foo:bar مشخص شود تا از تفسیر نادرست آن به‌عنوان یک نشانی ssh جلوگیری شود.

پروتکل‌های ssh و git علاوه بر این از بسط ~<username> پشتیبانی می‌کنند:

•ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>
•git://<host>[:<port>]/~<user>/<path-to-git-repo>
•[<user>@]<host>:~<user>/<path-to-git-repo>

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

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

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

دستورهای git clone، git fetch و git pull (اما نه git push) یک فایل باندل مناسب را نیز می‌پذیرند. به git-bundle(1) مراجعه کنید.

هنگامی که گیت روش کار با یک پروتکل انتقال معین را نمی‌داند، تلاش می‌کند از دستیار دوردست remote-<transport> در صورت وجود استفاده کند. برای درخواست صریح یک دستیار دوردست، می‌توان از نحو زیر استفاده کرد:

•<transport>::<address>

که در آن <address> می‌تواند یک مسیر، یک سرور و مسیر، یا یک رشته دلخواه شبیه نشانی باشد که توسط دستیار دوردست مربوطه فراخوانی‌شده شناسایی می‌شود. برای جزئیات به gitremote-helpers(7) مراجعه کنید.

اگر تعداد زیادی مخزن دوردست با نام‌های مشابه وجود دارد و می‌خواهید قالب متفاوتی برای آن‌ها استفاده کنید (به گونه‌ای که نشانی‌های مورداستفاده شما به نشانی‌هایی که کار می‌کنند بازنویسی شوند)، می‌توانید یک بخش پیکربندی به این شکل بسازید:

[url "<actual-url-base>"]
        insteadOf = <other-url-base>

برای نمونه، با این تنظیم:

[url "git://git.host.xz/"]
        insteadOf = host.xz:/path/to/
        insteadOf = work:

یک نشانی مانند "work:repo.git" یا مانند "host.xz:/path/to/repo.git" در هر زمینه‌ای که یک نشانی می‌پذیرد به "git://git.host.xz/repo.git" بازنویسی خواهد شد.

اگر می‌خواهید نشانی‌ها را فقط برای ارسال (push) بازنویسی کنید، می‌توانید یک بخش پیکربندی به این شکل بسازید:

[url "<actual-url-base>"]
        pushInsteadOf = <other-url-base>

برای نمونه، با این تنظیم:

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

یک نشانی مانند "git://example.org/path/to/repo.git" برای ارسال‌ها به "ssh://example.org/path/to/repo.git" بازنویسی می‌شود، اما دریافت‌ها (pull) همچنان از نشانی اصلی استفاده خواهند کرد..SH "مخازن دوردست (REMOTES)"

می‌توان از نام یکی از موارد زیر به‌جای نشانی (URL) به‌عنوان آرگومان <repository> استفاده کرد:

•یک مخزن دوردست در فایل پیکربندی گیت: $GIT_DIR/config،
•یک فایل در دایرکتوری $GIT_DIR/remotes، یا
•یک فایل در دایرکتوری $GIT_DIR/branches.

تمامی این موارد همچنین به شما امکان می‌دهند که مشخصه مرجع (refspec) را از خط فرمان حذف کنید زیرا هر یک شامل یک refspec هستند که گیت به‌طور پیش‌فرض از آن استفاده خواهد کرد.

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

[remote "<name>"]
        url = <URL>
        pushurl = <pushurl>
        push = <refspec>
        fetch = <refspec>

شناسه <pushurl> فقط برای ارسال‌ها (push) استفاده می‌شود. این شناسه اختیاری است و پیش‌فرض آن <URL> است. ارسال به یک مخزن دوردست بر روی تمامی pushurlهای تعریف‌شده، یا در صورت تعریف نشدن pushurl، بر روی تمامی urlهای تعریف‌شده اعمال می‌شود. با این حال، در صورت تعریف چندین url، عملیات واکشی (fetch) فقط از اولین url تعریف‌شده واکشی می‌کند.

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

URL: one of the above URL formats
Push: <refspec>
Pull: <refspec>

خطوط Push: توسط git push و خطوط Pull: توسط git pull و git fetch استفاده می‌شوند. برای نگاشت شاخه‌های اضافی می‌توان چندین خط Push: و Pull: مشخص کرد.

می‌توانید نام فایلی را در $GIT_DIR/branches ارائه دهید. نشانی موجود در این فایل برای دسترسی به مخزن استفاده خواهد شد. این فایل باید دارای قالب زیر باشد:

<URL>#<head>

شناسه <URL> الزامی است؛ #<head> اختیاری است.

بسته به نوع عملیات، اگر refspecی در خط فرمان ارائه ندهید، گیت از یکی از refspecهای زیر استفاده می‌کند. عبارت <branch> نام این فایل در $GIT_DIR/branches است و <head> به‌طور پیش‌فرض برابر master است.

دستور git fetch استفاده می‌کند از:

refs/heads/<head>:refs/heads/<branch>

دستور git push استفاده می‌کند از:

HEAD:refs/heads/<head>

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

•این حالت پیش‌فرض برای git pull یا git fetch بدون هیچ آرگومانی است.
•این حالت پیش‌فرض برای git push بدون هیچ آرگومانی با برخی استثناها است. برای نمونه، می‌توانید از گزینه branch.<name>.pushRemote برای ارسال به یک مخزن دوردست متفاوت از مخزنی که از آن دریافت (pull) می‌کنید استفاده کنید، و به‌طور پیش‌فرض با push.default=simple شاخه بالادستی که پیکربندی می‌کنید باید همان نام را داشته باشد.
•دستورات گوناگون، از جمله git checkout و git status، به شما نشان می‌دهند که از زمان انشعاب شما از آن، چند کامیت به شاخه جاری و بالادست اضافه شده است؛ برای مثال "شاخه شما و origin/main واگرا شده‌اند و به ترتیب دارای ۲ و ۳ کامیت متفاوت هستند".

اطلاعات بالادست در .git/config، در فیلدهای "remote" و "merge" ذخیره می‌شود. برای نمونه، اگر شاخه بالادست main برابر با origin/main باشد:

[branch "main"]
   remote = origin
   merge = refs/heads/main

می‌توانید با دستور git push --set-upstream <remote> <branch> یک شاخه بالادست را به‌طور صریح تنظیم کنید، اما گیت اغلب بالادست را به‌طور خودکار برای شما تنظیم می‌کند، برای نمونه:

•هنگامی که یک مخزن را کلون می‌کنید، گیت به‌طور خودکار بالادست را برای شاخه پیش‌فرض تنظیم می‌کند.
•اگر گزینه پیکربندی push.autoSetupRemote را تنظیم کرده باشید، git push اولین باری که یک شاخه را ارسال می‌کنید به‌طور خودکار بالادست را تنظیم خواهد کرد.
•دریافت (checkout) یک شاخه ردگیری دوردست با git checkout <branch> به‌طور خودکار یک شاخه محلی با آن نام ایجاد می‌کند و بالادست را روی شاخه دوردست تنظیم می‌نماید.

نکته

از شاخه‌های بالادست گاهی با عنوان «اطلاعات ردگیری» (tracking information) یاد می‌شود، مانند "تنظیم اطلاعات ردگیری شاخه".

سازوکار ادغام (دستورات git merge و git pull) امکان انتخاب استراتژی‌های ادغام پس‌زمینه را با گزینه -s فراهم می‌کند. برخی از استراتژی‌ها همچنین می‌توانند گزینه‌های ویژه خود را دریافت کنند که می‌توان آن‌ها را با دادن آرگومان‌های -X<option> به git merge و/یا git pull ارسال کرد.

ort

این استراتژی پیش‌فرض ادغام هنگام دریافت (pull) یا ادغام یک شاخه است. این استراتژی فقط می‌تواند دو سرشاخه را با استفاده از الگوریتم ادغام ۳-طرفه حل کند. هنگامی که بیش از یک والد مشترک وجود داشته باشد که بتوان برای ادغام ۳-طرفه از آن استفاده کرد، درختی ادغام‌شده از والدین مشترک ایجاد می‌کند و از آن به‌عنوان درخت مرجع برای ادغام ۳-طرفه بهره می‌برد. بر اساس آزمایش‌های انجام‌شده روی کامیت‌های ادغام واقعی برگرفته از تاریخچه توسعه هسته لینوکس ۲.۶، گزارش شده است که این روش منجر به تعارض‌های ادغام کمتر بدون ایجاد ادغام‌های نادرست می‌شود. علاوه بر این، این استراتژی می‌تواند ادغام‌های شامل تغییر نام را شناسایی و مدیریت کند. این استراتژی از کپی‌های شناسایی‌شده استفاده نمی‌کند. نام این الگوریتم یک کوته‌نوشت ("Ostensibly Recursive’s Twin") است و از این واقعیت ناشی می‌شود که به‌عنوان جایگزینی برای الگوریتم پیش‌فرض قبلی نوشته شده است: recursive.

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

استراتژی ort می‌تواند گزینه‌های زیر را بپذیرد:

ours

این گزینه تکه‌های دارای تعارض (conflicting hunks) را مجبور می‌کند تا با اولویت دادن به نسخه ما (our) به‌طور خودکار و تمیز حل شوند. تغییرات درخت دیگر که با طرف ما تعارضی ندارند، در نتیجه ادغام منعکس می‌شوند. برای یک فایل باینری، کل محتوا از طرف ما گرفته می‌شود.

این گزینه نباید با استراتژی ادغام ours اشتباه گرفته شود؛ آن استراتژی اصلاً به آنچه درخت دیگر شامل می‌شود نگاه نمی‌کند و هر کاری را که درخت دیگر انجام داده دور می‌اندازد و اعلام می‌کند که تاریخچه ما شامل تمام رویدادهایی است که در آن رخ داده است.

theirs

این گزینه برعکس ours است؛ توجه داشته باشید که بر خلاف ours، هیچ استراتژی ادغامی به نام theirs وجود ندارد که بتوان این گزینه ادغام را با آن اشتباه گرفت.

ignore-space-change, ignore-all-space, ignore-space-at-eol, ignore-cr-at-eol

خطوطی را که دارای نوع مشخص‌شده تغییرات در فاصله‌های خالی (whitespace) هستند، به منظور ادغام سه‌طرفه به‌عنوان خطوط بدون تغییر در نظر می‌گیرد. تغییرات فاصله‌های خالی که با تغییرات دیگر در یک خط ترکیب شده باشند، نادیده گرفته نمی‌شوند. همچنین به git-diff(1) -b، -w، --ignore-space-at-eol و --ignore-cr-at-eol مراجعه کنید.
•اگر نسخه آن‌ها (their) فقط تغییرات فاصله خالی را در یک خط ایجاد کرده باشد، از نسخه ما (our) استفاده می‌شود؛
•اگر نسخه ما تغییرات فاصله خالی ایجاد کرده باشد اما نسخه آن‌ها شامل یک تغییر اساسی باشد، از نسخه آن‌ها استفاده می‌شود؛
•در غیر این صورت، ادغام به روش معمول پیش می‌رود.

renormalize

این گزینه یک دریافت (check-out) و ثبت (check-in) مجازی از تمام سه مرحله هر فایلی که نیاز به ادغام سه‌طرفه دارد انجام می‌دهد. این گزینه برای استفاده هنگام ادغام شاخه‌هایی با فیلترهای پاکسازی متفاوت یا قوانین نرمال‌سازی انتهای خط متفاوت در نظر گرفته شده است. برای جزئیات به بخش "Merging branches with differing checkin/checkout attributes" در gitattributes(5) مراجعه کنید.

no-renormalize

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

find-renames[=<n>]

تشخیص تغییر نام را فعال می‌کند و به‌صورت اختیاری آستانه شباهت را تنظیم می‌نماید. این حالت پیش‌فرض است. این گزینه متغیر پیکربندی merge.renames را بازنویسی می‌کند. همچنین به git-diff(1) --find-renames مراجعه کنید.

rename-threshold=<n>

یک مترادف منسوخ‌شده برای find-renames=<n>.

no-renames

تشخیص تغییر نام را خاموش می‌کند. این گزینه متغیر پیکربندی merge.renames را بازنویسی می‌کند. همچنین به git-diff(1) --no-renames مراجعه کنید.

histogram

یک مترادف منسوخ‌شده برای diff-algorithm=histogram.

patience

یک مترادف منسوخ‌شده برای diff-algorithm=patience.

diff-algorithm=(histogram|minimal|myers|patience)

از یک الگوریتم تفاضل (diff) متفاوت هنگام ادغام استفاده می‌کند، که می‌تواند به جلوگیری از ادغام‌های نادرست که ناشی از خطوط منطبق کم‌اهمیت هستند (مانند براکت‌های توابع مجزا) کمک کند. همچنین به git-diff(1) --diff-algorithm مراجعه کنید. توجه داشته باشید که ort به‌طور پیش‌فرض از diff-algorithm=histogram استفاده می‌کند، در حالی که تفاضل‌های معمولی در حال حاضر به‌طور پیش‌فرض از تنظیمات پیکربندی diff.algorithm استفاده می‌نمایند.

subtree[=<path>]

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

recursive

این گزینه اکنون مترادفی برای ort است. تا نسخه 2.49.0 یک پیاده‌سازی جایگزین بود، اما در نسخه 2.50.0 تغییر مسیر یافت تا به معنای ort باشد. استراتژی بازگشتی قبلی، استراتژی پیش‌فرض برای حل دو سرشاخه از نسخه v0.99.9k گیت تا نسخه v2.33.0 بود.

resolve

این استراتژی فقط می‌تواند دو سرشاخه (یعنی شاخه جاری و شاخه دیگری که از آن دریافت کرده‌اید) را با استفاده از یک الگوریتم ادغام ۳-طرفه حل کند. این روش تلاش می‌کند تا ابهامات ادغام ضربدری (criss-cross) را با دقت شناسایی کند. این استراتژی تغییر نام‌ها را مدیریت نمی‌کند.

octopus

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

ours

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

subtree

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

در استراتژی‌هایی که از ادغام ۳-طرفه استفاده می‌کنند (از جمله گزینه پیش‌فرض، ort)، اگر تغییری در هر دو شاخه ایجاد شود اما بعداً در یکی از شاخه‌ها بازگردانی (revert) شود، آن تغییر در نتیجه ادغام وجود خواهد داشت؛ برخی این رفتار را گیج‌کننده می‌دانند. این حالت رخ می‌دهد زیرا هنگام انجام ادغام، فقط سرشاخه‌ها و پایه ادغام (merge base) در نظر گرفته می‌شوند، نه تک‌تک کامیت‌ها. بنابراین الگوریتم ادغام، تغییر بازگردانده‌شده را اصلاً به‌عنوان هیچ تغییری در نظر نمی‌گیرد و در عوض نسخه تغییریافته را جایگزین می‌کند..SH "رفتار پیش‌فرض (DEFAULT BEHAVIOUR)"

اغلب افراد از git pull بدون دادن هیچ پارامتری استفاده می‌کنند. از گذشته، این کار معادل اجرای git pull origin بوده است. با این حال، زمانی که در شاخه <name> هستید و پیکربندی branch.<name>.remote وجود داشته باشد، آن مقدار به‌جای origin استفاده می‌شود.

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

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

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

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

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

اگر مشخصه‌های مرجع (refspecها) به‌طور صریح در خط فرمان git pull داده شده باشند، همگی آن‌ها ادغام می‌شوند.

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

1.اگر پیکربندی branch.<name>.merge برای شاخه جاری <name> وجود داشته باشد، نام شاخه‌ای در سایت دوردست است که ادغام می‌شود.
2.اگر refspec از نوع الگویی (globbing) باشد، چیزی ادغام نمی‌شود.
3.در غیر این صورت، شاخه دوردست مربوط به اولین refspec ادغام می‌شود.

•به‌روزرسانی شاخه‌های ردگیری دوردست برای مخزنی که از آن کلون کرده‌اید، و سپس ادغام یکی از آن‌ها در شاخه جاری: 
$ git pull
$ git pull origin

به‌طور معمول، شاخه‌ای که ادغام می‌شود همان HEAD مخزن دوردست است، اما این انتخاب توسط گزینه‌های branch.<name>.remote و branch.<name>.merge تعیین می‌شود؛ برای جزئیات به git-config(1) مراجعه کنید.

•ادغام شاخه دوردست next در شاخه جاری: 
$ git pull origin next

این دستور یک کپی از next را به‌طور موقت در FETCH_HEAD قرار می‌دهد و شاخه ردگیری دوردست origin/next را به‌روزرسانی می‌کند. همین کار را می‌توان با فراخوانی fetch و merge انجام داد:

$ git fetch origin
$ git merge origin/next

اگر یک عملیات دریافت (pull) انجام دادید که منجر به تعارض‌های پیچیده شد و مایلید از اول شروع کنید، می‌توانید با git reset وضعیت را بازیابی نمایید.

پروتکل‌های fetch و push طوری طراحی نشده‌اند که از سرقت داده‌های مخزن دیگر که قصد اشتراک‌گذاری آن‌ها وجود نداشته جلوگیری کنند. اگر داده‌های خصوصی دارید که باید از یک همتای (peer) مخرب محافظت شوند، بهترین گزینه این است که آن‌ها را در مخزن دیگری ذخیره کنید. این مورد هم برای کلاینت‌ها و هم برای سرورها صدق می‌کند. به‌ویژه، فضاهای نام روی یک سرور برای کنترل دسترسی خواندن مؤثر نیستند؛ شما باید فقط به کلاینت‌هایی دسترسی خواندن به یک فضای نام را بدهید که برای دسترسی خواندن به کل مخزن به آن‌ها اعتماد دارید.

بردار‌های حمله شناخته‌شده به شرح زیر هستند:

1.قربانی خطوط "have" را ارسال می‌کند که شناسه (ID) اشیایی را که در اختیار دارد و صریحاً قصد اشتراک‌گذاری آن‌ها نبوده اما در صورت داشتن آن‌ها توسط همتا می‌توان برای بهینه‌سازی انتقال استفاده کرد، اعلام می‌نماید. مهاجم شناسه شیء X را برای سرقت انتخاب کرده و یک مرجع به X ارسال می‌کند، اما نیازی به ارسال محتوای X ندارد زیرا قربانی از قبل آن را دارد. اکنون قربانی بر این باور است که مهاجم شیء X را دارد و بعداً محتوای X را برای مهاجم پس می‌فرستد. (این حمله برای یک کلاینت ساده‌ترین حالت برای اجرا روی یک سرور است، با ایجاد مرجعی به X در فضای نامی که کلاینت به آن دسترسی دارد و سپس واکشی آن. محتمل‌ترین راه برای اجرای آن توسط سرور روی یک کلاینت، "ادغام" X در یک شاخه عمومی است به این امید که کاربر کارهای اضافی روی این شاخه انجام داده و بدون توجه به ادغام، آن را به سرور ارسال کند.)
2.مشابه مورد ۱، مهاجم شناسه شیء X را برای سرقت انتخاب می‌کند. قربانی یک شیء Y را ارسال می‌کند که مهاجم از قبل در اختیار دارد، و مهاجم به دروغ ادعا می‌کند که X را دارد و نه Y را، بنابراین قربانی Y را به‌صورت یک دلتا (تفاضل) نسبت به X ارسال می‌کند. این دلتا بخش‌هایی از X را که شبیه به Y هستند برای مهاجم آشکار می‌سازد.

در حال حاضر استفاده از --recurse-submodules فقط می‌تواند کامیت‌های جدید را در زیرماژول‌هایی که از قبل دریافت (check out) شده‌اند واکشی کند. هنگامی که مثلاً بالادست یک زیرماژول جدید را در کامیت‌های تازه واکشی‌شده پروژه اصلی اضافه کرده باشد، خود زیرماژول نمی‌تواند واکشی شود و این امر دریافت آن زیرماژول را بعداً بدون نیاز به انجام مجدد واکشی غیرممکن می‌سازد. انتظار می‌رود این مشکل در نسخه آینده گیت برطرف شود.

git-fetch(1)، git-merge(1)، git-config(1)

بخشی از مجموعه git(1)

2026-06-29 Git 2.55.0