GIT-FETCH(1) Git Manual GIT-FETCH(1) نام (NAME) git-fetch - بارگیری اشیاء و ارجاعات از یک مخزن دیگر خلاصه دستور (SYNOPSIS) git fetch [] [ [...]] git fetch [] git fetch --ltiple [] [(|)...] git fetch --ll [] توضیحات (DESCRIPTION) شاخه‌ها و/یا تگ‌ها (که در مجموع "refs" یا ارجاعات نامیده می‌شوند) را از یک یا چند مخزن دیگر به همراه اشیاء لازم برای تکمیل تاریخچه آن‌ها واکشی (fetch) می‌کند. شاخه‌های ردیابی ریموت (remote-tracking branches) به‌روزرسانی می‌شوند (برای روش‌های کنترل این رفتار، توضیحات را در زیر ببینید). به طور پیش‌فرض، هر تگی که به تاریخچه‌های در حال واکشی اشاره کند نیز واکشی می‌شود؛ نتیجه این است که تگ‌هایی که به شاخه‌های مورد نظر شما اشاره دارند دریافت می‌شوند. این رفتار پیش‌فرض را می‌توان با استفاده از گزینه‌های --ags یا --0-tags یا با پیکربندی remote..tagOpt تغییر داد. با استفاده از refspec که تگ‌ها را صراحتاً واکشی می‌کند، می‌توانید تگ‌هایی را که به شاخه‌های مورد نظر شما اشاره نمی‌کنند نیز دریافت کنید. دستور git fetch می‌تواند از یک مخزن یا URL مشخص، یا از چندین مخزن به صورت همزمان (در صورتی که مشخص شده باشد و مدخل remotes. در فایل پیکربندی وجود داشته باشد) واکشی کند. (نگاه کنید به git- config(1)). هنگامی که هیچ ریموتی مشخص نشده باشد، به طور پیش‌فرض ریموت origin استفاده خواهد شد، مگر اینکه یک شاخه بالادست برای شاخه فعلی پیکربندی شده باشد. نام‌های ارجاعاتی که واکشی می‌شوند، همراه با نام اشیائی که به آن‌ها اشاره دارند، در .git/FETCH_HEAD نوشته می‌شوند. این اطلاعات ممکن است توسط اسکریپت‌ها یا سایر دستورات گیت، مانند git-pull(1) استفاده شود. گزینه‌ها (OPTIONS) --ll, --0-all واکشی تمام ریموت‌ها، به جز مواردی که متغیر پیکربندی remote..skipFetchAll برای آن‌ها تنظیم شده باشد. این گزینه متغیر پیکربندی fetch.all را نادیده می‌گیرد و بازنویسی می‌کند. -a, --ppend الحاق نام‌های ارجاع و نام‌های شیء ارجاعات واکشی‌شده به محتویات موجود در .git/FETCH_HEAD. بدون این گزینه، داده‌های قدیمی در .git/FETCH_HEAD بازنویسی خواهند شد. --tomic استفاده از یک تراکنش اتمیک (atomic transaction) برای به‌روزرسانی ارجاعات محلی. یا تمام ارجاعات به‌روزرسانی می‌شوند، یا در صورت بروز خطا، هیچ ارجاعی به‌روزرسانی نمی‌شود. --epth= محدود کردن واکشی به تعداد مشخصی از کامیت‌ها از نوک تاریخچه هر شاخه ریموت. در صورت واکشی در یک مخزن کم‌عمق (shallow) که توسط git clone همراه با گزینه --epth= ایجاد شده است (نگاه کنید به git- clone(1))، تاریخچه را تا تعداد کامیت‌های مشخص‌شده عمیق‌تر یا کوتاه‌تر می‌کند. تگ‌های مربوط به کامیت‌های عمیق‌ترشده واکشی نمی‌شوند. --eepen= مشابه --epth، با این تفاوت که تعداد کامیت‌ها را از مرز کم‌عمق فعلی به جای نوک تاریخچه هر شاخه ریموت مشخص می‌کند. --allow-since= عمیق‌تر یا کوتاه‌تر کردن تاریخچه یک مخزن کم‌عمق به منظور گنجاندن تمام کامیت‌های در دسترس پس از . --allow-exclude= عمیق‌تر یا کوتاه‌تر کردن تاریخچه یک مخزن کم‌عمق برای مستثنی کردن کامیت‌های در دسترس از یک شاخه یا تگ ریموت مشخص‌شده. این گزینه را می‌توان چندین بار مشخص کرد. --nshallow اگر مخزن مبدأ کامل باشد، مخزن کم‌عمق را به یک مخزن کامل تبدیل می‌کند و تمام محدودیت‌های تحمیل‌شده توسط مخازن کم‌عمق را برمی‌دارد. اگر مخزن مبدأ کم‌عمق باشد، تا حد امکان اطلاعات را واکشی می‌کند تا مخزن فعلی همان تاریخچه مخزن مبدأ را داشته باشد. --pdate-shallow به طور پیش‌فرض هنگام واکشی از یک مخزن کم‌عمق، git fetch ارجاعاتی را که نیاز به به‌روزرسانی .git/shallow دارند رد می‌کند. این گزینه .git/shallow را به‌روزرسانی کرده و چنین ارجاعاتی را می‌پذیرد. --0gotiation-restrict=(|), --0gotiation-tip=(|) به طور پیش‌فرض، گیت کامیت‌های در دسترس از تمام ارجاعات محلی را به سرور گزارش می‌دهد تا کامیت‌های مشترک را برای کاهش اندازه packfile دریافتی پیدا کند. در صورت تعیین، گیت تنها کامیت‌های در دسترس از نوک‌های (tips) داده‌شده را گزارش خواهد داد. این امر برای افزایش سرعت واکشی‌ها زمانی که کاربر می‌داند کدام ارجاع محلی احتمالاً کامیت‌های مشترکی با ارجاع ریموت در حال واکشی دارد، مفید است. گزینه --0gotiation-restrict نام ترجیحی برای این گزینه است؛ --0gotiation-tip به عنوان نام مترادف پذیرفته می‌شود. این گزینه ممکن است بیش از یک بار مشخص شود؛ در این صورت، گیت کامیت‌های در دسترس از هر یک از کامیت‌های داده‌شده را گزارش می‌دهد. آرگومان این گزینه می‌تواند یک الگوی glob بر روی نام‌های ارجاع، یک ارجاع، یا شناسه SHA-1 (احتمالاً مخفف‌شده) یک کامیت باشد. تعیین یک glob معادل تعیین این گزینه به تعداد چندین بار، یعنی به ازای هر نام ارجاع منطبق است. همچنین متغیرهای پیکربندی fetch.negotiationAlgorithm و push.negotiate مستندشده در git-config(1) و گزینه --0gotiate-only در زیر را ببینید. --0gotiation-include=(|) اطمینان حاصل می‌کند که کامیت‌های موجود در نوک‌های داده‌شده همیشه به عنوان خطوط "have" در حین مذاکره واکشی ارسال می‌شوند، بدون در نظر گرفتن اینکه الگوریتم مذاکره چه چیزی را انتخاب می‌کند. این امر برای تضمین اینکه تاریخچه مشترک در دسترس از ارجاعات خاص همیشه در نظر گرفته شود، حتی زمانی که --0gotiation-restrict مجموعه نوک‌ها را محدود کرده یا الگوریتم مذاکره آن‌ها را نادیده می‌گیرد، مفید است. این گزینه ممکن است بیش از یک بار مشخص شود؛ در این صورت، هر کامیت بدون قید و شرط ارسال می‌شود. آرگومان می‌تواند یک نام دقیق ارجاع (مثلاً refs/heads/release)، هش یک شیء، یا یک الگوی glob (مثلاً refs/heads/release/{asterisk}) باشد. نحو الگو همانند نحو --0gotiation-restrict است. اگر --0gotiation-restrict استفاده شود، مجموعه have ابتدا توسط آن گزینه محدود شده و سپس برای گنجاندن نوک‌های مشخص‌شده توسط --0gotiation-include افزایش می‌یابد. اگر این گزینه در خط فرمان مشخص نشده باشد، هرگونه مقدار پیکربندی remote..negotiationInclude برای ریموت فعلی در عوض استفاده می‌شود. --0gotiate-only هیچ چیزی از سرور واکشی نکنید، و در عوض اجداد آرگومان‌های ارائه‌شده برای --0gotiation-restrict= را که با سرور مشترک هستیم چاپ کنید. این گزینه با --ecurse-submodules=(yes|on-demand) ناسازگار است. در بخش داخلی این گزینه برای پیاده‌سازی گزینه push.negotiate استفاده می‌شود، نگاه کنید به git-config(1). --ry-run نمایش آنچه بدون اعمال هیچ تغییری انجام خواهد شد. --orcelain چاپ خروجی در خروجی استاندارد در قالبی که به راحتی برای اسکریپت‌ها قابل تجزیه باشد. برای جزئیات بخش خروجی (OUTPUT) را در git-fetch(1) ببینید. این گزینه با --ecurse-submodules=(yes|on-demand) ناسازگار است و بر گزینه پیکربندی fetch.output تقدم دارد. --lter= استفاده از ویژگی کلون جزئی (partial clone) و درخواست اینکه سرور زیرمجموعه‌ای از اشیاء در دسترس را بر اساس یک فیلتر شیء مشخص ارسال کند. هنگام استفاده از --lter، مقدار ارائه‌شده برای واکشی جزئی استفاده می‌شود. اگر --lter=auto استفاده شود، مشخصات فیلتر به صورت خودکار با ترکیب مشخصات فیلتر اعلان‌شده توسط سرور برای ریموت‌های promisor که کلاینت می‌پذیرد تعیین می‌شود (نگاه کنید به gitprotocol-v2(5) و گزینه پیکربندی promisor.acceptFromServer در git-config(1)). برای جزئیات درباره تمام مشخصات فیلتر موجود دیگر، گزینه --lter= در git-rev-list(1) را ببینید. برای مثال، --lter=blob:none تمامی blobها (محتوای فایل‌ها) را تا زمانی که توسط گیت مورد نیاز باشند فیلتر می‌کند. همچنین، --lter=blob:limit= تمام blobهای با اندازه حداقل را فیلتر خواهد کرد. --504ite-fetch-head نوشتن فهرست ارجاعات ریموت واکشی‌شده در فایل FETCH_HEAD مستقیماً زیر $GIT_DIR. این رفتار پیش‌فرض است. ارسال --0-write-fetch-head از خط فرمان به گیت می‌گوید که این فایل را ننویسد. تحت گزینه --ry-run، این فایل هرگز نوشته نمی‌شود. -f, --rce هنگامی که git fetch همراه با refspec به صورت : استفاده شود، ممکن است همان‌طور که در بخش در زیر بحث شده است از به‌روزرسانی شاخه محلی خودداری کند. این گزینه آن بررسی را لغو می‌کند. -k, --ep نگه‌داشتن بسته (pack) بارگیری‌شده. --ltiple امکان تعیین چندین آرگومان و . هیچ نباید مشخص شود. --uto-maintenance, --0-auto-maintenance, --uto-gc, --0-auto-gc اجرای دستور git maintenance run --uto در پایان کار جهت انجام نگهداری خودکار مخزن در صورت نیاز. این گزینه به صورت پیش‌فرض فعال است. --288aph, --0-write-commit-graph نوشتن یک commit-graph پس از واکشی. این گزینه تنظیم پیکربندی fetch.writeCommitGraph را نادیده می‌گیرد و بازنویسی می‌کند. --refetch تغییر refspec پیکربندی‌شده برای قرار دادن تمام ارجاعات در فضای نام refs/prefetch/. تسک prefetch را در git-maintenance(1) ببینید. -p, --rune قبل از واکشی، هرگونه ارجاع ردیابی ریموت را که دیگر در ریموت وجود ندارد حذف کنید. تگ‌ها در صورتی که فقط به دلیل دنبال کردن خودکار پیش‌فرض تگ‌ها یا به دلیل گزینه --ags واکشی شده باشند، مشمول هرس (pruning) نمی‌شوند. با این حال، اگر تگ‌ها به دلیل یک refspec صریح واکشی شوند (چه در خط فرمان و چه در پیکربندی ریموت، برای مثال اگر ریموت با گزینه --rror کلون شده باشد)، آن‌گاه مشمول هرس خواهند شد. تعیین گزینه --rune-tags روشی کوتاه برای ارائه refspec تگ است. برای جزئیات بیشتر بخش «هرس کردن شاخه‌ها» (PRUNING) را در زیر ببینید. -P, --rune-tags قبل از واکشی، در صورت فعال بودن --rune، هرگونه تگ محلی را که دیگر در ریموت وجود ندارد حذف کنید. این گزینه باید با احتیاط بیشتری استفاده شود، زیرا برخلاف --rune هرگونه ارجاع محلی (تگ محلی) ایجادشده را حذف خواهد کرد. این گزینه یک روش کوتاه برای ارائه refspec صریح تگ به همراه --rune است، بحث مربوط به آن را در مستنداتش ببینید. برای جزئیات بیشتر بخش «هرس کردن شاخه‌ها» (PRUNING) را در زیر ببینید. -n, --0-tags به طور پیش‌فرض، تگ‌هایی که به اشیاء بارگیری‌شده از مخزن ریموت اشاره می‌کنند واکشی و به صورت محلی ذخیره می‌شوند. این گزینه این دنبال کردن خودکار تگ‌ها را غیرفعال می‌کند. رفتار پیش‌فرض برای یک ریموت را می‌توان با تنظیم remote..tagOpt مشخص کرد. نگاه کنید به git-config(1). --efetch به جای مذاکره با سرور برای جلوگیری از انتقال کامیت‌ها و اشیاء مرتبط که قبلاً به صورت محلی وجود دارند، این گزینه تمام اشیاء را همان‌طور که یک کلون تازه انجام می‌دهد واکشی می‌کند. از این گزینه برای اعمال مجدد فیلتر کلون جزئی از پیکربندی یا با استفاده از --lter= هنگامی که تعریف فیلتر تغییر کرده است استفاده کنید. نگهداری خودکار پس از واکشی، یکپارچه‌سازی بسته‌های پایگاه داده اشیاء را برای حذف هرگونه شیء تکراری انجام خواهد داد. --efmap= هنگام واکشی ارجاعات ذکرشده در خط فرمان، به جای مقادیر متغیرهای پیکربندی remote..fetch برای مخزن ریموت، از refspec مشخص‌شده (می‌تواند بیش از یک بار داده شود) برای نگاشت ارجاعات به شاخه‌های ردیابی ریموت استفاده کنید. ارائه یک خالی به گزینه --efmap باعث می‌شود گیت refspecهای پیکربندی‌شده را نادیده بگیرد و کاملاً به refspecهای ارائه‌شده به عنوان آرگومان‌های خط فرمان اتکا کند. برای جزئیات بخش «شاخه‌های ردیابی ریموت پیکربندی‌شده» را ببینید. -t, --ags واکشی تمام تگ‌ها از ریموت (یعنی واکشی تگ‌های ریموت refs/tags/* در تگ‌های محلی با همان نام)، علاوه بر هر چیز دیگری که در غیر این صورت واکشی می‌شد. استفاده از این گزینه به تنهایی تگ‌ها را مشمول هرس نمی‌کند، حتی اگر --rune استفاده شود (اگرچه ممکن است تگ‌ها در صورتی که مقصد یک refspec صریح باشند به هر حال هرس شوند؛ گزینه --rune را ببینید). --ecurse-submodules[=(yes|on-demand|no)] کنترل اینکه آیا و تحت چه شرایطی کامیت‌های جدید زیرماژول‌ها نیز باید واکشی شوند. هنگام پیمایش بازگشتی در زیرماژول‌ها، git fetch همیشه تلاش می‌کند زیرماژول‌های "تغییریافته" را واکشی کند، یعنی زیرماژولی که دارای کامیت‌هایی است که توسط یک کامیت ابرپروژه (superproject) تازه واکشی‌شده ارجاع داده شده‌اند اما در کلون محلی زیرماژول وجود ندارند. یک زیرماژول تغییریافته تا زمانی که به صورت محلی مثلاً در $GIT_DIR/modules/ حضور داشته باشد می‌تواند واکشی شود (نگاه کنید به gitsubmodules(7))؛ اگر بالادست یک زیرماژول جدید اضافه کند، آن زیرماژول تا زمانی که کلون نشود (مثلاً توسط git submodule update) نمی‌تواند واکشی شود. هنگامی که روی on-demand تنظیم شود، فقط زیرماژول‌های تغییریافته واکشی می‌شوند. هنگامی که روی yes تنظیم شود، تمام زیرماژول‌های پرشده واکشی می‌شوند و زیرماژول‌هایی که هم پرنشده و هم تغییریافته هستند نیز واکشی می‌گردند. هنگامی که روی no تنظیم شود، زیرماژول‌ها هرگز واکشی نمی‌شوند. در صورت عدم تعیین، این گزینه از مقدار fetch.recurseSubmodules در صورت تنظیم بودن استفاده می‌کند (نگاه کنید به git-config(1))، و در صورت عدم تنظیم پیش‌فرض آن on-demand است. هنگامی که این گزینه بدون هیچ مقداری استفاده شود، پیش‌فرض آن yes خواهد بود. -j , --jobs= موازی‌سازی تمام اشکال واکشی تا سقف شغل (job) در یک زمان. مقدار 0 از یک پیش‌فرض منطقی استفاده خواهد کرد. اگر گزینه --ltiple مشخص شده باشد، ریموت‌های مختلف به صورت موازی واکشی خواهند شد. اگر چندین زیرماژول واکشی شوند، آن‌ها به صورت موازی واکشی می‌شوند. برای کنترل مستقل آن‌ها، از تنظیمات پیکربندی fetch.parallel و submodule.fetchJobs استفاده کنید (نگاه کنید به git-config(1)). به طور معمول، واکشی‌های بازگشتی و چندریموتی موازی سریع‌تر خواهند بود. به طور پیش‌فرض، واکشی‌ها به صورت متوالی انجام می‌شوند، نه به صورت موازی. --0-recurse-submodules غیرفعال کردن واکشی بازگشتی زیرماژول‌ها (این همان اثر استفاده از گزینه --ecurse-submodules=no را دارد). --t-upstream اگر ریموت با موفقیت واکشی شد، ارجاع بالادست (ردیابی) را اضافه کنید که توسط git-pull(1) بدون آرگومان و سایر دستورات استفاده می‌شود. برای اطلاعات بیشتر، گزینه‌های branch..merge و branch..remote در git-config(1) را ببینید. --bmodule-prefix= پیشوند دادن به مسیرهای چاپ‌شده در پیام‌های آگاهی‌بخش مانند "Fetching submodule foo". این گزینه به صورت داخلی هنگام پیمایش بازگشتی روی زیرماژول‌ها استفاده می‌شود. --ecurse-submodules-default=(yes|on-demand) این گزینه به صورت داخلی برای ارائه موقت یک مقدار پیش‌فرض غیرمنفی برای گزینه --ecurse-submodules استفاده می‌شود. تمام روش‌های دیگر پیکربندی واکشی بازگشتی زیرماژول (مانند تنظیمات موجود در gitmodules(5) و git-config(1)) این گزینه را لغو می‌کنند، همان‌طور که تعیین صریح --[no-]recurse-submodules آن را بازنویسی می‌کند. -u, --pdate-head-ok به طور پیش‌فرض git fetch از به‌روزرسانی head که متناظر با شاخه فعلی است خودداری می‌کند. این پرچم آن بررسی را غیرفعال می‌نماید. این صرفاً برای استفاده داخلی جهت ارتباط git pull با git fetch است، و مگر اینکه در حال پیاده‌سازی Porcelain خودتان باشید، قرار نیست از آن استفاده کنید. --pload-pack هنگامی که داده شود، و مخزنی که باید از آن واکشی انجام شود توسط git fetch-pack مدیریت شود، گزینه --\xec= به دستور ارسال می‌شود تا مسیر غیرپیش‌فرضی را برای دستور اجراشده در سمت دیگر تعیین کند. -q, --quiet ارسال --quiet به git-fetch-pack و ساکت کردن سایر دستورات گیت استفاده‌شده در داخل. روند پیشرفت کار به جریان خطای استاندارد گزارش داده نمی‌شود. -v, -- حالت پرگو (verbose). --rogress وضعیت پیشرفت به طور پیش‌فرض روی جریان خطای استاندارد گزارش می‌شود زمانی که به یک ترمینال متصل باشد، مگر اینکه -q مشخص شده باشد. این پرچم وضعیت پیشرفت را حتی اگر جریان خطای استاندارد به ترمینال هدایت نشده باشد اجبار می‌کند. -o