GIT-CONFIG(1)                     Git Manual                     GIT-CONFIG(1)

نام (NAME)
       git-config - دریافت و تنظیم گزینه‌های مخزن یا سراسری

خلاصه دستور (SYNOPSIS)
       git config list [<file-option>] [<display-option>] [--includes]
       git config get [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<pattern>] [--fixed-value] [--default=<default>] [--url=<url>] <name>
       git config set [<file-option>] [--type=<type>] [--all] [--value=<pattern>] [--fixed-value] <name> <value>
       git config unset [<file-option>] [--all] [--value=<pattern>] [--fixed-value] <name>
       git config rename-section [<file-option>] <old-name> <new-name>
       git config remove-section [<file-option>] <name>
       git config edit [<file-option>]
       git config [<file-option>] --get-colorbool <name> [<stdout-is-tty>]


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

       با استفاده از گزینه --append می‌توان چندین خط را به یک گزینه اضافه کرد.
       اگر می‌خواهید گزینه‌ای را که می‌تواند در چندین خط وجود داشته باشد
       به‌روزرسانی یا لغو کنید، باید --value=<pattern> (که یک عبارت منظم
       گسترش‌یافته است، مگر اینکه گزینه --fixed-value داده شده باشد) مشخص شود.
       تنها مقادیر موجودی که با الگو مطابقت دارند به‌روزرسانی یا لغو می‌شوند.
       اگر می‌خواهید خطوطی را مدیریت کنید که با الگو مطابقت ندارند، کافی است یک
       علامت تعجب منفرد در ابتدای آن قرار دهید (همچنین بخش «مثال‌ها (EXAMPLES)»
       را ببینید)، اما توجه داشته باشید که این کار تنها زمانی کار می‌کند که
       گزینه --fixed-value در حال استفاده نباشد.

       گزینه --type=<type> به git config دستور می‌دهد تا اطمینان حاصل کند
       مقادیر ورودی و خروجی تحت <type> داده‌شده قابلیت استانداردسازی
       (canonicalize) دارند. اگر هیچ --type=<type> مشخص نشود، هیچ
       استانداردسازی انجام نخواهد شد. فراخوانندگان می‌توانند مشخص‌کننده موجود
       --type را با --no-type لغو کنند.

       هنگام خواندن، مقادیر به صورت پیش‌فرض از فایل‌های پیکربندی سراسری سیستم
       (system)، سراسری کاربر (global) و محلی مخزن (local) خوانده می‌شوند، و
       می‌توان از گزینه‌های --system، --global، --local، --worktree و --file
       <filename> استفاده کرد تا به دستور گفته شود فقط از همان مکان بخواند
       (بخش «فایل‌ها (FILES)» را ببینید).

       هنگام نوشتن، مقدار جدید به صورت پیش‌فرض در فایل پیکربندی محلی مخزن نوشته
       می‌شود، و می‌توان از گزینه‌های --system، --global، --worktree و --file
       <filename> استفاده کرد تا به دستور گفته شود در آن مکان بنویسد (می‌توانید
       --local را مشخص کنید اما این حالت پیش‌فرض است).

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

       •   بخش یا کلید نامعتبر است (ret=1)،

       •   هیچ بخش یا نامی ارائه نشده است (ret=2)،

       •   فایل پیکربندی نامعتبر است (ret=3)،

       •   نوشتن در فایل پیکربندی امکان‌پذیر نیست (ret=4)،

       •   تلاش برای لغو گزینه‌ای که وجود ندارد (ret=5)،

       •   تلاش برای لغو/تنظیم گزینه‌ای که چندین خط با آن مطابقت دارند (ret=5)،
           یا

       •   تلاش برای استفاده از عبارت منظم نامعتبر (ret=6).

       در صورت موفقیت، این دستور با کد خروج 0 خارج می‌شود.

       فهرستی از تمام متغیرهای پیکربندی موجود را می‌توان با استفاده از دستور
       git help --config به دست آورد.

دستورها (COMMANDS)
       list
           فهرست کردن تمام متغیرهای تنظیم‌شده در فایل پیکربندی، همراه با مقادیر
           آن‌ها.

       get
           مقدار کلید مشخص‌شده را برمی‌گرداند. اگر کلید چندین بار در پیکربندی
           وجود داشته باشد، آخرین مقدار را برمی‌گرداند. اگر --all مشخص شده
           باشد، تمام مقادیر مرتبط با کلید را برمی‌گرداند. اگر کلید وجود نداشته
           باشد، کد خطای 1 را برمی‌گرداند.

       set
           تنظیم مقدار برای یک یا چند گزینه پیکربندی. به صورت پیش‌فرض، این
           دستور از نوشتن گزینه‌های پیکربندی چندمقداری خودداری می‌کند. ارسال
           --all تمام گزینه‌های پیکربندی چندمقداری را با مقدار جدید جایگزین
           می‌کند، در حالی که --value= تمام گزینه‌های پیکربندی را که مقادیرشان
           با الگوی داده‌شده مطابقت دارد جایگزین خواهد کرد.

       unset
           لغو مقدار برای یک یا چند گزینه پیکربندی. به صورت پیش‌فرض، این دستور
           از لغو کلیدهای چندمقداری خودداری می‌کند. ارسال --all تمام گزینه‌های
           پیکربندی چندمقداری را لغو می‌کند، در حالی که --value تمام گزینه‌های
           پیکربندی را که مقادیرشان با الگوی داده‌شده مطابقت دارد لغو خواهد
           کرد.

       rename-section
           تغییر نام بخش داده‌شده به نام جدید.

       remove-section
           حذف بخش داده‌شده از فایل پیکربندی.

       edit
           یک ویرایشگر را برای تغییر فایل پیکربندی مشخص‌شده باز می‌کند؛ شامل
           --system، --global، --local (پیش‌فرض)، --worktree، یا --file
           <config-file>.

گزینه‌ها (OPTIONS)
       --replace-all
           رفتار پیش‌فرض، جایگزینی حداکثر یک خط است. این گزینه تمام خطوط منطبق
           با کلید (و به صورت اختیاری --value=<pattern>) را جایگزین می‌کند.

       --append
           بدون تغییر هیچ‌یک از مقادیر موجود، یک خط جدید به گزینه اضافه می‌کند.
           این کار همانند ارائه --value=^$ در set است.

       --comment <message>
           افزودن یک توضیح (کامنت) در انتهای خطوط جدید یا تغییریافته.

           اگر <message> با یک یا چند نویسه فاصله و به دنبال آن # شروع شود،
           همان‌طور که هست استفاده می‌شود. اگر با # شروع شود، پیش از استفاده یک
           فاصله به ابتدای آن اضافه می‌شود. در غیر این صورت، رشته " # " (یک
           فاصله و سپس علامت هش و سپس یک فاصله) به ابتدای آن اضافه خواهد شد.
           رشته حاصل بلافاصله پس از مقدار تعریف‌شده برای متغیر قرار می‌گیرد.
           <message> نباید حاوی نویسه‌های خط جدید (linefeed) باشد (توضیحات
           چندخطی مجاز نیستند).

       --all
           همراه با get، تمام مقادیر یک کلید چندمقداری را برمی‌گرداند.

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

       --url=<URL>
           هنگامی که یک <name> دوبخشی به صورت <section>.<key> داده شود، مقداری
           برای <section>.<URL>.<key> که بخش <URL> آن بهترین تطابق را با URL
           داده‌شده دارد برگردانده می‌شود (اگر چنین کلیدی وجود نداشته باشد،
           مقدار <section>.<key> به عنوان جایگزین استفاده می‌شود). هنگامی که
           فقط <section> به عنوان نام داده شود، این کار برای تمام کلیدهای آن
           بخش انجام شده و فهرست می‌شوند. در صورتی که مقداری پیدا نشود کد خطای
           1 را برمی‌گرداند.

       --global
           برای گزینه‌های نوشتن: به جای فایل .git/config مخزن، در فایل سراسری
           ~/.gitconfig می‌نویسد، یا در فایل $XDG_CONFIG_HOME/git/config اگر
           این فایل موجود باشد و فایل ~/.gitconfig وجود نداشته باشد.

           برای گزینه‌های خواندن: به جای تمام فایل‌های موجود، فقط از فایل سراسری
           ~/.gitconfig و از $XDG_CONFIG_HOME/git/config می‌خواند.

           همچنین بخش «فایل‌ها (FILES)» را ببینید.

       --system
           برای گزینه‌های نوشتن: به جای فایل .git/config مخزن، در فایل سراسری
           سیستم $(prefix)/etc/gitconfig می‌نویسد.

           برای گزینه‌های خواندن: به جای تمام فایل‌های موجود، فقط از فایل سراسری
           سیستم $(prefix)/etc/gitconfig می‌خواند.

           همچنین بخش «فایل‌ها (FILES)» را ببینید.

       --local
           برای گزینه‌های نوشتن: در فایل .git/config مخزن می‌نویسد. این رفتار
           پیش‌فرض است.

           برای گزینه‌های خواندن: به جای تمام فایل‌های موجود، فقط از فایل
           .git/config مخزن می‌خواند.

           همچنین بخش «فایل‌ها (FILES)» را ببینید.

       --worktree
           مشابه --local است، به جز اینکه اگر extensions.worktreeConfig فعال
           باشد، از $GIT_DIR/config.worktree خوانده یا در آن نوشته می‌شود. در
           غیر این صورت همانند --local خواهد بود. توجه داشته باشید که $GIT_DIR
           برای درخت کاری اصلی برابر با $GIT_COMMON_DIR است، اما برای سایر
           درخت‌های کاری به شکل $GIT_DIR/worktrees/<id>/ است. برای یادگیری نحوه
           فعال‌سازی extensions.worktreeConfig به git-worktree(1) مراجعه کنید.

       -f <config-file>, --file <config-file>
           برای گزینه‌های نوشتن: به جای فایل .git/config مخزن، در فایل مشخص‌شده
           می‌نویسد.

           برای گزینه‌های خواندن: به جای تمام فایل‌های موجود، فقط از فایل
           مشخص‌شده می‌خواند.

           همچنین بخش «فایل‌ها (FILES)» را ببینید.

       --blob <blob>
           مشابه --file است اما به جای فایل از blob داده‌شده استفاده می‌کند.
           برای مثال می‌توانید از master:.gitmodules برای خواندن مقادیر از فایل
           .gitmodules در شاخه master استفاده کنید. برای فهرست کامل‌تری از
           روش‌های نگارش نام‌های blob، بخش «SPECIFYING REVISIONS» در
           gitrevisions(7) را ببینید.

       --value=<pattern>, --no-value
           همراه با get، set و unset، تنها با <pattern> تطبیق داده می‌شود. این
           الگو یک عبارت منظم گسترش‌یافته است مگر اینکه --fixed-value داده شده
           باشد.

           از --no-value برای لغو <pattern> استفاده کنید.

       --fixed-value
           هنگامی که همراه با --value=<pattern> استفاده شود، با <pattern> به
           عنوان یک رشته دقیق به جای عبارت منظم رفتار می‌کند. این کار جفت‌های
           نام/مقداری را که مطابقت داده می‌شوند تنها به مواردی محدود می‌کند که
           مقدار دقیقاً برابر با <pattern> باشد.

       --type <type>
           دستور git config اطمینان حاصل خواهد کرد که هر ورودی یا خروجی تحت
           محدودیت(های) نوع داده‌شده معتبر باشد، و مقادیر خروجی را به شکل
           استاندارد <type>'s تبدیل خواهد کرد.

           انواع معتبر <type>'s عبارتند از:

           •   bool: استانداردسازی مقادیر true، yes، on و اعداد مثبت به عنوان
               "true"، و مقادیر false، no، off و 0 به عنوان "false".

           •   int: استانداردسازی مقادیر به صورت اعداد ده‌دهی ساده. یک پسوند
               اختیاری از k، m یا g باعث می‌شود که مقدار در هنگام ورودی در
               1024، 1048576 یا 1073741824 ضرب شود.

           •   bool-or-int: استانداردسازی بر اساس bool یا int، همان‌طور که در
               بالا توضیح داده شد.

           •   path: استانداردسازی با گسترش ~ ابتدایی به مقدار $HOME و ~user
               به دایرکتوری خانگی کاربر مشخص‌شده. این مشخص‌کننده هنگام تنظیم
               مقدار هیچ اثری ندارد (اما می‌توانید از git config
               section.variable ~/ از خط فرمان استفاده کنید تا پوسته شما عمل
               گسترش را انجام دهد.)

           •   expiry-date: استانداردسازی با تبدیل از یک رشته تاریخ ثابت یا
               نسبی به یک برچسب زمان (timestamp). این مشخص‌کننده هنگام تنظیم
               مقدار هیچ اثری ندارد.

           •   color: هنگام دریافت مقدار، با تبدیل به یک توالی گریز رنگ ANSI
               استانداردسازی می‌شود. هنگام تنظیم مقدار، یک بررسی صحت انجام
               می‌شود تا اطمینان حاصل شود که مقدار داده‌شده به عنوان یک رنگ ANSI
               قابلیت استانداردسازی دارد، اما همان‌طور که هست نوشته می‌شود.

           اگر دستور در حالت list باشد، آنگاه آرگومان --type <type> برای هر
           مقدار پیکربندی فهرست‌شده اعمال خواهد شد. اگر مقدار با موفقیت در آن
           قالب تجزیه نشود، از فهرست حذف خواهد شد.

       --bool, --int, --bool-or-int, --path, --expiry-date
           گزینه‌های قدیمی برای انتخاب یک مشخص‌کننده نوع. در عوض ترجیحاً از
           --type استفاده کنید (بالا را ببینید).

       --no-type
           مشخص‌کننده نوعی را که پیش‌تر تنظیم شده بود لغو می‌کند (اگر پیش‌تر تنظیم
           شده باشد). این گزینه درخواست می‌کند که git config متغیر بازیابی‌شده
           را استانداردسازی نکند.  --no-type بدون --type=<type> یا --<type>
           هیچ اثری ندارد.

       -z, --null
           برای تمام گزینه‌هایی که مقادیر و/یا کلیدها را خروجی می‌دهند، همواره
           مقادیر را با نویسه null خاتمه می‌دهد (به جای خط جدید). در عوض از خط
           جدید به عنوان جداکننده میان کلید و مقدار استفاده می‌کند. این کار
           امکان تجزیه امن خروجی را فراهم می‌آورد بدون اینکه برای مثال به دلیل
           وجود مقادیری که حاوی شکست خط هستند دچار سردرگمی شود.

       --name-only
           تنها نام‌های متغیرهای پیکربندی را برای list یا get خروجی می‌دهد.

       --show-names, --no-show-names
           همراه با get، کلیدهای پیکربندی را علاوه بر مقادیر آن‌ها نشان می‌دهد.
           حالت پیش‌فرض --no-show-names است، مگر اینکه --url داده شده باشد و
           هیچ زیربخشی در <name> وجود نداشته باشد.

       --show-origin
           خروجی تمام گزینه‌های پیکربندی پرس‌وجوشده را با نوع مبدا (فایل، ورودی
           استاندارد، blob، خط فرمان) و مبدا واقعی (مسیر فایل پیکربندی، ref،
           یا شناسه blob در صورت کاربرد) تکمیل می‌کند.

       --show-scope
           مشابه --show-origin است از این نظر که خروجی تمام گزینه‌های پیکربندی
           پرس‌وجوشده را با محدوده (scope) آن مقدار (worktree، local، global،
           system، command) تکمیل می‌کند.

       --get-colorbool <name> [<stdout-is-tty>]
           تنظیمات رنگ را برای <name> (برای مثال color.diff) پیدا کرده و
           "true" یا "false" را خروجی می‌دهد.  <stdout-is-tty> باید "true" یا
           "false" باشد، و هنگامی که پیکربندی روی "auto" باشد در نظر گرفته
           می‌شود. اگر <stdout-is-tty> وجود نداشته باشد، خروجی استاندارد خود
           دستور را بررسی می‌کند و اگر قرار باشد از رنگ استفاده شود با وضعیت 0
           خارج می‌شود، و در غیر این صورت با وضعیت 1 خارج می‌شود. هنگامی که
           تنظیمات رنگ برای name تعریف نشده باشد، دستور از color.ui به عنوان
           پشتیبان استفاده می‌کند.

       --includes, --no-includes
           دستورالعمل‌های include.* را در فایل‌های پیکربندی هنگام جستجوی مقادیر
           رعایت می‌کند. هنگام مشخص شدن یک فایل خاص (برای مثال، با استفاده از
           --file، --global و غیره) به طور پیش‌فرض روی off و هنگام جستجو در
           تمام فایل‌های پیکربندی روی on قرار دارد.

       --default <value>
           هنگام استفاده از get، اگر متغیر درخواستی یافت نشود، به گونه‌ای رفتار
           می‌کند که گویی <value> مقدار تخصیص‌یافته به آن متغیر است.

حالت‌های منسوخ‌شده (DEPRECATED MODES)
       حالت‌های زیر به نفع زیردستورها منسوخ شده‌اند. توصیه می‌شود به نحو (syntax)
       جدید مهاجرت کنید.

       git config <name>
           جایگزین‌شده با git config get <name>.

       git config <name> <value> [<value-pattern>]
           جایگزین‌شده با git config set [--value=<pattern>] <name> <value>.

       -l, --list
           جایگزین‌شده با git config list.

       --get <name> [<value-pattern>]
           جایگزین‌شده با git config get [--value=<pattern>] <name>.

       --get-all <name> [<value-pattern>]
           جایگزین‌شده با git config get [--value=<pattern>] --all <name>.

       --get-regexp <name-regexp>
           جایگزین‌شده با git config get --all --show-names --regexp
           <name-regexp>.

       --get-urlmatch <name> <URL>
           جایگزین‌شده با git config get --url=<URL> <name>.

       --get-color <name> [<default>]
           جایگزین‌شده با git config get --type=color [--default=<default>]
           <name>.

       --add <name> <value>
           جایگزین‌شده با git config set --append <name> <value>.

       --unset <name> [<value-pattern>]
           جایگزین‌شده با git config unset [--value=<pattern>] <name>.

       --unset-all <name> [<value-pattern>]
           جایگزین‌شده با git config unset [--value=<pattern>] --all <name>.

       --rename-section <old-name> <new-name>
           جایگزین‌شده با git config rename-section <old-name> <new-name>.

       --remove-section <name>
           جایگزین‌شده با git config remove-section <name>.

       -e, --edit
           جایگزین‌شده با git config edit.

پیکربندی (CONFIGURATION)
       مقدار pager.config تنها هنگام فهرست کردن پیکربندی رعایت می‌شود، یعنی
       هنگام استفاده از list یا get که ممکن است چندین نتیجه را برگردانند. حالت
       پیش‌فرض استفاده از صفحه‌بند (pager) است.

فایل‌ها (FILES)
       به صورت پیش‌فرض، git config گزینه‌های پیکربندی را از چندین فایل خواهد
       خواند:

       $(prefix)/etc/gitconfig
           فایل پیکربندی سراسری سیستم.

       $XDG_CONFIG_HOME/git/config, ~/.gitconfig
           فایل‌های پیکربندی مختص کاربر. هنگامی که متغیر محیطی XDG_CONFIG_HOME
           تنظیم نشده باشد یا خالی باشد، $HOME/.config/ به عنوان
           $XDG_CONFIG_HOME استفاده می‌شود.

           به این فایل‌ها همچنین فایل‌های پیکربندی «سراسری» (global) گفته می‌شود.
           اگر هر دو فایل وجود داشته باشند، هر دو فایل به ترتیبی که در بالا
           ذکر شد خوانده می‌شوند.

       $GIT_DIR/config
           فایل پیکربندی مختص مخزن.

       $GIT_DIR/config.worktree
           این فایل اختیاری است و تنها زمانی جستجو می‌شود که
           extensions.worktreeConfig در $GIT_DIR/config وجود داشته باشد.

       همچنین می‌توانید هنگام اجرای هر دستور گیت با استفاده از گزینه -c
       پارامترهای پیکربندی اضافی را مشخص کنید. برای جزئیات به git(1) مراجعه
       کنید.

       گزینه‌ها از تمام فایل‌های موجود از این میان خوانده خواهند شد. اگر فایل‌های
       پیکربندی سراسری کاربر یا سراسری سیستم وجود نداشته باشند یا غیرقابل
       خواندن باشند، نادیده گرفته می‌شوند. اگر فایل پیکربندی مخزن وجود نداشته
       باشد یا غیرقابل خواندن باشد، git config با یک کد خطای غیرصفر خارج خواهد
       شد. اگر فایل غیرقابل خواندن باشد پیام خطا صادر می‌شود، اما اگر وجود
       نداشته باشد پیامی صادر نمی‌شود.

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

       به صورت پیش‌فرض، گزینه‌ها تنها در فایل پیکربندی مختص مخزن نوشته می‌شوند.
       توجه داشته باشید که این موضوع بر گزینه‌هایی مانند set و unset نیز اثر
       می‌گذارد. git config در هر بار فقط یک فایل را تغییر خواهد داد.

       می‌توانید منابع پیکربندی قابل خواندن یا نوشتن را با مشخص کردن مسیر یک
       فایل با گزینه --file، یا با مشخص کردن یک محدوده پیکربندی با --system،
       --global، --local یا --worktree محدود کنید. برای اطلاعات بیشتر، بخش
       «گزینه‌ها (OPTIONS)» در بالا را ببینید.

محدوده‌ها (SCOPES)
       هر منبع پیکربندی درون یک محدوده (scope) پیکربندی قرار می‌گیرد. این
       محدوده‌ها عبارتند از:

       system
           $(prefix)/etc/gitconfig

       global
           $XDG_CONFIG_HOME/git/config

           ~/.gitconfig

       local
           $GIT_DIR/config

       worktree
           $GIT_DIR/config.worktree

       command
           متغیرهای محیطی GIT_CONFIG_{COUNT,KEY,VALUE} (بخش «متغیرهای محیطی
           (ENVIRONMENT)» در زیر را ببینید)

           گزینه -c

       به استثنای command، هر محدوده متناظر با یک گزینه خط فرمان است:
       --system، --global، --local، --worktree.

       هنگام خواندن گزینه‌ها، تعیین یک محدوده تنها گزینه‌ها را از فایل‌های درون
       آن محدوده می‌خواند. هنگام نوشتن گزینه‌ها، تعیین یک محدوده در فایل‌های درون
       آن محدوده خواهد نوشت (به جای فایل پیکربندی مختص مخزن). برای توضیحات
       کامل بخش «گزینه‌ها (OPTIONS)» در بالا را ببینید.

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

   پیکربندی محافظت‌شده (Protected configuration)
       پیکربندی محافظت‌شده به محدوده‌های system، global و command اشاره دارد. به
       دلایل امنیتی، گزینه‌های خاصی تنها زمانی رعایت می‌شوند که در پیکربندی
       محافظت‌شده مشخص شده باشند، و در غیر این صورت نادیده گرفته می‌شوند.

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

متغیرهای محیطی (ENVIRONMENT)
       GIT_CONFIG_GLOBAL, GIT_CONFIG_SYSTEM
           پیکربندی را به جای پیکربندی در سطح سراسری (global) یا سطح سیستم
           (system) از فایل‌های داده‌شده دریافت می‌کند. برای جزئیات به git(1)
           مراجعه کنید.

       GIT_CONFIG_NOSYSTEM
           اینکه آیا خواندن تنظیمات از فایل سراسری سیستم
           $(prefix)/etc/gitconfig نادیده گرفته شود یا خیر. برای جزئیات به
           git(1) مراجعه کنید.

       همچنین بخش «فایل‌ها (FILES)» را ببینید.

       GIT_CONFIG_COUNT, GIT_CONFIG_KEY_<n>, GIT_CONFIG_VALUE_<n>
           اگر GIT_CONFIG_COUNT روی یک عدد مثبت تنظیم شده باشد، تمام جفت‌های
           محیطی GIT_CONFIG_KEY_<n> و GIT_CONFIG_VALUE_<n> تا آن عدد به
           پیکربندی زمان اجرای فرایند اضافه خواهند شد. جفت‌های پیکربندی با
           اندیس صفر شروع می‌شوند. هر کلید یا مقدار مفقود به عنوان یک خطا در
           نظر گرفته می‌شود. یک GIT_CONFIG_COUNT خالی همانند GIT_CONFIG_COUNT=0
           در نظر گرفته می‌شود، یعنی هیچ جفتی پردازش نخواهد شد. این متغیرهای
           محیطی مقادیر موجود در فایل‌های پیکربندی را بازنویسی (override)
           خواهند کرد، اما توسط هر گزینه صریحی که از طریق git -c ارسال شود
           بازنویسی می‌شوند.

           این متغیر برای مواردی مفید است که می‌خواهید چندین دستور گیت را با یک
           پیکربندی مشترک اجرا کنید اما نمی‌توانید به یک فایل پیکربندی وابسته
           باشید، برای مثال هنگام نوشتن اسکریپت‌ها.

       GIT_CONFIG
           اگر هیچ گزینه --file به git config ارائه نشود، از فایل ارائه‌شده
           توسط GIT_CONFIG به گونه‌ای استفاده می‌کند که گویی از طریق --file
           ارائه شده است. این متغیر هیچ اثری بر سایر دستورات گیت ندارد و عمدتاً
           برای سازگاری گذشته حفظ شده است؛ به طور کلی هیچ دلیلی برای استفاده
           از آن به جای گزینه --file وجود ندارد.

مثال‌ها (EXAMPLES)
       با فرض یک فایل .git/config مانند این:

           #
           # This is the config file, and
           # a '#' or ';' character indicates
           # a comment
           #

           ; core variables
           [core]
                   ; Don't trust file modes
                   filemode = false

           ; Our diff algorithm
           [diff]
                   external = /usr/local/bin/diff-wrapper
                   renames = true

           ; Proxy settings
           [core]
                   gitproxy=proxy-command for kernel.org
                   gitproxy=default-proxy ; for all the rest

           ; HTTP
           [http]
                   sslVerify
           [http "https://weak.example.com"]
                   sslVerify = false
                   cookieFile = /tmp/cookie.txt


       می‌توانید filemode را با دستور زیر روی true تنظیم کنید:

           % git config set core.filemode true


       مدخل‌های فرضی دستور پروکسی در واقع دارای یک پسوند هستند تا مشخص شود برای
       چه URL اعمال می‌شوند. در اینجا نحوه تغییر مدخل برای kernel.org به "ssh"
       آمده است:

           % git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'


       این کار اطمینان حاصل می‌کند که تنها جفت کلید/مقدار مربوط به kernel.org
       جایگزین شود.

       برای حذف مدخل renames، این دستور را اجرا کنید:

           % git config unset diff.renames


       اگر می‌خواهید مدخلی را برای یک متغیر چندمقداری (مانند core.gitproxy در
       بالا) حذف کنید، باید یک عبارت منظم ارائه دهید که دقیقاً با مقدار یک خط
       مطابقت داشته باشد.

       برای پرس‌وجوی مقدار یک کلید مشخص، این دستور را اجرا کنید:

           % git config get core.filemode


       یا، برای پرس‌وجوی یک متغیر چندمقداری:

           % git config get --value="for kernel.org$" core.gitproxy


       اگر می‌خواهید تمام مقادیر یک متغیر چندمقداری را بدانید، دستور زیر را
       اجرا کنید:

           % git config get --all --show-names core.gitproxy


       اگر اهل ریسک هستید، می‌توانید تمام مقادیر core.gitproxy را با یک مقدار
       جدید جایگزین کنید:

           % git config set --all core.gitproxy ssh


       با این حال، اگر واقعاً فقط می‌خواهید خط مربوط به پروکسی پیش‌فرض را جایگزین
       کنید، یعنی خطی که پسوند "for ..." ندارد، کاری شبیه به این انجام دهید:

           % git config set --value='! for ' core.gitproxy ssh


       برای تطبیق واقعی تنها مقادیری که دارای علامت تعجب هستند، باید به این
       صورت عمل کنید:

           % git config set --value='[!]' section.key value


       برای افزودن یک پروکسی جدید، بدون تغییر هیچ‌یک از گزینه‌های موجود، از این
       دستور استفاده کنید:

           % git config set --append core.gitproxy '"proxy-command" for example.com'


       یک مثال برای استفاده از رنگ سفارشی‌شده از پیکربندی در اسکریپت شما:

           #!/bin/sh
           WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
           RESET=$(git config get --type=color --default="reset" "")
           echo "${WS}your whitespace color or blue reverse${RESET}"


       برای نشانی‌های وب در https://weak.example.com، مقدار http.sslVerify روی
       false تنظیم شده است، در حالی که برای سایر نشانی‌ها روی true تنظیم شده
       است:

           % git config get --type=bool --url=https://good.example.com http.sslverify
           true
           % git config get --type=bool --url=https://weak.example.com http.sslverify
           false
           % git config get --url=https://weak.example.com http
           http.cookieFile /tmp/cookie.txt
           http.sslverify false


فایل پیکربندی (CONFIGURATION FILE)
       فایل پیکربندی گیت شامل تعدادی متغیر است که بر رفتار دستورات گیت تأثیر
       می‌گذارند. فایل‌های .git/config و به صورت اختیاری config.worktree (بخش
       "CONFIGURATION FILE" از git-worktree(1) را ببینید) در هر مخزن برای
       ذخیره پیکربندی آن مخزن استفاده می‌شوند، و $HOME/.gitconfig برای ذخیره یک
       پیکربندی به ازای هر کاربر به عنوان مقادیر پشتیبان برای فایل .git/config
       استفاده می‌شود. فایل /etc/gitconfig می‌تواند برای ذخیره یک پیکربندی
       پیش‌فرض در سطح سیستم استفاده شود.

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

   قواعد نحوی (Syntax)
       قواعد نحوی نسبتاً انعطاف‌پذیر و آسان‌گیرانه است. نویسه‌های فاصله سفید، که
       در این زمینه شامل نویسه فاصله (SP) و تب افقی (HT) هستند، عمدتاً نادیده
       گرفته می‌شوند. نویسه‌های # و ; آغازگر توضیحات تا پایان خط هستند. خطوط
       خالی نادیده گرفته می‌شوند.

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

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

                   [section "subsection"]


       نام‌های زیربخش‌ها به حروف بزرگ و کوچک حساس هستند و می‌توانند شامل هر
       نویسه‌ای به جز خط جدید و بایت تهی (null) باشند. گیومه دوتایی " و بک‌اسلش
       را می‌توان به ترتیب با اسکیپ کردن آن‌ها به صورت \" و \\ گنجاند. بک‌اسلش‌های
       قبل از سایر نویسه‌ها هنگام خواندن حذف می‌شوند؛ برای مثال، \t به صورت t و
       \0 به صورت 0 خوانده می‌شود. سربرگ‌های بخش نمی‌توانند در چندین خط امتداد
       یابند. متغیرها ممکن است مستقیماً به یک بخش یا به یک زیربخش مشخص تعلق
       داشته باشند. در صورت داشتن [section "subsection"] می‌توانید [section] را
       نیز داشته باشید، اما الزامی به آن نیست.

       همچنین یک نحو منسوخ‌شده [section.subsection] وجود دارد. با این نحو، نام
       زیربخش به حروف کوچک تبدیل شده و همچنین به صورت حساس به حروف بزرگ و کوچک
       مقایسه می‌شود. این نام‌های زیربخش از همان محدودیت‌های نام‌های بخش پیروی
       می‌کنند.

       تمام خطوط دیگر (و باقی‌مانده خط پس از سربرگ بخش) به عنوان متغیرهای
       تنظیم‌کننده شناخته می‌شوند، به شکل name = value (یا صرفاً name که یک
       میان‌بر برای بیان این است که متغیر دارای مقدار بولی "true" است). نام‌های
       متغیرها به حروف بزرگ و کوچک حساس نیستند، تنها نویسه‌های الفبایی-عددی و -
       را مجاز می‌دانند، و باید با یک نویسه الفبایی آغاز شوند.

       نویسه‌های فاصله سفید در اطراف name، = و value دور ریخته می‌شوند. فاصله‌های
       سفید داخلی درون value عیناً حفظ می‌شوند. توضیحاتی که با # یا ; شروع شده و
       تا پایان خط امتداد می‌یابند دور ریخته می‌شوند. خطی که مقداری را تعریف
       می‌کند می‌تواند با پایان یافتن با یک بک‌اسلش (\) به خط بعدی ادامه یابد؛
       بک‌اسلش و نویسه‌های پایان خط دور ریخته می‌شوند.

       اگر value نیاز دارد که دارای نویسه‌های فاصله سفید ابتدایی یا انتهایی
       باشد، باید در گیومه دوتایی (") محصور شود. در داخل گیومه دوتایی،
       نویسه‌های گیومه دوتایی (") و بک‌اسلش (\) باید اسکیپ شوند: از \" برای " و
       \\ برای \ استفاده کنید.

       توالی‌های گریز زیر (علاوه بر \" و \\) شناخته شده‌اند: \n برای نویسه خط
       جدید (NL)، \t برای تب افقی (HT, TAB) و \b برای پس‌بر (BS). سایر توالی‌های
       گریز نویسه (شامل توالی‌های گریز هشت‌هشتی) نامعتبر هستند.

   درج‌ها (Includes)
       بخش‌های include و includeIf به شما امکان می‌دهند دستورالعمل‌های پیکربندی
       را از منبع دیگری درج کنید. این بخش‌ها عملکرد یکسانی با یکدیگر دارند با
       این استثنا که بخش‌های includeIf ممکن است در صورتی که شرط آن‌ها به true
       ارزیابی نشود نادیده گرفته شوند؛ بخش «درج‌های مشروط (Conditional
       includes)» در زیر را ببینید.

       می‌توانید با تنظیم متغیر ویژه include.path (یا includeIf.*.path) به نام
       فایلی که قرار است درج شود، یک فایل پیکربندی را از فایل دیگری درج کنید.
       این متغیر یک نام مسیر را به عنوان مقدار خود می‌پذیرد و مشمول گسترش مد
       (tilde expansion) است. این متغیرها را می‌توان چندین بار مشخص کرد.

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

   درج‌های مشروط (Conditional includes)
       می‌توانید با تنظیم یک متغیر includeIf.<condition>.path به نام فایلی که
       قرار است درج شود، یک فایل پیکربندی را به صورت مشروط از فایل دیگری درج
       کنید.

       شرط با یک کلمه کلیدی آغاز می‌شود و به دنبال آن یک دونقطه (:) و سپس
       داده‌هایی قرار می‌گیرد که قالب و معنای آن‌ها به کلمه کلیدی بستگی دارد.
       کلمات کلیدی پشتیبانی‌شده عبارتند از:

       gitdir
           داده‌هایی که بعد از کلمه کلیدی gitdir و دونقطه می‌آیند به عنوان یک
           الگوی تطبیق مسیر (glob) استفاده می‌شوند. اگر مکان دایرکتوری .git با
           این الگو مطابقت داشته باشد، شرط درج برآورده می‌شود.

           مکان .git ممکن است به صورت خودکار شناسایی شود یا از متغیر محیطی
           $GIT_DIR به دست آید. اگر مخزن از طریق یک فایل .git شناسایی شود
           (برای مثال از زیرماژول‌ها یا یک درخت کاری پیوند داده‌شده)، مکان .git
           مکان نهایی خواهد بود که دایرکتوری .git در آن قرار دارد، نه مکانی که
           فایل .git در آن است.

           الگو می‌تواند شامل نویسه‌های عام استاندارد globbing و دو نویسه اضافی،
           **/ و /** باشد که می‌توانند چندین جزء مسیر را مطابقت دهند. لطفاً برای
           جزئیات به gitignore(5) مراجعه کنید. جهت سهولت:

           •   اگر الگو با ~/ آغاز شود، ~ با محتوای متغیر محیطی HOME جایگزین
               خواهد شد.

           •   اگر الگو با ./ آغاز شود، با دایرکتوری حاوی فایل پیکربندی فعلی
               جایگزین می‌شود.

           •   اگر الگو با هیچ‌کدام از ~/، ./ یا / آغاز نشود، **/ به صورت
               خودکار به ابتدای آن اضافه خواهد شد. برای مثال، الگوی foo/bar
               تبدیل به **/foo/bar می‌شود و با /any/path/to/foo/bar مطابقت
               خواهد داشت.

           •   اگر الگو با / پایان یابد، ** به صورت خودکار اضافه خواهد شد.
               برای مثال، الگوی foo/ تبدیل به foo/** می‌شود. به عبارت دیگر، با
               "foo" و هر آنچه در داخل آن است به صورت بازگشتی مطابقت خواهد
               داشت.

       gitdir/i
           این مورد همانند gitdir است، به جز اینکه تطبیق بدون حساسیت به حروف
           بزرگ و کوچک انجام می‌شود (برای مثال در سیستم‌های فایلی غیرحساس به
           حروف).

       onbranch
           داده‌هایی که بعد از کلمه کلیدی onbranch و دونقطه می‌آیند به عنوان
           الگویی با نویسه‌های عام استاندارد globbing و دو نویسه اضافی، **/ و
           /** در نظر گرفته می‌شوند که می‌توانند چندین جزء مسیر را مطابقت دهند.
           اگر در یک درخت کاری باشیم که در آن نام شاخه فعلی چک‌اوت‌شده با الگو
           مطابقت داشته باشد، شرط درج برآورده می‌شود.

           اگر الگو با / پایان یابد، ** به صورت خودکار اضافه خواهد شد. برای
           مثال، الگوی foo/ تبدیل به foo/** می‌شود. به عبارت دیگر، با تمام
           شاخه‌هایی که با foo/ آغاز می‌شوند مطابقت دارد. این مورد زمانی مفید
           است که شاخه‌های شما به صورت سلسله‌مراتبی سازماندهی شده باشند و
           بخواهید یک پیکربندی را برای تمام شاخه‌ها در آن سلسله‌مراتب اعمال
           کنید.

       hasconfig:remote.*.url
           داده‌هایی که بعد از این کلمه کلیدی و دونقطه می‌آیند به عنوان الگویی
           با نویسه‌های عام استاندارد globbing و دو نویسه اضافی، **/ و /** در
           نظر گرفته می‌شوند که می‌توانند چندین جزء را مطابقت دهند. نخستین باری
           که این کلمه کلیدی دیده شود، باقی‌مانده فایل‌های پیکربندی برای یافتن
           URLهای ریموت اسکن خواهند شد (بدون اعمال هیچ‌گونه مقداری). اگر حداقل
           یک URL ریموت وجود داشته باشد که با این الگو مطابقت کند، شرط درج
           برآورده می‌شود.

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

           توجه داشته باشید که برخلاف سایر شرایط includeIf، حل این شرط متکی بر
           اطلاعاتی است که در زمان خواندن شرط هنوز مشخص نیست. یک مورد استفاده
           معمول این است که این گزینه در یک پیکربندی سطح سیستم یا سطح سراسری
           وجود داشته باشد، و URL ریموت در یک پیکربندی سطح محلی باشد؛ از این
           رو هنگام حل این شرط نیاز به پیش‌اسکن است. به منظور اجتناب از مسئله
           «مرغ و تخم‌مرغ» که در آن فایل‌های به طور بالقوه درج‌شده می‌توانند بر
           اینکه آیا چنین فایل‌هایی به طور بالقوه درج می‌شوند یا خیر اثر
           بگذارند، گیت با منع این فایل‌ها از اثرگذاری بر حل این شرایط (و در
           نتیجه منع آن‌ها از اعلان URLهای ریموت)، این چرخه را می‌شکند.

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

       چند نکته بیشتر در مورد تطبیق از طریق gitdir و gitdir/i:

       •   پیوندهای نمادین (Symlinks) در $GIT_DIR پیش از تطبیق حل نمی‌شوند.

       •   هر دو نسخه پیوند نمادین و مسیر واقعی (realpath) در خارج از $GIT_DIR
           مطابقت داده خواهند شد. برای مثال اگر git/~ یک پیوند نمادین به
           mnt/storage/git/ باشد، هر دو gitdir:~/git و gitdir:/mnt/storage/git
           مطابقت خواهند داشت.

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

       •   توجه داشته باشید که "../" خاص نیست و به صورت لفظی مطابقت داده خواهد
           شد، که احتمالاً چیزی نیست که شما می‌خواهید.

   مثال (Example)
           # Core variables
           [core]
                   ; Don't trust file modes
                   filemode = false

           # Our diff algorithm
           [diff]
                   external = /usr/local/bin/diff-wrapper
                   renames = true

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

           # Proxy settings
           [core]
                   gitProxy="ssh" for "kernel.org"
                   gitProxy=default-proxy ; for the rest

           [include]
                   path = /path/to/foo.inc ; include by absolute path
                   path = foo.inc ; find "foo.inc" relative to the current file
                   path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory

           ; include if $GIT_DIR is /path/to/foo/.git
           [includeIf "gitdir:/path/to/foo/.git"]
                   path = /path/to/foo.inc

           ; include for all repositories inside /path/to/group
           [includeIf "gitdir:/path/to/group/"]
                   path = /path/to/foo.inc

           ; include for all repositories inside $HOME/to/group
           [includeIf "gitdir:~/to/group/"]
                   path = /path/to/foo.inc

           ; relative paths are always relative to the including
           ; file (if the condition is true); their location is not
           ; affected by the condition
           [includeIf "gitdir:/path/to/group/"]
                   path = foo.inc

           ; include only if we are in a worktree where foo-branch is
           ; currently checked out
           [includeIf "onbranch:foo-branch"]
                   path = foo.inc

           ; include only if a remote with the given URL exists (note
           ; that such a URL may be provided later in a file or in a
           ; file read after this file is read, as seen in this example)
           [includeIf "hasconfig:remote.*.url:https://example.com/**"]
                   path = foo.inc
           [remote "origin"]
                   url = https://example.com/git


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

       boolean
           هنگامی که گفته می‌شود یک متغیر مقدار بولی (boolean) می‌پذیرد،
           مترادف‌های متعددی برای true و false پذیرفته می‌شوند؛ تمامی این موارد
           غیرحساس به حروف بزرگ و کوچک هستند.

           true
               مقدارهای لیترال برای true بولی عبارتند از yes، on، true و 1.
               همچنین، متغیری که بدون = <value> تعریف شود به عنوان true در نظر
               گرفته می‌شود.

           false
               مقدارهای لیترال برای false بولی عبارتند از no، off، false، 0 و
               رشته خالی.

           هنگام تبدیل یک مقدار به شکل استاندارد آن با استفاده از مشخص‌کننده
           نوع --type=bool، git config اطمینان حاصل خواهد کرد که خروجی "true"
           یا "false" باشد (نوشته‌شده با حروف کوچک).

       integer
           مقدار بسیاری از متغیرها که اندازه‌های مختلف را مشخص می‌کنند می‌تواند
           با پسوندهای k، M و غیره همراه باشد تا به معنای «مقیاس‌بندی عدد در
           1024»، «در 1024x1024» و غیره باشد.

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

           رنگ‌های پایه‌ای پذیرفته‌شده عبارتند از normal، black، red، green،
           yellow، blue، magenta، cyan، white و default. اولین رنگ داده‌شده
           برای پیش‌زمینه و دومین رنگ برای پس‌زمینه است. تمام رنگ‌های پایه به جز
           normal و default دارای یک حالت روشن (bright) هستند که می‌توان با
           افزودن پیشوند bright به رنگ، مانند brightred، آن‌ها را مشخص کرد.

           رنگ normal هیچ تغییری در رنگ ایجاد نمی‌کند. این رنگ همانند یک رشته
           خالی است، اما می‌توان از آن به عنوان رنگ پیش‌زمینه در هنگام مشخص کردن
           رنگ پس‌زمینه به تنهایی استفاده کرد (برای مثال، "normal red").

           رنگ default به طور صریح رنگ را به حالت پیش‌فرض ترمینال بازنشانی
           می‌کند، برای مثال برای مشخص کردن یک پس‌زمینه پاک‌شده. اگرچه این مورد
           بین ترمینال‌ها متفاوت است، اما معمولاً مشابه تنظیم روی "white black"
           نیست.

           رنگ‌ها همچنین می‌توانند به عنوان اعدادی بین 0 تا 255 داده شوند؛ این
           رنگ‌ها از حالت 256 رنگی ANSI استفاده می‌کنند (اما توجه داشته باشید که
           ممکن است همه ترمینال‌ها از آن پشتیبانی نکنند). اگر ترمینال شما
           پشتیبانی کند، می‌توانید مقادیر RGB بیست‌وچهار بیتی را نیز به صورت
           هگزادسیمال مشخص کنید، مانند #ff0ab3، یا مقادیر RGB دوازده بیتی
           مانند #f1b که معادل رنگ 24 بیتی #ff11bb است.

           ویژگی‌های پذیرفته‌شده عبارتند از bold، dim، ul، blink، reverse،
           italic و strike (برای خط‌خورده یا حروفی با خط روی آن‌ها). موقعیت هر
           ویژگی نسبت به رنگ‌ها (قبل، بعد یا در بین آن‌ها) اهمیتی ندارد.
           ویژگی‌های خاص را می‌توان با افزودن پیشوند no یا no- (مانند noreverse،
           no-ul و غیره) غیرفعال کرد.

           شبه‌ویژگی reset تمام رنگ‌ها و ویژگی‌ها را پیش از اعمال رنگ‌آمیزی
           مشخص‌شده بازنشانی می‌کند. برای مثال، reset green باعث یک پیش‌زمینه سبز
           و پس‌زمینه پیش‌فرض بدون هیچ ویژگی فعالی خواهد شد.

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

           برای جایگاه‌های رنگی پیش‌تعریف‌شده در گیت، ویژگی‌ها به گونه‌ای در نظر
           گرفته شده‌اند که در ابتدای هر مورد در خروجی رنگی بازنشانی شوند.
           بنابراین تنظیم color.decorate.branch روی black آن نام شاخه را به
           رنگ ساده black درمی‌آورد، حتی اگر مورد قبلی در همان خط خروجی (مانند
           پرانتز بازکننده قبل از فهرست نام‌های شاخه‌ها در خروجی log --decorate)
           تنظیم شده باشد که با bold یا ویژگی دیگری رنگ‌آمیزی شود. با این حال،
           قالب‌های سفارشی لاگ ممکن است رنگ‌آمیزی‌های پیچیده‌تر و لایه‌بندی‌شده‌ای
           انجام دهند و حالت‌های منفی‌شده ممکن است در آنجا مفید باشند.

       pathname
           به متغیری که مقدار pathname (نام مسیر) را می‌پذیرد می‌توان رشته‌ای داد
           که با "~/" یا "~user/" آغاز می‌شود، و گسترش معمولی مد (tilde) برای
           چنین رشته‌ای رخ می‌دهد: ~/ به مقدار $HOME و ~user/ به دایرکتوری خانگی
           کاربر مشخص‌شده گسترش می‌یابد.

           اگر یک مسیر با %(prefix)/ آغاز شود، باقی‌مانده آن به عنوان یک مسیر
           نسبی به «پیشوند زمان اجرا» (runtime prefix) گیت، یعنی نسبت به مکانی
           که گیت در آن نصب شده است، تفسیر می‌شود. برای مثال، %(prefix)/bin/ به
           دایرکتوری‌ای اشاره دارد که فایل اجرایی گیت در آن قرار دارد. اگر گیت
           بدون پشتیبانی از پیشوند زمان اجرا کامپایل شده باشد، پیشوند
           کامپایل‌شده به جای آن جایگزین خواهد شد. در صورت نادری که نیاز باشد
           یک مسیر لفظی مشخص شود که نباید not گسترش یابد، لازم است پیشوند ./
           به آن اضافه شود، مانند: ./%(prefix)/bin.

           اگر با پیشوند :(optional) همراه باشد، در صورتی که مسیر نام‌برده وجود
           نداشته باشد، با متغیر پیکربندی به گونه‌ای رفتار می‌شود که گویی وجود
           ندارد.

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

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

       add.ignoreErrors, add.ignore-errors (منسوخ‌شده)
           به git add می‌گوید زمانی که برخی از فایل‌ها به دلیل خطاهای
           ایندکس‌گذاری قابل افزودن نیستند، به افزودن فایل‌ها ادامه دهد. معادل
           گزینه --ignore-errors در git-add(1).  add.ignore-errors منسوخ شده
           است، زیرا از قرارداد نام‌گذاری معمول برای متغیرهای پیکربندی پیروی
           نمی‌کند.

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

           از آنجا که این پیام‌ها برای کمک به کاربران انسانی در نظر گرفته
           شده‌اند، در خروجی خطای استاندارد (standard error) چاپ می‌شوند. هنگامی
           که ابزارهایی که Git را به عنوان یک زیرفرآیند اجرا می‌کنند آن‌ها را
           مخل می‌دانند، می‌توانند GIT_ADVICE=0 را در محیط تنظیم کنند تا تمام
           پیام‌های راهنما بی‌صدا شوند.

           addEmbeddedRepo
               زمانی نشان داده می‌شود که کاربر به طور تصادفی یک مخزن گیت را
               درون مخزن دیگری اضافه می‌کند.

           addEmptyPathspec
               زمانی نشان داده می‌شود که کاربر git add را بدون ارائه پارامتر
               مشخصه مسیر (pathspec) اجرا می‌کند.

           addIgnoredFile
               زمانی نشان داده می‌شود که کاربر تلاش می‌کند فایلی نادیده‌گرفته‌شده
               (ignored) را به ایندکس اضافه کند.

           amWorkDir
               زمانی نشان داده می‌شود که git-am(1) در اعمال یک فایل وصله ناموفق
               است، تا مکان فایل را به کاربر اطلاع دهد.

           ambiguousFetchRefspec
               زمانی نشان داده می‌شود که یک مشخصه مرجع واکشی (fetch refspec)
               برای چند ریموت به همان فضای نام شاخه ردیابی ریموت
               (remote-tracking branch) نگاشت می‌شود و باعث شکست در راه‌اندازی
               ردیابی شاخه می‌گردد.

           checkoutAmbiguousRemoteBranchName
               زمانی نشان داده می‌شود که آرگومان داده‌شده به git-checkout(1) و
               git-switch(1) به طور مبهم به یک شاخه ردیابی ریموت در بیش از یک
               ریموت حل‌وفصل می‌شود، در شرایطی که یک آرگومان غیرمبهم در غیر این
               صورت باعث تحویل گرفتن (checkout) یک شاخه ردیابی ریموت می‌شد.
               برای چگونگی تنظیم یک ریموت معین برای استفاده پیش‌فرض در برخی
               شرایطی که این راهنما چاپ می‌شود، متغیر پیکربندی
               checkout.defaultRemote را ببینید.

           commitBeforeMerge
               زمانی نشان داده می‌شود که git-merge(1) برای جلوگیری از رونویسی
               تغییرات محلی، از ادغام خودداری می‌کند.

           detachedHead
               زمانی نشان داده می‌شود که کاربر از git-switch(1) یا git-
               checkout(1) برای رفتن به وضعیت HEAD جداشده (detached HEAD)
               استفاده می‌کند، تا نحوه ایجاد یک شاخه محلی را پس از وقوع به
               کاربر بگوید.

           diverging
               زمانی نشان داده می‌شود که فوروارد سریع (fast-forward) امکان‌پذیر
               نیست.

           fetchShowForcedUpdates
               زمانی نشان داده می‌شود که git-fetch(1) زمان زیادی را صرف محاسبه
               به‌روزرسانی‌های اجباری پس از به‌روزرسانی مراجع می‌کند، یا برای
               هشدار دادن درباره اینکه این بررسی غیرفعال است.

           forceDeleteBranch
               زمانی نشان داده می‌شود که کاربر تلاش می‌کند شاخه‌ای را که به طور
               کامل ادغام نشده است بدون تنظیم گزینه اجبار (force) حذف کند.

           ignoredHook
               زمانی نشان داده می‌شود که یک هوک نادیده گرفته می‌شود زیرا به
               عنوان قابل اجرا تنظیم نشده است.

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

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

           nestedTag
               زمانی نشان داده می‌شود که کاربر تلاش می‌کند به طور بازگشتی روی یک
               شیء تگ، تگ بزند.

           pushAlreadyExists
               زمانی نشان داده می‌شود که git-push(1) به‌روزرسانی‌ای را که شرایط
               فوروارد سریع را ندارد رد می‌کند (مانند یک تگ).

           pushFetchFirst
               زمانی نشان داده می‌شود که git-push(1) به‌روزرسانی‌ای را که سعی
               دارد یک مرجع ریموت اشاره‌کننده به شیئی را که ما نداریم رونویسی
               کند، رد می‌نماید.

           pushNeedsForce
               زمانی نشان داده می‌شود که git-push(1) به‌روزرسانی‌ای را که قصد
               دارد یک مرجع ریموت اشاره‌کننده به شیئی غیر از شبه‌کامیت
               (commit-ish) را رونویسی کند، یا باعث شود مرجع ریموت به شیئی که
               شبه‌کامیت نیست اشاره کند، رد می‌نماید.

           pushNonFFCurrent
               زمانی نشان داده می‌شود که git-push(1) به دلیل به‌روزرسانی غیر
               فوروارد سریع (non-fast-forward) در شاخه فعلی با شکست مواجه
               می‌شود.

           pushNonFFMatching
               زمانی نشان داده می‌شود که کاربر git-push(1) را اجرا کرده و مراجع
               منطبق («matching refs») را به صراحت ارسال نموده است (یعنی از :
               استفاده کرده، یا مشخصه مرجعی را تعیین نموده که شاخه فعلی نیست)
               و این کار منجر به خطای غیر فوروارد سریع شده است.

           pushRefNeedsUpdate
               زمانی نشان داده می‌شود که git-push(1) به‌روزرسانی اجباری یک شاخه
               را رد می‌کند هنگامی که مرجع ردیابی ریموت آن دارای به‌روزرسانی‌هایی
               است که ما به صورت محلی نداریم.

           pushUnqualifiedRefname
               زمانی نشان داده می‌شود که git-push(1) از تلاش برای حدس زدن فضای
               نام مرجع ریموتی که مبدأ به آن تعلق دارد بر اساس مراجع مبدأ و
               مقصد منصرف می‌شود، اما در جایی که هنوز می‌توانیم بر اساس نوع شیء
               مبدأ به کاربر پیشنهاد دهیم که به refs/heads/* یا refs/tags/*
               ارسال کند.

           pushUpdateRejected
               این متغیر را روی false تنظیم کنید اگر می‌خواهید
               pushNonFFCurrent، pushNonFFMatching، pushAlreadyExists،
               pushFetchFirst، pushNeedsForce و pushRefNeedsUpdate را به طور
               همزمان غیرفعال کنید.

           rebaseTodoError
               زمانی نشان داده می‌شود که پس از ویرایش فهرست کارهای بازسازی
               (rebase todo list) خطایی رخ دهد.

           refSyntax
               زمانی نشان داده می‌شود که کاربر یک نام مرجع نامعتبر ارائه دهد،
               تا کاربر را از مستندات نحو مرجع مطلع کند.

           resetNoRefresh
               زمانی نشان داده می‌شود که git-reset(1) برای بازخوانی ایندکس پس
               از ریست بیش از ۲ ثانیه طول می‌کشد، تا به کاربر بگوید می‌تواند از
               گزینه --no-refresh استفاده کند.

           resolveConflict
               توسط دستورات مختلف زمانی نشان داده می‌شود که تعارض‌ها مانع از
               انجام عملیات می‌شوند.

           rmHints
               هنگام شکست در خروجی git-rm(1) نشان داده می‌شود تا راهنمایی‌هایی
               درباره نحوه ادامه کار از وضعیت فعلی ارائه دهد.

           sequencerInUse
               زمانی نشان داده می‌شود که یک دستور توالی‌ساز (sequencer) در حال
               حاضر در حال اجرا است.

           skippedCherryPicks
               زمانی نشان داده می‌شود که git-rebase(1) کامیتی را که قبلاً به
               صورت گلچین (cherry-pick) بر روی شاخه بالادست اعمال شده نادیده
               می‌گیرد.

           sparseIndexExpanded
               زمانی نشان داده می‌شود که یک ایندکس پراکنده (sparse index) به یک
               ایندکس کامل گسترش می‌یابد، که احتمالاً به دلیل وجود مجموعه‌ای
               غیرمنتظره از فایل‌ها در خارج از تحویل پراکنده (sparse-checkout)
               است.

           statusAheadBehind
               زمانی نشان داده می‌شود که git-status(1) تعداد جلو/عقب بودن
               (ahead/behind) یک مرجع محلی را در مقایسه با مرجع ردیابی ریموت
               آن محاسبه می‌کند و این محاسبه بیش از حد انتظار طول می‌کشد. اگر
               status.aheadBehind روی false باشد یا گزینه --no-ahead-behind
               داده شود ظاهر نخواهد شد.

           statusHints
               راهنمایی‌هایی درباره نحوه ادامه کار از وضعیت فعلی را در خروجی
               git-status(1)، در الگوی نمایش داده‌شده هنگام نوشتن پیام کامیت در
               git-commit(1)، و در پیام راهنمای نمایش داده‌شده توسط git-
               switch(1) یا git-checkout(1) هنگام جابجایی شاخه‌ها نمایش می‌دهد.

           statusUoption
               زمانی نشان داده می‌شود که git-status(1) برای شمارش فایل‌های
               ردیابی‌نشده بیش از ۲ ثانیه طول می‌کشد، تا به کاربر بگوید می‌تواند
               از گزینه -u استفاده کند.

           submoduleAlternateErrorStrategyDie
               زمانی نشان داده می‌شود که تنظیم گزینه
               submodule.alternateErrorStrategy روی «die» باعث بروز یک خطای
               مهلک (fatal) می‌شود.

           submoduleMergeConflict
               راهنمایی نمایش‌داده‌شده هنگام مواجهه با یک تعارض ادغام زیرماژول
               غیربدیهی.

           submodulesNotUpdated
               زمانی نشان داده می‌شود که کاربر دستور زیرماژولی را اجرا می‌کند که
               به دلیل عدم اجرای git submodule update --init با شکست مواجه
               می‌شود.

           suggestDetachingHead
               زمانی نشان داده می‌شود که git-switch(1) از جدا کردن HEAD بدون
               گزینه صریح --detach خودداری می‌کند.

           updateSparsePath
               زمانی نشان داده می‌شود که از git-add(1) یا git-rm(1) خواسته
               می‌شود ورودی‌های ایندکس خارج از تحویل پراکنده (sparse checkout)
               فعلی را به‌روزرسانی کنند.

           waitingForEditor
               زمانی نشان داده می‌شود که Git منتظر ورودی ویرایشگر است. به عنوان
               مثال زمانی کاربرد دارد که ویرایشگر در داخل ترمینال اجرا نمی‌شود.

           worktreeAddOrphan
               زمانی نشان داده می‌شود که کاربر تلاش می‌کند یک درخت کاری
               (worktree) را از روی یک مرجع نامعتبر ایجاد کند، تا به کاربر
               بگوید چگونه به جای آن یک شاخه متولدنشده (unborn) جدید ایجاد
               کند.

       alias.*, alias.*.command
           نام‌های مستعار دستور برای بسته‌بند دستور git(1).  نام‌های مستعار را
           می‌توان با استفاده از دو نحو تعریف کرد:

            1. بدون زیربخش (subsection)، برای مثال: [alias] co = checkout.
               نام مستعار (در این مثال «co») به نویسه‌های الفبایی-عددی ASCII و
               - محدود است و بدون حساسیت به حروف بزرگ و کوچک مطابقت داده
               می‌شود.

            2. با یک زیربخش، برای مثال: [alias "co"] command = checkout.  نام
               مستعار می‌تواند شامل هر نویسه‌ای (به جز خط جدید و بایت‌های NUL)
               باشد، از جمله UTF-8، و به صورت بایت‌های خام و با حساسیت به حروف
               بزرگ و کوچک مطابقت داده می‌شود. شما عمل نام مستعار را در command
               تعریف می‌کنید.

           مثال‌ها:

               # Without subsection (ASCII alphanumeric and dash only)
               [alias]
                   co = checkout
                   st = status

               # With subsection (allows any characters, including UTF-8)
               [alias "hämta"]
                   command = fetch
               [alias "rätta till"]
                   command = commit --amend

           با تعریف یک نام مستعار گیت، به عنوان مثال:

               $ git config --global alias.last "cat-file commit HEAD"
               # Which is equivalent to
               $ git config --global alias.last.command "cat-file commit HEAD"

           دستور git last معادل است با git cat-file commit HEAD.

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

           توجه داشته باشید که کلمه اول یک نام مستعار لزوماً نباید یک دستور
           باشد. می‌تواند یک گزینه خط فرمان باشد که به فراخوانی git ارسال
           می‌شود. به ویژه، این قابلیت هنگام استفاده با -c برای ارسال
           پیکربندی‌های یک‌باره یا -p برای اجبار به صفحه‌بندی خروجی مفید است.
           برای مثال، loud-rebase = -c commit.verbose=true rebase را می‌توان
           طوری تعریف کرد که اجرای git loud-rebase معادل با git -c
           commit.verbose=true rebase باشد. همچنین، ps = -p status یک نام
           مستعار مفید خواهد بود، زیرا git ps خروجی git status را صفحه‌بندی
           می‌کند در حالی که دستور اصلی این کار را انجام نمی‌دهد.

           اگر ابتدای بسط نام مستعار با یک علامت تعجب همراه باشد، به عنوان یک
           دستور شل در نظر گرفته می‌شود. برای مثال، با تعریف alias.new = !gitk
           --all --not ORIG_HEAD، فراخوانی git new معادل با اجرای دستور شل
           gitk --all --not ORIG_HEAD خواهد بود. توجه:

           •   دستورات شل از پوشه سطح بالای (top-level) مخزن اجرا خواهند شد،
               که لزوماً پوشه فعلی نیست.

           •   مقدار GIT_PREFIX همان‌طور که از اجرای git rev-parse
               --show-prefix از پوشه فعلی اولیه بازگردانده می‌شود تنظیم می‌گردد.
               git-rev-parse(1) را ببینید.

           •   نام‌های مستعار دستور شل همیشه آرگومان‌های اضافی ارائه‌شده به خط
               فرمان Git را به عنوان آرگومان‌های موضعی (positional arguments)
               دریافت می‌کنند.

               •   اگر نام مستعار شل شما یک اسکریپت «یک‌خطی» با چند دستور است
                   (مثلاً در یک خط‌لوله)، به چندین آرگومان ارجاع می‌دهد، یا به هر
                   نحو قادر به مدیریت آرگومان‌های موضعی اضافه‌شده در انتها نیست،
                   باید دقت به خرج دهید. برای مثال: alias.cmd = "!echo $1 |
                   grep $2" که به صورت git cmd 1 2 فراخوانی شود، به این شکل
                   اجرا خواهد شد: echo $1 | grep $2 1 2، که مورد نظر شما نیست.

               •   یک راه مناسب برای رفع این مشکل این است که عملیات اسکریپت
                   خود را در یک تابع درون‌خطی (inline function) بنویسید که سپس
                   با هر آرگومان ارائه‌شده از خط فرمان فراخوانی شود. برای مثال:
                   alias.cmd = "!c() { echo $1 | grep $2 ; }; c" مثال قبلی را
                   به درستی اجرا خواهد کرد.

               •   تنظیم GIT_TRACE=1 می‌تواند به شما در اشکال‌زدایی دستوری که
                   برای نام مستعارتان اجرا می‌شود کمک کند.

       am.keepcr
           اگر true باشد، git-am(1) برای وصله‌ها در قالب mbox، git-mailsplit(1)
           را با پارامتر --keep-cr فراخوانی می‌کند. در این حالت git-
           mailsplit(1) کاراکتر \r را از خطوطی که به \r\n ختم می‌شوند حذف
           نمی‌کند. با ارائه --no-keep-cr از خط فرمان قابل بازنویسی است.

       am.threeWay
           به طور پیش‌فرض، اگر وصله به طور تمیز اعمال نشود، git-am(1) با شکست
           مواجه خواهد شد. اگر روی true تنظیم شود، این تنظیم به git-am(1)
           می‌گوید که در صورت ثبت هویت حباب‌ها (blobs) در وصله که قرار است روی
           آن‌ها اعمال شود و در صورت در دسترس بودن محلی آن حباب‌ها، به ادغام
           ۳-طرفه (3-way merge) بازگردد (معادل دادن گزینه --3way از خط فرمان).
           مقدار پیش‌فرض false است.

       am.messageId
           هنگام استفاده از git-am(1)، یک دنباله (trailer) با عنوان Message-ID
           بر اساس سرآیند ایمیل به کامیت اضافه می‌کند (به git-interpret-
           trailers(1) مراجعه کنید). همچنین گزینه‌های --message-id و
           --no-message-id را ببینید.

       apply.ignoreWhitespace
           زمانی که روی change تنظیم شود، به git apply می‌گوید که تغییرات در
           فاصله‌های خالی (whitespace) را نادیده بگیرد، همانند گزینه
           --ignore-space-change.  هنگامی که روی یکی از مقادیر: no، none،
           never، false تنظیم شود، به git apply می‌گوید تمام تفاوت‌های فاصله‌های
           خالی را رعایت کند. به git-apply(1) مراجعه کنید.

       apply.whitespace
           به git apply می‌گوید که چگونه فاصله‌های خالی را مدیریت کند، همانند
           گزینه --whitespace.  به git-apply(1) مراجعه کنید.

       attr.tree
           مرجعی به یک درخت (tree) در مخزن که ویژگی‌ها به جای فایل
           .gitattributes در درخت کاری از آن خوانده شود. اگر مقدار به یک شیء
           درخت معتبر حل‌وفصل نشود، به جای آن یک درخت خالی استفاده می‌شود.
           هنگامی که متغیر محیطی GIT_ATTR_SOURCE یا گزینه خط فرمان
           --attr-source استفاده شوند، این متغیر پیکربندی هیچ اثری ندارد.

           یادداشت (Note)

           گزینه‌های پیکربندی در bitmapPseudoMerge.* آزمایشی (EXPERIMENTAL) در
           نظر گرفته می‌شوند و ممکن است در آینده دستخوش تغییر شده یا به طور
           کامل حذف شوند. برای اطلاعات بیشتر درباره ویژگی نگاشت‌بیتی شبه‌ادغام
           (pseudo-merge bitmap)، بخش «Pseudo-merge bitmaps» در gitpacking(7)
           را ببینید.

       bitmapPseudoMerge.<name>.pattern
           عبارت منظم مورد استفاده برای تطبیق نام‌های مرجع. کامیت‌هایی که توسط
           مراجع منطبق با این الگو اشاره می‌شوند (و معیارهای زیر را برآورده
           می‌کنند، مانند bitmapPseudoMerge.<name>.sampleRate و
           bitmapPseudoMerge.<name>.threshold) برای گنجاندن در یک نگاشت‌بیتی
           شبه‌ادغام در نظر گرفته خواهند شد.

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

           درون یک گروه شبه‌ادغام، کامیت‌ها ممکن است بر اساس گروه‌های تسخیر
           (capture groups) در الگو، بیشتر به زیرگروه‌ها تقسیم شوند. این
           زیرگروه‌بندی‌ها از عبارات منظم با الحاق هر گروه تسخیر از عبارت منظم،
           با یک خط تیره - در این میان تشکیل می‌شوند.

           برای مثال، اگر الگو refs/tags/ باشد، آنگاه تمام تگ‌ها (به شرطی که
           معیارهای زیر را برآورده کنند) به عنوان نامزدهای همان گروه شبه‌ادغام
           در نظر گرفته می‌شوند. اما اگر الگو در عوض
           refs/remotes/([0-9])+/tags/ باشد، آنگاه تگ‌های ریموت‌های مختلف بر
           اساس شماره ریموت در گروه‌های شبه‌ادغام جداگانه دسته‌بندی خواهند شد.

       bitmapPseudoMerge.<name>.decay
           نرخی را تعیین می‌کند که با آن گروه‌های نگاشت‌بیتی شبه‌ادغام متوالی
           اندازه خود را کاهش می‌دهند. باید نامنفی باشد. این پارامتر را می‌توان
           به عنوان k در تابع f(n) = C * n^-k در نظر گرفت، که در آن f(n)
           اندازه گروه n-اُم است.

           تنظیم نرخ زوال (decay rate) برابر با 0 باعث می‌شود همه گروه‌ها اندازه
           یکسانی داشته باشند. تنظیم نرخ زوال برابر با 1 باعث می‌شود گروه n-اُم
           اندازه‌ای معادل `1/n` اندازه گروه اولیه داشته باشد. مقادیر بالاتر
           نرخ زوال باعث می‌شود که گروه‌های متوالی با نرخ فزاینده‌ای کوچک‌تر شوند.
           مقدار پیش‌فرض 1 است.

           اگر همه گروه‌ها هم‌اندازه باشند، این احتمال وجود دارد که گروه‌های حاوی
           کامیت‌های جدیدتر کمتر از گروه‌های قبلی قابل استفاده باشند، زیرا این
           احتمال بیشتر است که مراجع اشاره‌کننده به کامیت‌های جدیدتر مکرراً
           به‌روزرسانی شوند تا مرجعی که به یک کامیت قدیمی اشاره دارد.

       bitmapPseudoMerge.<name>.sampleRate
           نسبت کامیت‌های بدون نگاشت‌بیتی (در میان نوک‌های مرجع) را که برای
           گنجاندن در یک نگاشت‌بیتی شبه‌ادغام ناپایدار انتخاب می‌شوند تعیین
           می‌کند. باید بزرگ‌تر از 0 و کوچک‌تر یا مساوی با 1 باشد. مقدار پیش‌فرض 1
           است.

       bitmapPseudoMerge.<name>.threshold
           حداقل سن کامیت‌های بدون نگاشت‌بیتی (در میان نوک‌های مرجع، مانند بالا)
           را که نامزد گنجاندن در یک نگاشت‌بیتی شبه‌ادغام ناپایدار هستند تعیین
           می‌کند. مقدار پیش‌فرض 1.week.ago است.

       bitmapPseudoMerge.<name>.maxMerges
           حداکثر تعداد کامیت‌های شبه‌ادغام را که کامیت‌ها ممکن است در میان آن‌ها
           توزیع شوند تعیین می‌کند.

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

           برای مثال، اگر گروه تسخیر شما refs/tags/ باشد، این تنظیم تمام تگ‌ها
           را حداکثر در maxMerges کامیت شبه‌ادغام توزیع می‌کند. با این حال، اگر
           گروه تسخیر شما مثلاً refs/remotes/([0-9]+)/tags/ باشد، این تنظیم
           برای مجموعه تگ‌های هر ریموت به طور جداگانه اعمال خواهد شد.

           باید نامنفی باشد. مقدار پیش‌فرض 64 است.

       bitmapPseudoMerge.<name>.stableThreshold
           حداقل سن کامیت‌ها (در میان نوک‌های مرجع، همان‌طور که در بالا گفته شد،
           هرچند کامیت‌های پایدار حتی در صورتی که توسط یک نگاشت‌بیتی پوشش داده
           شده باشند همچنان نامزد در نظر گرفته می‌شوند) را که نامزد یک
           نگاشت‌بیتی شبه‌ادغام پایدار هستند تعیین می‌کند. مقدار پیش‌فرض
           1.month.ago است.

           تنظیم این آستانه روی مقداری کوچک‌تر (مثلاً 1.week.ago) باعث می‌شود
           گروه‌های پایدار بیشتری ایجاد شوند (که هزینه تولید یک‌باره را تحمیل
           می‌کنند) اما این گروه‌ها احتمالاً با گذشت زمان کهنه می‌شوند. استفاده از
           یک مقدار بزرگ‌تر جریمه معکوس را به همراه دارد (گروه‌های پایدار کمتر
           که مفیدتر هستند).

       bitmapPseudoMerge.<name>.stableSize
           اندازه (بر حسب تعداد کامیت‌ها) یک نگاشت‌بیتی شبه‌ادغام پایدار را تعیین
           می‌کند. مقدار پیش‌فرض 512 است.

       blame.blankBoundary
           نمایش نام شیء کامیت خالی برای کامیت‌های مرزی در git-blame(1).  این
           گزینه به طور پیش‌فرض روی false است.

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

       blame.date
           قالب مورد استفاده برای خروجی تاریخ‌ها در git-blame(1) را مشخص می‌کند.
           در صورت عدم تنظیم، از قالب iso استفاده می‌شود. برای مقادیر
           پشتیبانی‌شده، توضیحات گزینه --date را در git-log(1) ببینید.

       blame.showEmail
           نمایش ایمیل نویسنده به جای نام نویسنده در git-blame(1).  این گزینه
           به طور پیش‌فرض روی false است.

       blame.showRoot
           عدم برخورد با کامیت‌های ریشه به عنوان مرز در git-blame(1).  این
           گزینه به طور پیش‌فرض روی false است.

       blame.ignoreRevsFile
           ویرایش‌های (revisions) فهرست‌شده در فایل را (یک نام شیء خلاصه‌نشده در
           هر خط) در git-blame(1) نادیده می‌گیرد. فاصله‌های خالی و توضیحاتی که
           با # شروع می‌شوند نادیده گرفته می‌شوند. این گزینه ممکن است چندین بار
           تکرار شود. نام‌های فایل خالی، فهرست ویرایش‌های نادیده‌گرفته‌شده را
           بازنشانی می‌کنند. این گزینه پیش از گزینه خط فرمان --ignore-revs-file
           پردازش خواهد شد.

       blame.markUnblamableLines
           خطوطی را که توسط یک ویرایش نادیده‌گرفته‌شده تغییر یافته‌اند و
           نتوانسته‌ایم آن‌ها را به کامیت دیگری نسبت دهیم، با یک * در خروجی git-
           blame(1) علامت‌گذاری می‌کند.

       blame.markIgnoredLines
           خطوطی را که توسط یک ویرایش نادیده‌گرفته‌شده تغییر یافته‌اند و ما آن‌ها
           را به کامیت دیگری نسبت داده‌ایم، با یک ? در خروجی git-blame(1)
           علامت‌گذاری می‌کند.

       branch.autoSetupMerge
           به git branch، git switch و git checkout می‌گوید شاخه‌های جدید را
           طوری تنظیم کنند که git-pull(1) به طور مناسب از شاخه نقطه شروع ادغام
           شود. توجه داشته باشید که حتی اگر این گزینه تنظیم نشده باشد، این
           رفتار را می‌توان برای هر شاخه با استفاده از گزینه‌های --track و
           --no-track انتخاب کرد. این گزینه به طور پیش‌فرض روی true است.
           تنظیمات معتبر عبارتند از:

           false
               هیچ راه‌اندازی خودکاری انجام نمی‌شود

           true
               راه‌اندازی خودکار زمانی انجام می‌شود که نقطه شروع یک شاخه ردیابی
               ریموت باشد

           always
               راه‌اندازی خودکار زمانی انجام می‌شود که نقطه شروع یک شاخه محلی یا
               یک شاخه ردیابی ریموت باشد

           inherit
               اگر نقطه شروع دارای پیکربندی ردیابی باشد، به شاخه جدید کپی
               می‌شود

           simple
               راه‌اندازی خودکار تنها زمانی انجام می‌شود که نقطه شروع یک شاخه
               ردیابی ریموت باشد و شاخه جدید همان نام شاخه ریموت را داشته
               باشد.

       branch.autoSetupRebase
           هنگامی که یک شاخه جدید با git branch، git switch یا git checkout
           ایجاد می‌شود که شاخه دیگری را ردیابی می‌کند، این متغیر به Git می‌گوید
           pull را طوری تنظیم کند که به جای ادغام (merge)، بازسازی (rebase)
           انجام دهد (به branch.<name>.rebase مراجعه کنید). تنظیمات معتبر
           عبارتند از:

           never
               rebase هرگز به طور خودکار روی true تنظیم نمی‌شود.

           local
               rebase برای شاخه‌های ردیابی‌شده سایر شاخه‌های محلی روی true تنظیم
               می‌شود.

           remote
               rebase برای شاخه‌های ردیابی‌شده شاخه‌های ردیابی ریموت روی true
               تنظیم می‌شود.

           always
               rebase برای همه شاخه‌های ردیابی روی true تنظیم خواهد شد.

           برای جزئیات بیشتر در مورد نحوه تنظیم یک شاخه برای ردیابی شاخه دیگر،
           branch.autoSetupMerge را ببینید. این گزینه به طور پیش‌فرض روی never
           است.

       branch.sort
           این متغیر ترتیب مرتب‌سازی شاخه‌ها را هنگام نمایش توسط git-branch(1)
           کنترل می‌کند. بدون ارائه گزینه --sort=<value>، مقدار این متغیر به
           عنوان پیش‌فرض استفاده خواهد شد. برای مقادیر معتبر، نام فیلدهای git-
           for-each-ref(1) را ببینید.

       branch.<name>.remote
           هنگامی که در شاخه <name> هستید، به git fetch و git push می‌گوید از
           کدام ریموت واکشی کرده یا به کدام ارسال کنند. ریموت مقصد ارسال ممکن
           است با remote.pushDefault (برای همه شاخه‌ها) بازنویسی شود. ریموت
           مقصد ارسال، برای شاخه فعلی، ممکن است بیشتر توسط
           branch.<name>.pushRemote بازنویسی گردد. اگر هیچ ریموتی پیکربندی
           نشده باشد، یا اگر در هیچ شاخه‌ای نباشید و بیش از یک ریموت در مخزن
           تعریف شده باشد، مقدار پیش‌فرض برای واکشی origin و برای ارسال
           remote.pushDefault است. علاوه بر این، . (یک نقطه) نشان‌دهنده مخزن
           محلی فعلی است (یک مخزن نقطه‌ای یا dot-repository)، یادداشت نهایی
           branch.<name>.merge را در زیر ببینید.

       branch.<name>.pushRemote
           هنگامی که در شاخه <name> هستید، branch.<name>.remote را برای ارسال
           (push) بازنویسی می‌کند. همچنین remote.pushDefault را برای ارسال از
           شاخه <name> بازنویسی می‌نماید. هنگامی که از یک مکان (مثلاً بالادست
           خود) pull می‌کنید و به مکان دیگری (مثلاً مخزن انتشار اختصاصی خود)
           push انجام می‌دهید، ممکن است بخواهید remote.pushDefault را برای مشخص
           کردن ریموت مقصد ارسال برای همه شاخه‌ها تنظیم کنید و از این گزینه
           برای بازنویسی آن برای یک شاخه خاص استفاده نمایید.

       branch.<name>.merge
           به همراه branch.<name>.remote، شاخه بالادست را برای شاخه داده‌شده
           تعریف می‌کند. به git fetch/git pull/git rebase می‌گوید کدام شاخه را
           ادغام کنند و همچنین می‌تواند بر git push تأثیر بگذارد (به
           push.default مراجعه کنید). هنگامی که در شاخه <name> هستید، به git
           fetch مشخصه مرجع (refspec) پیش‌فرضی را که باید برای ادغام در
           FETCH_HEAD علامت‌گذاری شود می‌گوید. مقدار مانند بخش ریموت یک مشخصه
           مرجع مدیریت می‌شود و باید با مرجعی مطابقت داشته باشد که از ریموت
           ارائه‌شده توسط branch.<name>.remote واکشی شده است. اطلاعات ادغام
           توسط git pull (که ابتدا git fetch را فراخوانی می‌کند) برای یافتن
           شاخه پیش‌فرض ادغام استفاده می‌شود. بدون این گزینه، git pull به طور
           پیش‌فرض اولین مشخصه مرجع واکشی‌شده را ادغام می‌کند. مقادیر متعددی را
           برای دستیابی به یک ادغام هشت‌پا (octopus merge) مشخص کنید. اگر
           می‌خواهید git pull را طوری تنظیم کنید که از شاخه دیگری در مخزن محلی
           در <name> ادغام شود، می‌توانید branch.<name>.merge را به شاخه مورد
           نظر اشاره دهید و از تنظیم مسیر نسبی . (یک نقطه) برای
           branch.<name>.remote استفاده نمایید.

       branch.<name>.mergeOptions
           گزینه‌های پیش‌فرض را برای ادغام در شاخه <name> تنظیم می‌کند. نحو و
           گزینه‌های پشتیبانی‌شده مانند گزینه‌های git-merge(1) هستند، اما مقادیر
           گزینه‌های حاوی نویسه‌های فاصله خالی در حال حاضر پشتیبانی نمی‌شوند.

       branch.<name>.rebase
           هنگامی که روی true باشد، در زمان اجرای git pull، شاخه <name> را به
           جای ادغام شاخه پیش‌فرض از ریموت پیش‌فرض، بر روی شاخه واکشی‌شده بازسازی
           (rebase) می‌کند. برای انجام این کار به شیوه‌ای غیر وابسته به شاخه،
           pull.rebase را ببینید.

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

           هنگامی که مقدار interactive (یا صرفاً i) باشد، بازسازی در حالت
           تعاملی اجرا می‌شود.

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

       branch.<name>.description
           توضیحات شاخه، با git branch --edit-description قابل ویرایش است.
           توضیحات شاخه به طور خودکار به نامه مقدماتی (cover letter) در
           format-patch یا خلاصه request-pull اضافه می‌شود.

       browser.<tool>.cmd
           دستور فراخوانی مرورگر مشخص‌شده را تعیین می‌کند. دستور مشخص‌شده در شل
           ارزیابی شده و نشانی‌های اینترنتی به عنوان آرگومان به آن ارسال
           می‌شوند. (به git-web--browse(1) مراجعه کنید).

       browser.<tool>.path
           مسیر ابزار داده‌شده را که ممکن است برای مرور راهنمای HTML (گزینه -w
           در git-help(1) را ببینید) یا یک مخزن کاری در gitweb (به git-
           instaweb(1) مراجعه کنید) استفاده شود، بازنویسی می‌کند.

       bundle.*
           کلیدهای bundle.* ممکن است در یک فایل فهرست بسته (bundle list) که از
           طریق گزینه git clone --bundle-uri یافت شده ظاهر شوند. این کلیدها در
           حال حاضر در صورت قرار گرفتن در فایل پیکربندی مخزن هیچ اثری ندارند،
           اگرچه این موضوع در آینده تغییر خواهد کرد. برای جزئیات بیشتر به the
           bundle URI design document[1] مراجعه کنید.

       bundle.version
           این مقدار عدد صحیح نسخه قالب فهرست بسته مورد استفاده توسط فهرست
           بسته را اعلان می‌کند. در حال حاضر، تنها مقدار پذیرفته‌شده 1 است.

       bundle.mode
           این مقدار رشته‌ای باید all یا any باشد. این مقدار مشخص می‌کند که آیا
           تمام بسته‌های اعلان‌شده برای باز کردن بسته و دستیابی به درک کاملی از
           اطلاعات بسته‌بندی‌شده مورد نیاز هستند (all) یا اینکه هر یک از URIهای
           بسته فهرست‌شده کافی است (any).

       bundle.heuristic
           اگر این کلید با مقدار رشته‌ای وجود داشته باشد، فهرست بسته به گونه‌ای
           طراحی شده است که با دستورات افزایشی git fetch به خوبی کار کند. این
           اکتشاف (heuristic) نشان می‌دهد که کلیدهای اضافی برای هر بسته در
           دسترس هستند که به تعیین زیرمجموعه‌ای از بسته‌ها که کلاینت باید دانلود
           کند کمک می‌نمایند. تنها مقداری که در حال حاضر قابل درک است
           creationToken می‌باشد.

       bundle.<id>.*
           کلیدهای bundle.<id>.* برای توصیف یک آیتم منفرد در فهرست بسته
           استفاده می‌شوند که برای اهداف شناسایی تحت <id> گروه‌بندی شده‌اند.

       bundle.<id>.uri
           این مقدار رشته‌ای، نشانی URI را مشخص می‌کند که Git از طریق آن می‌تواند
           به محتویات این <id> دسترسی پیدا کند. این URI ممکن است یک فایل بسته
           یا یک فهرست بسته دیگر باشد.

       checkout.defaultRemote
           هنگامی که شما git checkout <something> یا git switch <something> را
           اجرا می‌کنید و فقط یک ریموت دارید، ممکن است به طور ضمنی به تحویل
           گرفتن و ردیابی به عنوان مثال origin/<something> بازگردد. به محض
           اینکه بیش از یک ریموت با مرجع <something> داشته باشید، این عملکرد
           متوقف می‌شود. این تنظیم اجازه می‌دهد نام یک ریموت ترجیحی تنظیم شود که
           همیشه هنگام رفع ابهام اولویت داشته باشد. کاربرد معمول این است که
           این گزینه روی origin تنظیم شود.

           در حال حاضر این متغیر توسط git-switch(1) و git-checkout(1) زمانی
           استفاده می‌شود که git checkout <something> یا git switch <something>
           شاخه <something> را روی ریموت دیگری تحویل بگیرند، و همچنین توسط
           git-worktree(1) زمانی که git worktree add به یک شاخه ریموت ارجاع
           می‌دهد. این تنظیم ممکن است در آینده برای سایر دستورات یا قابلیت‌های
           مشابه checkout نیز استفاده شود.

       checkout.guess
           مقدار پیش‌فرض را برای گزینه --guess یا --no-guess در git checkout و
           git switch فراهم می‌کند.  git-switch(1) و git-checkout(1) را ببینید.

       checkout.workers
           تعداد کارگرهای موازی (parallel workers) مورد استفاده هنگام
           به‌روزرسانی درخت کاری. مقدار پیش‌فرض یک است، یعنی اجرای متوالی. اگر
           روی مقداری کمتر از یک تنظیم شود، Git به تعداد هسته‌های منطقی در
           دسترس از کارگرها استفاده خواهد کرد. این تنظیم و
           checkout.thresholdForParallelism بر تمام دستوراتی که عمل چک‌اوت را
           انجام می‌دهند تأثیر می‌گذارند؛ مانند checkout، clone، reset،
           sparse-checkout و غیره.

               یادداشت
               چک‌اوت موازی معمولاً برای مخازن قرارگرفته روی SSD یا روی NFS
               عملکرد بهتری ارائه می‌دهد. برای مخازن روی دیسک‌های چرخان یا
               ماشین‌هایی با تعداد هسته‌های اندک، چک‌اوت متوالی پیش‌فرض اغلب
               عملکرد بهتری دارد. اندازه و سطح فشرده‌سازی یک مخزن نیز ممکن است
               بر میزان کارایی نسخه موازی تأثیر بگذارد.

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

       clean.requireForce
           یک مقدار بولی برای اینکه git-clean از حذف فایل‌ها خودداری کند مگر
           آنکه گزینه -f مشخص شده باشد. به‌طور پیش‌فرض true است.

       clone.defaultRemoteName
           نام ریموتی که هنگام کلون کردن یک مخزن ایجاد می‌شود. مقدار پیش‌فرض
           origin است. می‌توان آن را با ارسال گزینه خط فرمان --origin به git-
           clone(1) بازنویسی کرد.

       clone.rejectShallow
           رد کردن کلون یک مخزن در صورتی که کم‌عمق (shallow) باشد؛ این رفتار را
           می‌توان با ارسال گزینه --reject-shallow در خط فرمان لغو کرد. به git-
           clone(1) مراجعه کنید.

       clone.filterSubmodules
           اگر یک فیلتر کلون جزئی ارائه شده باشد (به --filter در git-rev-
           list(1) مراجعه کنید) و --recurse-submodules استفاده شود، فیلتر را
           برای زیرماژول‌ها نیز اعمال می‌کند.

       color.advice
           یک مقدار بولی برای فعال/غیرفعال کردن رنگ در پیام‌های راهنما (مثلاً
           هنگامی که یک push ناموفق بود، برای مشاهده فهرست به advice.* مراجعه
           کنید). ممکن است روی always، false (یا never) یا auto (یا true)
           تنظیم شود، که در این حالت رنگ‌ها تنها زمانی استفاده می‌شوند که خروجی
           خطا به یک ترمینال ارسال شود. اگر تنظیم نشده باشد، مقدار color.ui
           استفاده می‌شود (به‌طور پیش‌فرض auto).

       color.advice.hint
           استفاده از رنگ سفارشی برای پیام‌های راهنما.

       color.blame.highlightRecent
           تعیین رنگ حاشیه‌نویسی خطوط برای git blame --color-by-age بسته به
           قدمت خط.

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

           به جای برچسب زمانی مطلق، برچسب‌های زمانی نسبی نیز کار می‌کنند، مثلاً
           2.weeks.ago برای اشاره به هر موردی قدیمی‌تر از ۲ هفته معتبر است.

           مقدار پیش‌فرض آن blue,12 month ago,white,1 month ago,red است، که هر
           چیزی قدیمی‌تر از یک سال را آبی می‌کند، تغییرات اخیر بین یک ماه تا یک
           سال سفید نگه داشته می‌شوند، و خطوط ایجادشده در طول یک ماه گذشته به
           رنگ قرمز درمی‌آیند.

       color.blame.repeatedLines
           استفاده از رنگ مشخص‌شده برای رنگ‌آمیزی حاشیه‌نویسی خطوط در git blame
           --color-lines، در صورتی که از همان کامیت خط قبلی آمده باشند. مقدار
           پیش‌فرض cyan است.

       color.branch
           یک مقدار بولی برای فعال/غیرفعال کردن رنگ در خروجی git-branch(1).
           می‌تواند روی always، false (یا never) یا auto (یا true) تنظیم شود،
           که در این حالت رنگ‌ها تنها زمانی استفاده می‌شوند که خروجی به یک
           ترمینال ارسال شود. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود
           (به‌طور پیش‌فرض auto).

       color.branch.<slot>
           استفاده از رنگ سفارشی برای رنگ‌آمیزی شاخه.  <slot> یکی از موارد زیر
           است: current (شاخه فعلی)، local (یک شاخه محلی)، remote (یک شاخه
           ردیابی از راه دور در refs/remotes/)، upstream (شاخه ردیابی
           بالادست)، plain (سایر ارجاع‌ها).

       color.diff
           آیا از دنباله‌های گریز ANSI برای افزودن رنگ به پچ‌ها استفاده شود یا
           خیر. اگر این مقدار روی always تنظیم شود، دستورات git-diff(1)، git-
           log(1) و git-show(1) برای تمام پچ‌ها از رنگ استفاده خواهند کرد. اگر
           روی true یا auto تنظیم شود، این دستورات تنها زمانی که خروجی به
           ترمینال می‌رود از رنگ استفاده می‌کنند. اگر تنظیم نشده باشد، مقدار
           color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

           این تنظیم روی git-format-patch(1) یا دستورات لوله‌کشی (plumbing)
           git-diff-* تأثیری ندارد. می‌تواند در خط فرمان با گزینه
           --color[=<when>] لغو شود.

       color.diff.<slot>
           استفاده از رنگ سفارشی برای رنگ‌آمیزی diff.  <slot> مشخص می‌کند که
           کدام بخش از پچ از رنگ مشخص‌شده استفاده کند، و یکی از موارد زیر است:
           context (متن زمینه - plain یک مترادف قدیمی است)، meta (اطلاعات
           متا)، frag (هدر تکه تغییرات)، func (تابع در هدر تکه تغییرات)، old
           (خطوط حذف‌شده)، new (خطوط اضافه‌شده)، commit (هدرهای کامیت)،
           whitespace (برجسته‌سازی خطاهای فاصله‌گذاری)، oldMoved (خطوط حذف‌شده)،
           newMoved (خطوط اضافه‌شده)، oldMovedDimmed، oldMovedAlternative،
           oldMovedAlternativeDimmed، newMovedDimmed، newMovedAlternative
           newMovedAlternativeDimmed (برای جزئیات به تنظیم <mode> در گزینه
           --color-moved از git-diff(1) مراجعه کنید)، contextDimmed،
           oldDimmed، newDimmed، contextBold، oldBold و newBold (برای جزئیات
           به git-range-diff(1) مراجعه کنید).

       color.decorate.<slot>
           استفاده از رنگ سفارشی برای خروجی git log --decorate.  <slot> به
           ترتیب یکی از مقادیر branch، remoteBranch، tag، stash یا HEAD برای
           شاخه‌های محلی، شاخه‌های ردیابی ریموت، برچسب‌ها، استش و HEAD است و
           grafted برای کامیت‌های پیوندخورده (grafted).

       color.grep
           هنگامی که روی always تنظیم شود، همیشه موارد منطبق را برجسته می‌کند.
           هنگامی که false (یا never) باشد، هرگز. هنگامی که روی true یا auto
           تنظیم شود، رنگ را تنها زمانی استفاده می‌کند که خروجی در ترمینال
           نوشته شود. اگر تنظیم نشده باشد، مقدار color.ui استفاده می‌شود (به‌طور
           پیش‌فرض auto).

       color.grep.<slot>
           استفاده از رنگ سفارشی برای رنگ‌آمیزی grep.  <slot> مشخص می‌کند کدام
           بخش از خط از رنگ مشخص‌شده استفاده کند، و یکی از موارد زیر است:

           context
               متن غیرمنطبق در خطوط زمینه (هنگام استفاده از -A، -B یا -C)

           filename
               پیشوند نام فایل (هنگامی که از -h استفاده نمی‌شود)

           function
               خطوط نام تابع (هنگام استفاده از -p)

           lineNumber
               پیشوند شماره خط (هنگام استفاده از -n)

           column
               پیشوند شماره ستون (هنگام استفاده از --column)

           match
               متن منطبق (مشابه تنظیم matchContext و matchSelected)

           matchContext
               متن منطبق در خطوط زمینه

           matchSelected
               متن منطبق در خطوط انتخاب‌شده. همچنین برای سفارشی‌سازی زیردستورهای
               زیر از git-log(1) استفاده می‌شود: --grep، --author و
               --committer.

           selected
               متن غیرمنطبق در خطوط انتخاب‌شده. همچنین برای سفارشی‌سازی
               زیردستورهای زیر از git-log(1) استفاده می‌شود: --grep، --author و
               --committer.

           separator
               جداکننده‌های بین فیلدها در یک خط (:، - و =) و بین تکه‌ها (--)

       color.interactive
           هنگامی که روی always تنظیم شود، همیشه از رنگ‌ها برای اعلانات و
           نمایش‌های تعاملی استفاده کن (مانند مواردی که توسط "git-add
           --interactive" و "git-clean --interactive" استفاده می‌شود). هنگامی
           که false (یا never) باشد، هرگز. هنگامی که روی true یا auto تنظیم
           شود، رنگ‌ها تنها زمانی استفاده می‌شوند که خروجی به ترمینال باشد. در
           صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

       color.interactive.<slot>
           استفاده از رنگ سفارشی برای خروجی‌های git add --interactive و git
           clean --interactive.  <slot> می‌تواند prompt، header، help یا error
           برای چهار نوع متمایز از خروجی‌های عادی دستورات تعاملی باشد.

       color.pager
           یک مقدار بولی برای مشخص کردن اینکه آیا حالت‌های رنگی auto باید خروجی
           ارسال‌شده به صفحه‌بندی‌کننده (pager) را رنگ‌آمیزی کنند یا خیر. پیش‌فرض
           true است؛ اگر صفحه‌بندی‌کننده شما کدهای رنگی ANSI را درک نمی‌کند، این
           را روی false تنظیم کنید.

       color.push
           یک مقدار بولی برای فعال/غیرفعال کردن رنگ در خطاهای push. ممکن است
           روی always، false (یا never) یا auto (یا true) تنظیم شود، که در این
           حالت رنگ‌ها تنها زمانی استفاده می‌شوند که خروجی خطا به یک ترمینال
           ارسال شود. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور
           پیش‌فرض auto).

       color.push.error
           استفاده از رنگ سفارشی برای خطاهای push.

       color.remote
           در صورت تنظیم، کلمات کلیدی در ابتدای خط برجسته می‌شوند. این کلمات
           کلیدی شامل "error" ،"warning" ،"hint" و "success" هستند و بدون
           حساسیت به بزرگی و کوچکی حروف تطبیق داده می‌شوند. ممکن است روی
           always، false (یا never) یا auto (یا true) تنظیم شود. در صورت تنظیم
           نشدن، مقدار color.ui استفاده می‌شود (به‌طور پیش‌فرض auto).

       color.remote.<slot>
           استفاده از رنگ سفارشی برای هر کلمه کلیدی ریموت.  <slot> می‌تواند
           hint، warning، success یا error باشد که با کلمه کلیدی متناظر تطبیق
           می‌یابد.

       color.showBranch
           یک مقدار بولی برای فعال/غیرفعال کردن رنگ در خروجی git-show-
           branch(1).  می‌تواند روی always، false (یا never) یا auto (یا true)
           تنظیم شود، که در این صورت رنگ‌ها تنها زمانی که خروجی به ترمینال
           ارسال می‌شود به کار می‌روند. در صورت تنظیم نشدن، مقدار color.ui
           استفاده می‌شود (به‌طور پیش‌فرض auto).

       color.status
           یک مقدار بولی برای فعال/غیرفعال کردن رنگ در خروجی git-status(1).
           می‌تواند روی always، false (یا never) یا auto (یا true) تنظیم شود،
           که در این حالت رنگ‌ها فقط زمانی که خروجی به یک ترمینال می‌رود استفاده
           می‌شوند. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود (به‌طور
           پیش‌فرض auto).

       color.status.<slot>
           استفاده از رنگ سفارشی برای رنگ‌آمیزی وضعیت.  <slot> یکی از موارد زیر
           است: header (متن هدر پیام وضعیت)، added یا updated (فایل‌هایی که
           اضافه شده‌اند اما هنوز کامیت نشده‌اند)، changed (فایل‌هایی که تغییر
           یافته‌اند اما در ایندکس اضافه نشده‌اند)، untracked (فایل‌هایی که توسط
           Git ردیابی نمی‌شوند)، branch (شاخه فعلی)، nobranch (رنگی که هشدار no
           branch با آن نشان داده می‌شود، با پیش‌فرض قرمز)، localBranch یا
           remoteBranch (به ترتیب نام شاخه محلی و ریموت، زمانی که اطلاعات شاخه
           و ردیابی در قالب کوتاه وضعیت نمایش داده می‌شود)، یا unmerged
           (فایل‌هایی که تغییرات ادغام‌نشده دارند).

       color.transport
           یک مقدار بولی برای فعال/غیرفعال کردن رنگ هنگام رد شدن pushها. ممکن
           است روی always، false (یا never) یا auto (یا true) تنظیم شود، که در
           این حالت رنگ‌ها فقط زمانی که خروجی خطا به یک ترمینال ارسال می‌شود
           استفاده می‌گردند. در صورت تنظیم نشدن، مقدار color.ui استفاده می‌شود
           (به‌طور پیش‌فرض auto).

       color.transport.rejected
           استفاده از رنگ سفارشی هنگامی که یک push رد شده باشد.

       color.ui
           این متغیر مقدار پیش‌فرض را برای متغیرهایی مانند color.diff و
           color.grep تعیین می‌کند که استفاده از رنگ را در هر خانواده دستور
           کنترل می‌نمایند. دامنه آن با پشتیبانی دستورات بیشتر از قابلیت
           پیکربندی جهت تعیین پیش‌فرض برای گزینه --color گسترش خواهد یافت. اگر
           ترجیح می‌دهید دستورات Git از رنگ استفاده نکنند مگر اینکه صریحاً با
           پیکربندی دیگری یا گزینه --color فعال شده باشد، آن را روی false یا
           never تنظیم کنید. اگر می‌خواهید تمام خروجی‌هایی که برای پردازش ماشینی
           در نظر گرفته نشده‌اند از رنگ استفاده کنند آن را روی always، و اگر
           می‌خواهید این خروجی‌ها هنگام ارسال به ترمینال از رنگ استفاده کنند آن
           را روی true یا auto تنظیم نمایید (این گزینه از Git 1.8.4 مقدار
           پیش‌فرض است).

       column.ui
           مشخص می‌کند که آیا دستورات پشتیبانی‌شده باید خروجی را در ستون‌ها نمایش
           دهند یا خیر. این متغیر شامل فهرستی از توکن‌ها است که با فاصله یا
           کاما از هم جدا شده‌اند:

           این گزینه‌ها زمان فعال بودن این ویژگی را کنترل می‌کنند (به‌طور پیش‌فرض
           never):

           always
               همیشه در ستون‌ها نمایش داده شود

           never
               هرگز در ستون‌ها نمایش داده نشود

           auto
               اگر خروجی به ترمینال برود در ستون‌ها نمایش داده شود

           این گزینه‌ها چیدمان را کنترل می‌کنند (به‌طور پیش‌فرض column).  تنظیم هر
           یک از این موارد در صورتی که هیچ‌یک از مقادیر always، never یا auto
           مشخص نشده باشند، به معنای always خواهد بود.

           column
               ستون‌ها قبل از سطرها پر شوند

           row
               سطرها قبل از ستون‌ها پر شوند

           plain
               در یک ستون نمایش داده شود

           در نهایت، این گزینه‌ها را می‌توان با یک گزینه چیدمان ترکیب کرد (به‌طور
           پیش‌فرض nodense):

           dense
               ایجاد ستون‌هایی با اندازه نابرابر برای بهره‌گیری از فضای بیشتر

           nodense
               ایجاد ستون‌هایی با اندازه برابر

       column.branch
           مشخص می‌کند که آیا خروجی فهرست شاخه‌ها در git branch به صورت ستونی
           نمایش داده شود یا خیر. برای جزئیات به column.ui مراجعه کنید.

       column.clean
           تعیین چیدمان هنگام فهرست کردن موارد در git clean -i، که همیشه
           فایل‌ها و پوشه‌ها را در ستون‌ها نشان می‌دهد. برای جزئیات به column.ui
           مراجعه کنید.

       column.status
           مشخص می‌کند که آیا فایل‌های ردیابی‌نشده در git status به صورت ستونی
           نمایش داده شوند یا خیر. برای جزئیات به column.ui مراجعه کنید.

       column.tag
           مشخص می‌کند که آیا فهرست برچسب‌ها در git tag به صورت ستونی نمایش داده
           شود یا خیر. برای جزئیات به column.ui مراجعه کنید.

       commit.cleanup
           این تنظیم پیش‌فرض گزینه --cleanup را در git commit بازنویسی می‌کند.
           برای جزئیات به git-commit(1) مراجعه کنید. تغییر مقدار پیش‌فرض زمانی
           مفید است که می‌خواهید خطوطی را که با نویسه توضیح (core.commentChar،
           پیش‌فرض #) شروع می‌شوند همیشه در پیام گزارش خود نگه دارید، که در این
           حالت دستور زیر را اجرا می‌کنید: git config commit.cleanup whitespace
           (توجه داشته باشید که اگر این کار را انجام دهید، خودتان باید خطوط
           راهنما را که با نویسه توضیح در الگوی گزارش کامیت شروع می‌شوند، حذف
           کنید).

       commit.gpgSign
           یک مقدار بولی برای مشخص کردن اینکه آیا تمام کامیت‌ها باید با GPG
           امضا شوند یا خیر. استفاده از این گزینه هنگام انجام عملیاتی مانند
           rebase می‌تواند به امضا شدن تعداد زیادی کامیت منجر شود. برای جلوگیری
           از تایپ چندباره عبارت عبور GPG، ممکن است استفاده از یک agent مناسب
           باشد.

       commit.status
           یک مقدار بولی برای فعال/غیرفعال کردن درج اطلاعات وضعیت در الگوی
           پیام کامیت هنگام استفاده از ویرایشگر برای آماده‌سازی پیام کامیت.
           به‌طور پیش‌فرض true است.

       commit.template
           مسیر فایلی را مشخص می‌کند که به عنوان الگو برای پیام‌های کامیت جدید
           استفاده شود.

       commit.verbose
           یک مقدار بولی یا عددی برای تعیین سطح جزئیات خروجی در git commit.
           برای جزئیات به git-commit(1) مراجعه کنید.

       commitGraph.generationVersion
           نوع نسخه شماره نسل را برای استفاده هنگام نوشتن یا خواندن فایل
           commit-graph مشخص می‌کند. اگر نسخه 1 مشخص شود، تاریخ‌های تصحیح‌شده
           کامیت نوشته یا خوانده نخواهند شد. به‌طور پیش‌فرض 2 است.

       commitGraph.maxNewFilters
           مقدار پیش‌فرض را برای گزینه --max-new-filters در دستور git
           commit-graph write مشخص می‌کند (قیاس کنید با git-commit-graph(1)).

       commitGraph.changedPaths
           اگر true باشد، git commit-graph write به‌طور پیش‌فرض فیلترهای بلوم
           مسیرهای تغییریافته را محاسبه کرده و می‌نویسد، که معادل با ارسال
           --changed-paths است. اگر false یا تنظیم‌نشده باشد، فیلترهای بلوم
           مسیرهای تغییریافته در حین git commit-graph write فقط در صورتی نوشته
           می‌شوند که این فیلترها از قبل در فایل commit-graph فعلی وجود داشته
           باشند. این با رفتار پیش‌فرض git commit-graph write بدون هیچ گزینه
           --[no-]changed-paths مطابقت دارد. برای بازنویسی فایل commit-graph
           بدون فیلترها، از گزینه --no-changed-paths استفاده کنید. گزینه خط
           فرمان --[no-]changed-paths همیشه بر این پیکربندی اولویت دارد. مقدار
           پیش‌فرض تنظیم‌نشده است.

       commitGraph.readChangedPaths
           منسوخ شده است. معادل commitGraph.changedPathsVersion=-1 در صورت
           true بودن، و commitGraph.changedPathsVersion=0 در صورت false بودن
           است. (اگر commitGraph.changedPathVersion نیز تنظیم شده باشد،
           commitGraph.changedPathsVersion اولویت دارد.)

       commitGraph.changedPathsVersion
           نسخه فیلترهای بلوم مسیرهای تغییریافته را که Git می‌خواند و می‌نویسد
           مشخص می‌کند. ممکن است -1، 0، 1 یا 2 باشد. توجه داشته باشید که مقادیر
           بزرگتر از 1 ممکن است با نسخه‌های قدیمی‌تر Git که هنوز آن نسخه‌ها را
           درک نمی‌کنند ناسازگار باشند. هنگام کار در محیطی با نسخه‌های ترکیبی
           احتیاط کنید.

           پیش‌فرض -1 است.

           اگر -1 باشد، Git از نسخه فیلترهای بلوم مسیرهای تغییریافته موجود در
           مخزن استفاده می‌کند، و اگر هیچ‌کدام وجود نداشته باشد پیش‌فرض 1 خواهد
           بود.

           اگر 0 باشد، Git هیچ فیلتر بلومی را نمی‌خواند، و هنگام صدور دستور
           نوشتن، فیلترهای بلوم نسخه 1 را می‌نویسد.

           اگر 1 باشد، Git فقط فیلترهای بلوم نسخه 1 را می‌خواند، و فیلترهای
           بلوم نسخه 1 را می‌نویسد.

           اگر 2 باشد، Git فقط فیلترهای بلوم نسخه 2 را می‌خواند، و فیلترهای
           بلوم نسخه 2 را می‌نویسد.

           برای اطلاعات بیشتر به git-commit-graph(1) مراجعه کنید.

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

       core.fileMode
           به Git می‌گوید که آیا بیت اجرایی (executable bit) فایل‌ها در درخت
           کاری رعایت شود یا خیر.

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

           با این حال، ممکن است یک مخزن روی سیستم فایلی باشد که حالت فایل را
           به درستی مدیریت می‌کند، و این متغیر هنگام ایجاد روی true تنظیم شده
           باشد، اما بعداً از محیط دیگری در دسترس قرار گیرد که حالت فایل را از
           بین می‌برد (مانند صادر کردن ext4 از طریق مانت CIFS، یا بازدید از
           مخزن ایجادشده در Cygwin توسط Git for Windows یا Eclipse). در چنین
           حالتی ممکن است لازم باشد این متغیر روی false تنظیم شود. به git-
           update-index(1) مراجعه کنید.

           مقدار پیش‌فرض true است (زمانی که core.filemode در فایل پیکربندی مشخص
           نشده باشد).

       core.hideDotFiles
           (فقط ویندوز) اگر true باشد، پوشه‌ها و فایل‌های تازه‌ایجادشده را که نام
           آن‌ها با نقطه آغاز می‌شود به عنوان پنهان علامت‌گذاری می‌کند. اگر
           dotGitOnly باشد، تنها پوشه .git/ پنهان می‌شود، اما فایل‌های دیگر که
           با نقطه شروع می‌شوند پنهان نخواهند شد. حالت پیش‌فرض dotGitOnly است.

       core.ignoreCase
           متغیر داخلی که راهکارهای مختلفی را برای کارکرد بهتر Git در سیستم‌های
           فایلی که به بزرگی و کوچکی حروف حساس نیستند (مانند APFS، HFS+، FAT،
           NTFS و غیره) فعال می‌کند. برای مثال، اگر فهرست یک پوشه شامل
           "makefile" باشد در حالی که Git انتظار "Makefile" را دارد، Git فرض
           می‌کند که واقعاً همان فایل است و همچنان آن را به عنوان "Makefile" به
           یاد می‌سپارد.

           پیش‌فرض false است، به جز اینکه git-clone(1) یا git-init(1) هنگام
           ایجاد مخزن، سیستم را بررسی کرده و در صورت لزوم core.ignoreCase را
           روی true تنظیم می‌کنند.

           عملکرد صحیح Git به پیکربندی درست این متغیر متناسب با سیستم عامل و
           سیستم فایل شما وابسته است. تغییر این مقدار ممکن است رفتارهای
           غیرمنتظره‌ای ایجاد کند.

       core.precomposeUnicode
           این گزینه تنها توسط پیاده‌سازی Mac OS از Git استفاده می‌شود. هنگامی
           که core.precomposeUnicode=true باشد، Git تجزیه یونیکد (unicode
           decomposition) نام فایل‌ها را که توسط Mac OS انجام شده به حالت اولیه
           بازمی‌گرداند. این قابلیت هنگام اشتراک‌گذاری یک مخزن میان Mac OS و
           لینوکس یا ویندوز مفید است. (Git for Windows نسخه 1.7.10 یا بالاتر
           مورد نیاز است، یا Git تحت cygwin 1.7). هنگامی که false باشد، نام
           فایل‌ها توسط Git به صورت کاملاً شفاف پردازش می‌شوند که با نسخه‌های
           قدیمی‌تر Git سازگار است.

       core.protectHFS
           اگر روی true تنظیم شود، اجازه چک‌اوت مسیرهایی را که در سیستم فایل
           HFS+ معادل .git محسوب می‌شوند نمی‌دهد. به‌طور پیش‌فرض روی Mac OS برابر
           true و در سایر جاها false است.

       core.protectNTFS
           اگر روی true تنظیم شود، اجازه چک‌اوت مسیرهایی را که ممکن است در
           سیستم فایل NTFS مشکلاتی ایجاد کنند (مانند تداخل با نام‌های "کوتاه"
           8.3) نمی‌دهد. به‌طور پیش‌فرض در ویندوز برابر true و در سایر جاها false
           است.

       core.fsmonitor
           اگر روی true تنظیم شود، دیمن پایشگر داخلی سیستم فایل را برای این
           درخت کاری فعال می‌کند (git-fsmonitor--daemon(1)).

           همانند پایشگرهای سیستم فایل مبتنی بر هوک، پایشگر داخلی سیستم فایل
           می‌تواند سرعت دستورات Git را که نیاز به تازه‌سازی ایندکس Git دارند
           (مانند git status) در یک درخت کاری با فایل‌های پرتعداد افزایش دهد.
           پایشگر داخلی نیاز به نصب و نگهداری یک ابزار خارجی شخص ثالث را برطرف
           می‌کند.

           پایشگر داخلی سیستم فایل در حال حاضر فقط روی پلتفرم‌های پشتیبانی‌شده
           محدودی در دسترس است. در حال حاضر این پلتفرم‌ها شامل Windows و MacOS
           هستند.

           در غیر این صورت، این متغیر شامل مسیر دستور هوک "fsmonitor" است.

           این دستور هوک برای شناسایی تمام فایل‌هایی که ممکن است از تاریخ/زمان
           درخواستی تغییر کرده باشند استفاده می‌شود. این اطلاعات برای افزایش
           سرعت git از طریق اجتناب از اسکن غیرضروری فایل‌هایی که تغییر نکرده‌اند
           به کار می‌رود.

           به بخش "fsmonitor-watchman" از githooks(5) مراجعه کنید.

           توجه داشته باشید که اگر همزمان از چند نسخه Git استفاده می‌کنید
           (مانند یک نسخه در خط فرمان و نسخه دیگر در یک ابزار IDE)، تعریف
           core.fsmonitor گسترش یافته تا علاوه بر مسیرهای هوک، مقادیر بولی را
           نیز بپذیرد. نسخه‌های Git 2.35.1 و قبل از آن، مقادیر بولی را متوجه
           نمی‌شوند و مقادیر "true" یا "false" را به عنوان مسیر هوکی که باید
           اجرا شود در نظر می‌گیرند. نسخه‌های Git بین 2.26 تا 2.35.1 به‌طور
           پیش‌فرض از پروتکل هوک V2 استفاده می‌کنند و به حالت بدون fsmonitor
           (اسکن کامل) بازمی‌گردند. نسخه‌های Git قبل از 2.26 به‌طور پیش‌فرض از
           پروتکل هوک V1 استفاده می‌کنند و بدون هشدار فرض می‌کنند هیچ تغییری
           برای گزارش وجود ندارد (بدون اسکن)، بنابراین دستورات status ممکن است
           نتایج ناقص گزارش کنند. به همین دلیل، بهتر است پیش از استفاده از
           پایشگر داخلی سیستم فایل، تمام نسخه‌های Git خود را ارتقا دهید.

       core.fsmonitorHookVersion
           نسخه پروتکل مورد استفاده هنگام فراخوانی هوک "fsmonitor" را تعیین
           می‌کند.

           در حال حاضر نسخه‌های 1 و 2 وجود دارند. هنگامی که این تنظیم نشده
           باشد، ابتدا نسخه 2 امتحان می‌شود و اگر با شکست مواجه شد، نسخه 1
           امتحان خواهد شد. نسخه 1 از یک برچسب زمانی به عنوان ورودی برای تعیین
           فایل‌هایی که از آن زمان تغییر کرده‌اند استفاده می‌کند، اما برخی
           پایشگرها مانند Watchman در صورت استفاده با برچسب زمانی دچار شرایط
           رقابتی (race conditions) می‌شوند. نسخه 2 از یک رشته مات (opaque
           string) استفاده می‌کند تا پایشگر بتواند چیزی را بازگرداند که بتوان
           از آن برای تعیین فایل‌های تغییریافته بدون شرایط رقابتی استفاده کرد.

       core.trustctime
           اگر false باشد، تفاوت‌های ctime بین ایندکس و درخت کاری نادیده گرفته
           می‌شوند؛ زمانی مفید است که زمان تغییر inode مرتباً توسط چیزی خارج از
           Git (خزنده‌های سیستم فایل و برخی سیستم‌های پشتیبان‌گیری) تغییر داده
           می‌شود. به git-update-index(1) مراجعه کنید. به‌طور پیش‌فرض true است.

       core.splitIndex
           اگر true باشد، از ویژگی split-index در ایندکس استفاده خواهد شد. به
           git-update-index(1) مراجعه کنید. به‌طور پیش‌فرض false است.

       core.untrackedCache
           تعیین می‌کند که با ویژگی حافظه موقت ردیابی‌نشده در ایندکس چه رفتاری
           شود. اگر این متغیر تنظیم نشده باشد یا روی keep تنظیم گردد، حفظ
           خواهد شد. اگر روی true تنظیم شود، به‌طور خودکار اضافه خواهد شد. و
           اگر روی false تنظیم شود، به‌طور خودکار حذف خواهد شد. پیش از تنظیم آن
           روی true، باید بررسی کنید که mtime در سیستم شما به درستی کار می‌کند.
           به git-update-index(1) مراجعه کنید. به‌طور پیش‌فرض keep است، مگر
           اینکه feature.manyFiles فعال باشد که این تنظیم را به‌طور پیش‌فرض روی
           true قرار می‌دهد.

       core.checkStat
           هنگامی که وجود نداشته باشد یا روی default تنظیم شده باشد، بسیاری از
           فیلدهای ساختار stat بررسی می‌شوند تا مشخص شود آیا فایلی از زمان
           بررسی توسط Git تغییر کرده است یا خیر. هنگامی که این متغیر پیکربندی
           روی minimal تنظیم شود، بخش زیرثانیه‌ای mtime و ctime، شناسه‌های uid و
           gid مالک فایل، شماره inode (و شماره دستگاه، در صورتی که Git طوری
           کامپایل شده باشد که از آن استفاده کند)، از میان این فیلدها از بررسی
           مستثنی می‌شوند، و تنها بخش ثانیه کامل mtime (و ctime، در صورتی که
           core.trustCtime تنظیم شده باشد) و اندازه فایل برای بررسی باقی
           می‌مانند.

           پیاده‌سازی‌هایی از Git وجود دارند که مقادیر قابل استفاده‌ای در برخی
           فیلدها باقی نمی‌گذارند (مانند JGit)؛ با مستثنی کردن این فیلدها از
           مقایسه، حالت minimal ممکن است به سازگاری متقابل هنگام استفاده
           همزمان از همان مخزن توسط این سیستم‌های دیگر کمک کند.

       core.quotePath
           دستوراتی که مسیرها را در خروجی نمایش می‌دهند (مانند ls-files، diff)،
           نویسه‌های «غیرعادی» را در نام مسیر با قرار دادن مسیر در گیومه دوتایی
           (double-quotes) و اسکیپ کردن آن نویسه‌ها با بک‌اسلش به همان روشی که C
           نویسه‌های کنترلی را اسکیپ می‌کند (مانند \t برای TAB، \n برای LF، \\
           برای بک‌اسلش) یا بایت‌هایی با مقادیر بزرگتر از 0x80 (مانند هشت‌هشتی
           \302\265 برای "micro" در UTF-8) نقل‌قول می‌کنند. اگر این متغیر روی
           false تنظیم شود، بایت‌های بالاتر از 0x80 دیگر «غیرعادی» در نظر گرفته
           نمی‌شوند. گیومه‌ها، بک‌اسلش و نویسه‌های کنترلی صرف‌نظر از مقدار این
           متغیر همیشه اسکیپ می‌شوند. نویسه فاصله ساده «غیرعادی» تلقی نمی‌شود.
           بسیاری از دستورات می‌توانند با استفاده از گزینه -z نام مسیرها را
           کاملاً دست‌نخورده در خروجی نمایش دهند. مقدار پیش‌فرض true است.

       core.eol
           نوع پایان خط را برای استفاده در درخت کاری جهت فایل‌هایی که به عنوان
           متن علامت‌گذاری شده‌اند (خواه از طریق تنظیم بودن صفت text، یا داشتن
           text=auto و تشخیص خودکار محتویات به عنوان متن توسط Git) مشخص می‌کند.
           گزینه‌ها عبارتند از lf، crlf و native، که از پایان خط بومی پلتفرم
           استفاده می‌کند. مقدار پیش‌فرض native است. برای اطلاعات بیشتر درباره
           تبدیل پایان خط به gitattributes(5) مراجعه کنید. توجه داشته باشید که
           اگر core.autocrlf روی true یا input تنظیم شده باشد، این مقدار
           نادیده گرفته می‌شود.

       core.safecrlf
           اگر true باشد، Git بررسی می‌کند که آیا تبدیل CRLF هنگام فعال بودن
           تبدیل پایان خط برگشت‌پذیر است یا خیر. Git بررسی خواهد کرد که آیا
           دستوری، فایلی را در درخت کاری چه به طور مستقیم و چه غیرمستقیم تغییر
           می‌دهد یا خیر. برای مثال، کامیت کردن یک فایل و سپس چک‌اوت کردن همان
           فایل باید همان فایل اصلی را در درخت کاری ایجاد کند. اگر برای تنظیم
           فعلی core.autocrlf چنین نباشد، Git فایل را رد خواهد کرد. متغیر
           می‌تواند روی "warn" تنظیم شود، که در این حالت Git تنها درباره تبدیل
           برگشت‌ناپذیر هشدار می‌دهد اما عملیات را ادامه خواهد داد.

           تبدیل CRLF خطر اندکی برای خراب کردن داده‌ها به همراه دارد. هنگامی که
           فعال است، Git در حین کامیت CRLF را به LF و در حین چک‌اوت LF را به
           CRLF تبدیل می‌کند. فایلی که قبل از کامیت حاوی ترکیبی از LF و CRLF
           باشد، توسط Git قابل بازسازی نیست. برای فایل‌های متنی این کار مناسبی
           است: پایان خطوط را اصلاح می‌کند تا تنها پایان خطوط LF در مخزن داشته
           باشیم. اما برای فایل‌های باینری که تصادفاً به عنوان متن طبقه‌بندی
           شده‌اند، تبدیل می‌تواند داده‌ها را تخریب کند.

           اگر چنین خرابی را زود تشخیص دهید، می‌توانید به سادگی با تعیین نوع
           تبدیل به طور صریح در .gitattributes آن را برطرف کنید. درست پس از
           کامیت کردن، هنوز فایل اصلی را در درخت کاری خود دارید و این فایل
           هنوز آسیب ندیده است. می‌توانید صریحاً به Git بگویید که این فایل
           باینری است و Git به درستی با فایل رفتار خواهد کرد.

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

           توجه داشته باشید، این بررسی ایمنی بدان معنا نیست که یک چک‌اوت فایلی
           همسان با فایل اصلی برای یک تنظیم متفاوت از core.eol و core.autocrlf
           تولید کند، بلکه تنها برای تنظیم فعلی صادق است. برای مثال، یک فایل
           متنی با LF تحت core.eol=lf پذیرفته می‌شود و ممکن است بعداً با
           core.eol=crlf چک‌اوت شود، که در این صورت فایل حاصل شامل CRLF خواهد
           بود، هرچند فایل اصلی شامل LF بوده است. با این حال، در هر دو درخت
           کاری پایان خطوط یکدست خواهد بود؛ یعنی یا همگی LF یا همگی CRLF، اما
           هرگز ترکیبی نخواهد بود. فایلی با پایان خطوط مختلط توسط سازوکار
           core.safecrlf گزارش خواهد شد.

       core.autocrlf
           تنظیم این متغیر روی "true" همانند تنظیم صفت text روی "auto" برای
           تمام فایل‌ها و تنظیم core.eol روی "crlf" است. اگر می‌خواهید پایان
           خطوط CRLF را در دایرکتوری کاری خود داشته باشید در حالی که مخزن
           دارای پایان خطوط LF است، آن را روی true تنظیم کنید. این متغیر
           می‌تواند روی input تنظیم شود، که در این حالت هیچ تبدیلی در خروجی
           صورت نمی‌پذیرد.

       core.checkRoundtripEncoding
           فهرستی از رمزگذاری‌ها که با کاما یا نویسه فاصله از هم جدا شده‌اند و
           در صورتی که در صفت working-tree-encoding استفاده شوند (به
           gitattributes(5) مراجعه کنید)، Git بررسی رفت‌وبرگشت به UTF-8 را روی
           آن‌ها انجام می‌دهد. مقدار پیش‌فرض SHIFT-JIS است.

       core.symlinks
           اگر false باشد، پیوندهای نمادین به صورت فایل‌های متنی ساده و کوچکی
           که شامل متن پیوند هستند چک‌اوت می‌شوند. دستورات git-update-index(1) و
           git-add(1) نوع ثبت‌شده را به فایل معمولی تغییر نخواهند داد. در
           سیستم‌های فایلی مانند FAT که از پیوندهای نمادین پشتیبانی نمی‌کنند
           مفید است.

           مقدار پیش‌فرض true است، به جز اینکه git-clone(1) یا git-init(1)
           هنگام ایجاد مخزن، وضعیت را بررسی کرده و در صورت لزوم core.symlinks
           را روی false تنظیم می‌کنند.

       core.gitProxy
           یک «دستور پروکسی» برای اجرا (به صورت command host port) به جای
           برقراری ارتباط مستقیم با سرور ریموت هنگام استفاده از پروتکل Git
           برای واکشی (fetch). اگر مقدار متغیر در قالب "COMMAND for DOMAIN"
           باشد، دستور تنها روی نام‌های میزبانی اعمال می‌شود که به رشته دامنه
           مشخص‌شده ختم می‌شوند. این متغیر ممکن است چندین بار تنظیم شود و به
           ترتیب داده‌شده تطبیق داده می‌شود؛ اولین تطابق برنده است.

           می‌تواند توسط متغیر محیطی GIT_PROXY_COMMAND (که همیشه به طور سراسری
           و بدون رفتار خاص "for" اعمال می‌شود) بازنویسی شود.

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

       core.sshCommand
           اگر این متغیر تنظیم شود، git fetch و git push هنگامی که نیاز به
           اتصال به یک سیستم ریموت دارند، از دستور مشخص‌شده به جای ssh استفاده
           خواهند کرد. این دستور در همان قالب متغیر محیطی GIT_SSH_COMMAND است
           و هنگام تنظیم بودن آن متغیر محیطی، اولویت با متغیر محیطی خواهد بود.

       core.ignoreStat
           اگر true باشد، Git با تنظیم بیت "assume-unchanged" برای آن دسته از
           فایل‌های ردیابی‌شده‌ای که آن‌ها را به طور یکسان در هر دو بخش ایندکس و
           درخت کاری به‌روزرسانی کرده است، از فراخوانی‌های lstat() برای تشخیص
           اینکه آیا فایل‌ها تغییر کرده‌اند خودداری می‌کند.

           هنگامی که فایل‌ها خارج از Git تغییر می‌یابند، کاربر باید فایل‌های
           تغییریافته را صریحاً استیج کند (مثلاً به بخش Examples در git-update-
           index(1) مراجعه کنید). Git معمولاً تغییرات این فایل‌ها را تشخیص
           نخواهد داد.

           این امر در سیستم‌هایی که فراخوانی‌های lstat() در آن‌ها بسیار کند است،
           مانند CIFS/Microsoft Windows مفید است.

           به‌طور پیش‌فرض false است.

       core.preferSymlinkRefs
           به جای قالب پیش‌فرض "symref" برای HEAD و سایر فایل‌های ارجاع نمادین،
           از پیوندهای نمادین استفاده می‌کند. این قابلیت گاهی برای کار با
           اسکریپت‌های قدیمی که انتظار دارند HEAD یک پیوند نمادین باشد مورد
           نیاز است.

           این پیکربندی منسوخ شده است و در Git 3.0 حذف خواهد شد. ارجاع‌های
           نمادین همواره به صورت symref متنی نوشته خواهند شد.

       core.alternateRefsCommand
           هنگام اعلان نوک‌های تاریخچه در دسترس از یک منبع جایگزین (alternate)،
           به جای git-for-each-ref(1) از پوسته برای اجرای دستور مشخص‌شده
           استفاده می‌کند. نخستین آرگومان مسیر مطلق منبع جایگزین است. خروجی
           باید شامل یک شناسه شیء هگزادسیمال در هر خط باشد (یعنی مشابه آنچه
           توسط git for-each-ref --format='%(objectname)' تولید می‌شود).

           توجه داشته باشید که عموماً نمی‌توانید git for-each-ref را مستقیماً در
           مقدار پیکربندی قرار دهید، زیرا مسیر مخزن را به عنوان آرگومان
           نمی‌پذیرد (اما می‌توانید دستور بالا را در یک اسکریپت شل کپسوله‌سازی
           کنید).

       core.alternateRefsPrefixes
           هنگام فهرست کردن ارجاع‌ها از یک منبع جایگزین، تنها ارجاع‌هایی را
           فهرست کن که با پیشوند داده‌شده شروع می‌شوند. پیشوندها همان‌گونه تطبیق
           داده می‌شوند که گویی به عنوان آرگومان به git-for-each-ref(1) داده
           شده‌اند. برای فهرست کردن چندین پیشوند، آن‌ها را با فاصله جدا کنید.
           اگر core.alternateRefsCommand تنظیم شده باشد، تنظیم
           core.alternateRefsPrefixes هیچ اثری ندارد.

       core.bare
           اگر true باشد، این مخزن به صورت bare (مخزن فاقد درخت کاری) فرض
           می‌شود و هیچ دایرکتوری کاری مرتبط با آن وجود ندارد. در این حالت
           تعدادی از دستوراتی که به دایرکتوری کاری نیاز دارند غیرفعال خواهند
           شد، مانند git-add(1) یا git-merge(1).

           این تنظیم به‌طور خودکار توسط git-clone(1) یا git-init(1) هنگام ایجاد
           مخزن حدس زده می‌شود. به‌طور پیش‌فرض مخزنی که به "/.git" ختم می‌شود غیر
           bare فرض می‌شود (bare = false)، در حالی که سایر مخازن به صورت bare
           فرض می‌شوند (bare = true).

       core.worktree
           مسیر ریشه درخت کاری را تنظیم می‌کند. اگر متغیر محیطی GIT_COMMON_DIR
           تنظیم شده باشد، core.worktree نادیده گرفته شده و برای تعیین ریشه
           درخت کاری استفاده نخواهد شد. این مقدار می‌تواند توسط متغیر محیطی
           GIT_WORK_TREE و گزینه خط فرمان --work-tree لغو شود. مقدار می‌تواند
           یک مسیر مطلق یا نسبی نسبت به مسیر پوشه .git باشد، که یا توسط
           --git-dir یا GIT_DIR مشخص شده، یا به‌طور خودکار شناسایی شده است. اگر
           --git-dir یا GIT_DIR مشخص شده باشد اما هیچ‌کدام از گزینه‌های
           --work-tree، GIT_WORK_TREE و core.worktree مشخص نشده باشند،
           دایرکتوری کاری فعلی به عنوان بالاترین سطح درخت کاری شما در نظر
           گرفته می‌شود.

           توجه داشته باشید که این متغیر حتی زمانی که در یک فایل پیکربندی در
           یک زیرپوشه ".git" از یک پوشه تنظیم شده باشد و مقدار آن با پوشه اخیر
           متفاوت باشد (مثلاً "/path/to/.git/config" مقدار core.worktree را روی
           "/different/path" تنظیم کرده باشد) رعایت می‌شود، که به احتمال زیاد
           یک پیکربندی نادرست است. اجرای دستورات Git در پوشه "/path/to" همچنان
           از "/different/path" به عنوان ریشه درخت کاری استفاده خواهد کرد و
           می‌تواند باعث سردرگمی شود مگر اینکه بدانید چه می‌کنید (مثلاً در حال
           ایجاد یک تصویر لحظه‌ای فقط‌خواندنی از همان ایندکس در مکانی متفاوت از
           درخت کاری معمول مخزن هستید).

       core.lockfilePid
           اگر true باشد، Git یک فایل PID در کنار فایل‌های قفل ایجاد می‌کند.
           هنگامی که گرفتن قفل با شکست مواجه شود و یک فایل PID وجود داشته
           باشد، Git می‌تواند اطلاعات تشخیصی بیشتری درباره فرآیندی که قفل را در
           اختیار دارد ارائه دهد، از جمله اینکه آیا هنوز در حال اجرا است یا
           خیر. به‌طور پیش‌فرض false است.

           فایل PID با درج ~pid قبل از پسوند .lock نام‌گذاری می‌شود. برای مثال،
           اگر فایل قفل index.lock باشد، فایل PID با نام index~pid.lock خواهد
           بود. این فایل شامل یک خط به قالب pid <value> به همراه یک سطر تازه
           است.

       core.logAllRefUpdates
           فعال‌سازی reflog. به‌روزرسانی‌های یک ارجاع <ref> با الحاق کردن SHA-1
           جدید و قدیم، تاریخ/زمان و دلیل به‌روزرسانی در فایل
           "$GIT_DIR/logs/<ref>" ثبت می‌شوند، اما تنها در صورتی که فایل وجود
           داشته باشد. اگر این متغیر پیکربندی روی true تنظیم شده باشد، فایل
           مفقود "$GIT_DIR/logs/<ref>" به‌طور خودکار برای نوک شاخه‌ها (یعنی زیر
           refs/heads/)، ارجاع‌های ریموت (یعنی زیر refs/remotes/)، ارجاع‌های
           یادداشت (یعنی زیر refs/notes/) و ارجاع نمادین HEAD ایجاد می‌شود. اگر
           روی always تنظیم شود، یک reflog مفقود به‌طور خودکار برای هر ارجاعی
           زیر refs/ ایجاد خواهد شد.

           این اطلاعات می‌تواند برای تعیین اینکه چه کامیتی نوک یک شاخه در "2
           روز پیش" بوده است استفاده شود.

           این مقدار به‌طور پیش‌فرض در مخزنی که دارای درخت کاری مرتبط باشد true،
           و به‌طور پیش‌فرض در یک مخزن bare برابر false است.

       core.repositoryFormatVersion
           متغیر داخلی برای شناسایی قالب مخزن و نسخه چیدمان. به gitrepository-
           layout(5) مراجعه کنید.

       core.sharedRepository
           هنگامی که روی group (یا true) تنظیم شود، مخزن میان چندین کاربر در
           یک گروه قابل اشتراک‌گذاری می‌شود (با اطمینان از اینکه تمامی فایل‌ها و
           اشیاء توسط گروه قابل نوشتن باشند). هنگامی که روی all (یا world یا
           everybody) تنظیم شود، مخزن علاوه بر اشتراک‌گذاری گروهی، برای همه
           کاربران قابل خواندن خواهد بود. هنگامی که روی umask (یا false) تنظیم
           شود، Git از دسترسی‌های گزارش‌شده توسط umask(2) استفاده خواهد کرد.
           هنگامی که روی 0xxx تنظیم شود، که در آن 0xxx یک عدد هشت‌هشتی (octal)
           است، فایل‌های درون مخزن دارای این مقدار حالت (mode) دسترسی خواهند
           بود.  0xxx مقدار umask کاربر را بازنویسی خواهد کرد (در حالی که
           گزینه‌های دیگر تنها بخش‌های مورد درخواست از مقدار umask کاربر را
           بازنویسی می‌کنند). مثال‌ها: 0660 مخزن را برای مالک و گروه قابل
           خواندن/نوشتن می‌کند، اما برای دیگران غیرقابل دسترس می‌سازد (معادل
           group مگر اینکه umask برای نمونه 0022 باشد).  0640 مخزنی است که
           برای گروه قابل خواندن است اما برای گروه قابل نوشتن نیست. به git-
           init(1) مراجعه کنید. به طور پیش‌فرض False است.

       core.warnAmbiguousRefs
           اگر روی true تنظیم شود، چنانچه نام ref ارسالی شما مبهم باشد و ممکن
           باشد با چندین ref در مخزن مطابقت داشته باشد، Git به شما هشدار خواهد
           داد. به طور پیش‌فرض True است.

       core.compression
           یک عدد صحیح بین -1 تا 9 که سطح فشرده‌سازی پیش‌فرض را مشخص می‌کند.
           مقدار -1 پیش‌فرض zlib است. مقدار 0 به معنای عدم فشرده‌سازی است، و 1
           تا 9 موازنه‌های مختلف میان سرعت/اندازه هستند که 9 کندترین آن‌هاست. در
           صورت تنظیم، این متغیر مقداری پیش‌فرض را برای سایر متغیرهای فشرده‌سازی
           فراهم می‌کند، مانند core.looseCompression و pack.compression.

       core.looseCompression
           یک عدد صحیح بین -1 تا 9 که سطح فشرده‌سازی را برای اشیائی که در یک
           pack file قرار ندارند مشخص می‌کند. مقدار -1 پیش‌فرض zlib است. مقدار 0
           به معنای عدم فشرده‌سازی است، و 1 تا 9 موازنه‌های مختلف میان
           سرعت/اندازه هستند که 9 کندترین آن‌هاست. اگر تنظیم نشود، به طور
           پیش‌فرض مقدار core.compression در نظر گرفته می‌شود. اگر آن هم تنظیم
           نشده باشد، به طور پیش‌فرض 1 (بهترین سرعت) خواهد بود.

       core.packedGitWindowSize
           تعداد بایت‌های یک pack file برای نگاشت (map) در حافظه در یک عملیات
           نگاشت منفرد. اندازه‌های بزرگ‌تر پنجره ممکن است به سیستم شما اجازه
           دهند تعداد کمتری از pack fileهای بزرگ را سریع‌تر پردازش کند.
           اندازه‌های کوچک‌تر پنجره به دلیل افزایش فراخوانی‌ها به مدیر حافظه
           سیستم‌عامل، بر کارایی تأثیر منفی خواهند گذاشت، اما ممکن است هنگام
           دسترسی به تعداد زیادی از pack fileهای بزرگ کارایی را بهبود بخشند.

           اگر NO_MMAP در زمان کامپایل تنظیم شده باشد مقدار پیش‌فرض 1 MiB است،
           در غیر این صورت روی پلتفرم‌های 32 بیتی 32 MiB و روی پلتفرم‌های 64
           بیتی 1 GiB است. این مقدار باید برای همه کاربران/سیستم‌های عامل منطقی
           باشد. احتمالاً نیازی به تغییر این مقدار ندارید.

           پسوندهای واحد متداول شامل k، m، یا g پشتیبانی می‌شوند.

       core.packedGitLimit
           حداکثر تعداد بایت‌ها برای نگاشت همزمان از pack fileها به حافظه. اگر
           Git برای تکمیل یک عملیات نیاز به دسترسی همزمان به بیش از این مقدار
           بایت داشته باشد، نواحی موجود را از حالت نگاشت خارج می‌کند (unmap) تا
           فضای آدرس مجازی را درون فرآیند بازپس گیرد.

           پیش‌فرض روی پلتفرم‌های 32 بیتی 256 MiB و روی پلتفرم‌های 64 بیتی 32 TiB
           (در عمل نامحدود) است. این مقدار باید برای همه کاربران/سیستم‌های عامل
           به جز در بزرگ‌ترین پروژه‌ها معقول باشد. احتمالاً نیازی به تغییر این
           مقدار ندارید.

           پسوندهای واحد متداول شامل k، m، یا g پشتیبانی می‌شوند.

       core.deltaBaseCacheLimit
           حداکثر تعداد بایت به ازای هر ریسه (thread) برای رزرو جهت کش کردن
           اشیاء پایه که ممکن است توسط چندین شیء دلتایی (deltified) مورد ارجاع
           قرار گیرند. با ذخیره کامل اشیاء پایه از حالت فشرده خارج‌شده در یک
           کش، Git قادر است از باز کردن و از حالت فشرده خارج کردن چندباره
           اشیاء پایه پرکاربرد جلوگیری کند.

           پیش‌فرض روی تمامی پلتفرم‌ها 96 MiB است. این مقدار باید برای همه
           کاربران/سیستم‌های عامل به جز در بزرگ‌ترین پروژه‌ها معقول باشد. احتمالاً
           نیازی به تغییر این مقدار ندارید.

           پسوندهای واحد متداول شامل k، m، یا g پشتیبانی می‌شوند.

       core.bigFileThreshold
           اندازه فایل‌هایی که "بزرگ" در نظر گرفته می‌شوند، که همان‌طور که در
           ادامه توضیح داده شده رفتار دستورات متعدد گیت و همچنین نحوه
           ذخیره‌سازی چنین فایل‌هایی را در مخزن تغییر می‌دهد. مقدار پیش‌فرض 512
           MiB است. پسوندهای واحد متداول شامل k، m، یا g پشتیبانی می‌شوند.

           فایل‌های بالاتر از حد پیکربندی‌شده:

           •   به صورت فشرده‌شده (deflated) در packfileها بدون تلاش برای
               فشرده‌سازی دلتا ذخیره می‌شوند.

               حد پیش‌فرض اساساً با در نظر گرفتن این کاربرد تنظیم شده است. با
               این تنظیم، در اکثر پروژه‌ها کد منبع و سایر فایل‌های متنی تحت
               فشرده‌سازی دلتا قرار می‌گیرند، اما فایل‌های چندرسانه‌ای باینری
               بزرگ‌تر شامل آن نمی‌شوند.

               ذخیره‌سازی فایل‌های بزرگ بدون فشرده‌سازی دلتا از مصرف بیش از حد
               حافظه جلوگیری می‌کند، هرچند با هزینه اندک افزایش مصرف دیسک همراه
               است.

           •   طوری رفتار خواهد شد که گویی برچسب "binary" دارند (به
               gitattributes(5) مراجعه کنید). برای نمونه git-log(1) و git-
               diff(1) برای فایل‌های بالاتر از این حد، دیف محاسبه نخواهند کرد.

           •   عموماً هنگام نوشتن به صورت جریانی (streamed) منتقل می‌شوند، که از
               مصرف بیش از حد حافظه با هزینه مقداری سربار ثابت جلوگیری می‌کند.
               دستوراتی که از این قابلیت استفاده می‌کنند شامل git-archive(1)،
               git-fast-import(1)، git-index-pack(1)، git-unpack-objects(1) و
               git-fsck(1) هستند.

       core.excludesFile
           مسیر فایلی را مشخص می‌کند که علاوه بر .gitignore (به ازای هر
           دایرکتوری) و .git/info/exclude، حاوی الگوهایی برای توصیف مسیرهایی
           است که نباید ردگیری شوند. مقدار پیش‌فرض آن
           $XDG_CONFIG_HOME/git/ignore است. اگر $XDG_CONFIG_HOME تنظیم نشده یا
           خالی باشد، $HOME/.config/git/ignore به جای آن استفاده می‌شود. به
           gitignore(5) مراجعه کنید.

       core.askPass
           به برخی از دستورات (مانند رابط‌های svn و http) که به صورت تعاملی
           گذرواژه درخواست می‌کنند می‌توان اعلام کرد از یک برنامه خارجی که از
           طریق مقدار این متغیر مشخص شده است استفاده کنند. این مقدار می‌تواند
           توسط متغیر محیطی GIT_ASKPASS بازنویسی شود. در صورت عدم تنظیم، به
           مقدار متغیر محیطی SSH_ASKPASS یا در صورت نبود آن، به یک اعلان ساده
           گذرواژه برمی‌گردد. به برنامه خارجی باید یک اعلان مناسب به عنوان
           آرگومان خط فرمان داده شود و گذرواژه را در STDOUT خود بنویسد.

       core.attributesFile
           مسیر فایلی را مشخص می‌کند که علاوه بر .gitattributes (به ازای هر
           دایرکتوری) و .git/info/attributes، حاوی مشخصه‌ها (attributes) است
           (به gitattributes(5) مراجعه کنید). مقدار پیش‌فرض آن
           $XDG_CONFIG_HOME/git/attributes است. اگر $XDG_CONFIG_HOME تنظیم
           نشده یا خالی باشد، $HOME/.config/git/attributes به جای آن استفاده
           می‌شود.

       core.hooksPath
           به طور پیش‌فرض، Git قلاب‌های شما را در دایرکتوری $GIT_DIR/hooks جستجو
           می‌کند. این متغیر را روی مسیر متفاوتی تنظیم کنید، برای نمونه
           /etc/git/hooks، و Git تلاش خواهد کرد قلاب‌های شما را در آن دایرکتوری
           پیدا کند، برای نمونه /etc/git/hooks/pre-receive به جای
           $GIT_DIR/hooks/pre-receive.

           مسیر می‌تواند مطلق یا نسبی باشد. یک مسیر نسبی، نسبت به دایرکتوری که
           قلاب‌ها در آن اجرا می‌شوند در نظر گرفته می‌شود (به بخش "DESCRIPTION"
           در githooks(5) مراجعه کنید).

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

           همچنین می‌توانید تمام قلاب‌ها را با تنظیم core.hooksPath روی
           /dev/null به طور کامل غیرفعال کنید. این کار معمولاً تنها برای
           کاربران حرفه‌ای و به صورت به ازای هر دستور با استفاده از پارامترهای
           پیکربندی به فرم git -c core.hooksPath=/dev/null .... توصیه می‌شود.

       core.editor
           دستوراتی مانند commit و tag که به شما امکان می‌دهند با اجرای یک
           ویرایشگر پیام‌ها را ویرایش کنید، در صورتی که این متغیر تنظیم شده
           باشد و متغیر محیطی GIT_EDITOR تنظیم نشده باشد، از مقدار این متغیر
           استفاده می‌کنند. به git-var(1) مراجعه کنید.

       core.commentChar, core.commentString
           دستوراتی مانند commit و tag که به شما امکان ویرایش پیام‌ها را
           می‌دهند، خطی را که با این نویسه آغاز شود به عنوان کامنت در نظر گرفته
           و پس از بسته شدن ویرایشگر آن‌ها را حذف می‌کنند (پیش‌فرض #).

           اگر روی "auto" تنظیم شود، git-commit نویسه‌ای را انتخاب خواهد کرد که
           نویسه ابتدایی هیچ‌یک از خطوط در پیام‌های کامیت موجود نباشد. پشتیبانی
           از این مقدار منسوخ شده است و در Git 3.0 به دلیل محدودیت‌های زیر حذف
           خواهد شد:

           •   با افزودن کامنت‌ها در یک الگوی پیام کامیت ناسازگار است. این شامل
               کامنت‌های تعارض که توسط cherry-pick، merge، rebase و revert به
               پیام کامیت اضافه می‌شوند نیز می‌شود.

           •   با افزودن کامنت‌ها به پیام کامیت در قلاب prepare-commit-msg
               ناسازگار است.

           •   هنگام rebase کردن با دستورات fixup و squash ناسازگار است،

           •   توسط git notes رعایت نمی‌شود

           توجه داشته باشید که این دو متغیر نام‌های مستعار (alias) یکدیگر
           هستند، و در نسخه‌های مدرن Git آزادید که از یک رشته (برای نمونه // یا
           ⁑⁕⁑) با commentChar استفاده کنید. نسخه‌های قبل از v2.45.0 گیت متغیر
           commentString را نادیده می‌گیرند اما مقداری از commentChar را که
           شامل بیش از یک بایت اسکی باشد رد می‌کنند. اگر قصد دارید از پیکربندی
           خود هم با نسخه‌های قدیمی‌تر و هم جدیدتر Git استفاده کنید، ممکن است
           مایل باشید هر دو را مشخص کنید:

               [core]
               # single character for older versions
               commentChar = "#"
               # string for newer versions (which will override commentChar
               # because it comes later in the file)
               commentString = "//"

       core.filesRefLockTimeout
           مدت زمان به میلی‌ثانیه برای تلاش مجدد هنگام تلاش برای قفل کردن یک
           ارجاع (ref) منفرد. مقدار 0 به معنای اصلاً تلاش مجدد نکردن است؛ -1 به
           معنای تلاش نامحدود است. پیش‌فرض 100 است (یعنی تلاش مجدد برای 100
           میلی‌ثانیه).

       core.packedRefsTimeout
           مدت زمان به میلی‌ثانیه برای تلاش مجدد هنگام تلاش برای قفل کردن فایل
           packed-refs.  مقدار 0 به معنای اصلاً تلاش مجدد نکردن است؛ -1 به
           معنای تلاش نامحدود است. پیش‌فرض 1000 است (یعنی تلاش مجدد برای 1
           ثانیه).

       core.pager
           نمایش‌دهنده متن (pager) برای استفاده توسط دستورات گیت (برای نمونه
           less).  این مقدار برای تفسیر شدن توسط شل در نظر گرفته شده است.
           ترتیب اولویت عبارت است از متغیر محیطی $GIT_PAGER، سپس پیکربندی
           core.pager، سپس $PAGER، و سپس پیش‌فرض انتخاب‌شده در زمان کامپایل
           (معمولاً less).

           زمانی که متغیر محیطی LESS تنظیم نشده باشد، Git آن را روی FRX تنظیم
           می‌کند (اگر متغیر محیطی LESS تنظیم شده باشد، Git اصلاً آن را تغییر
           نمی‌دهد). اگر می‌خواهید تنظیم پیش‌فرض Git برای LESS را به صورت انتخابی
           لغو کنید، می‌توانید core.pager را برای نمونه روی less -S تنظیم کنید.
           این مقدار توسط Git به شل منتقل می‌شود، که دستور نهایی را به LESS=FRX
           less -S ترجمه خواهد کرد. محیط گزینه S را تنظیم نکرده اما خط فرمان
           این کار را انجام می‌دهد، که به less دستور می‌دهد خطوط طولانی را کوتاه
           (truncate) کند. به طور مشابه، تنظیم core.pager روی less -+F گزینه F
           مشخص‌شده توسط محیط را از طریق خط فرمان غیرفعال می‌کند، که رفتار "خروج
           در صورت جا شدن در یک صفحه" در less را غیرفعال می‌سازد. می‌توان برخی
           گزینه‌ها را به طور اختصاصی برای دستورات خاصی فعال کرد: برای مثال،
           تنظیم pager.blame روی less -S کوتاه‌سازی خطوط را تنها برای git blame
           فعال می‌سازد.

           به همین شکل، زمانی که متغیر محیطی LV تنظیم نشده باشد، Git آن را روی
           -c تنظیم می‌کند. می‌توانید این تنظیم را با export کردن LV با مقداری
           دیگر یا با تنظیم core.pager روی lv +c لغو کنید.

       core.whitespace
           فهرستی جداشده با کاما از مشکلات رایج فاصله خالی (whitespace) برای
           بررسی و جلب توجه.  git diff از color.diff.whitespace برای
           برجسته‌سازی آن‌ها استفاده می‌کند، و git apply --whitespace=error آن‌ها
           را به عنوان خطا در نظر می‌گیرد. می‌توانید پیشوند - را برای غیرفعال
           کردن هر یک از آن‌ها به کار ببرید (برای نمونه -trailing-space):

           •   blank-at-eol فاصله‌های خالی انتهایی در انتهای خط را به عنوان خطا
               در نظر می‌گیرد (به طور پیش‌فرض فعال است).

           •   space-before-tab نویسه فاصله‌ای را که بلافاصله پیش از یک نویسه
               تب در بخش تورفتگی اولیه خط ظاهر شود به عنوان خطا در نظر می‌گیرد
               (به طور پیش‌فرض فعال است).

           •   indent-with-non-tab خطی را که به جای تب‌های معادل با نویسه‌های
               فاصله تورفته شده باشد به عنوان خطا در نظر می‌گیرد (به طور پیش‌فرض
               فعال نیست).

           •   tab-in-indent نویسه تب در بخش تورفتگی اولیه خط را به عنوان خطا
               در نظر می‌گیرد (به طور پیش‌فرض فعال نیست).

           •   blank-at-eof خطوط خالی اضافه‌شده در انتهای فایل را به عنوان خطا
               در نظر می‌گیرد (به طور پیش‌فرض فعال است).

           •   trailing-space شورت‌کدی برای پوشش دادن هر دو مورد blank-at-eol و
               blank-at-eof است.

           •   cr-at-eol بازگشت به ابتدای خط (carriage-return) در انتهای خط را
               به عنوان بخشی از پایان‌دهنده خط تلقی می‌کند، یعنی با فعال بودن
               آن، اگر نویسه پیش از چنین carriage-return یک فاصله خالی نباشد،
               trailing-space فعال نمی‌شود (به طور پیش‌فرض فعال نیست).

           •   incomplete-line آخرین خط فایلی را که فاقد خط جدید (newline) در
               انتها است به عنوان خطا در نظر می‌گیرد (به طور پیش‌فرض فعال نیست).

           •   tabwidth=<n> مشخص می‌کند که یک تب چند موقعیت نویسه را اشغال
               می‌کند؛ این گزینه برای indent-with-non-tab و زمانی که Git خطاهای
               tab-in-indent را اصلاح می‌کند کاربرد دارد. عرض پیش‌فرض تب 8 است.
               مقادیر مجاز از 1 تا 63 می‌باشند.

       core.fsync
           فهرستی جداشده با کاما از مؤلفه‌های مخزن که باید در زمان ایجاد یا
           تغییر، از طریق core.fsyncMethod پایدارسازی (hardened) شوند.
           می‌توانید پایدارسازی هر مؤلفه را با قرار دادن پیشوند - در ابتدای آن
           غیرفعال کنید. مواردی که پایدارسازی نشده‌اند ممکن است در صورت خاموش
           شدن غیرعادی سیستم از دست بروند. مگر در مواردی که نیازمندی‌های خاصی
           داشته باشید، توصیه می‌شود این گزینه را خالی بگذارید یا یکی از موارد
           committed، added، یا all را انتخاب کنید.

           هنگام مواجهه با این پیکربندی، مجموعه مؤلفه‌ها با مقدار پیش‌فرض پلتفرم
           آغاز می‌شود، مؤلفه‌های غیرفعال حذف می‌شوند، و مؤلفه‌های اضافی افزوده
           می‌گردند.  none وضعیت را بازنشانی می‌کند تا پیش‌فرض پلتفرم نادیده
           گرفته شود.

           رشته خالی پیکربندی fsync را به پیش‌فرض پلتفرم بازنشانی می‌کند. پیش‌فرض
           در اکثر پلتفرم‌ها معادل core.fsync=committed,-loose-object است، که
           کارایی خوبی دارد، اما در صورت خاموش شدن غیرعادی سیستم، خطر از دست
           رفتن کارهای اخیر را به همراه دارد.

           •   none مجموعه مؤلفه‌های تحت fsync را پاک می‌کند.

           •   loose-object اشیائی را که در قالب loose-object به مخزن اضافه
               شده‌اند پایدارسازی می‌کند.

           •   pack اشیائی را که در قالب packfile به مخزن اضافه شده‌اند
               پایدارسازی می‌کند.

           •   pack-metadata بیت‌مپ‌ها و ایندکس‌های packfile را پایدارسازی می‌کند.

           •   commit-graph فایل commit-graph را پایدارسازی می‌کند.

           •   index ایندکس را هنگام تغییر پایدارسازی می‌کند.

           •   objects گزینه‌ای تجمیعی است که معادل loose-object,pack می‌باشد.

           •   reference ارجاع‌های تغییریافته در مخزن را پایدارسازی می‌کند.

           •   derived-metadata گزینه‌ای تجمیعی است که معادل
               pack-metadata,commit-graph می‌باشد.

           •   committed گزینه‌ای تجمیعی است که در حال حاضر معادل objects است.
               این حالت مقداری از کارایی را فدا می‌کند تا اطمینان حاصل شود کاری
               که با git commit یا دستورات مشابه در مخزن کامیت شده است،
               پایدارسازی می‌شود.

           •   added گزینه‌ای تجمیعی است که در حال حاضر معادل committed,index
               است. این حالت کارایی بیشتری را فدا می‌کند تا اطمینان حاصل شود
               نتایج دستوراتی مانند git add و عملیات مشابه پایدارسازی می‌شوند.

           •   all گزینه‌ای تجمیعی است که تمامی مؤلفه‌های منفرد فوق را همگام‌سازی
               (sync) می‌کند.

       core.fsyncMethod
           مقداری که راهبرد Git را برای پایدارسازی داده‌های مخزن با استفاده از
           fsync و دستورات اولیه مرتبط مشخص می‌کند.

           •   fsync از فراخوانی سیستمی fsync() یا معادل‌های آن در پلتفرم
               استفاده می‌کند.

           •   writeout-only درخواست‌های بازنویسی حافظه پنهان صفحه (pagecache
               writeback) را صادر می‌کند، اما بسته به سیستم فایل و سخت‌افزار
               ذخیره‌سازی، داده‌های اضافه‌شده به مخزن ممکن است در صورت وقوع خرابی
               سیستم (crash) پایدار نمانند. این حالت پیش‌فرض در macOS است.

           •   batch حالتی را فعال می‌کند که از تخلیه‌های فقط بازنویسی
               (writeout-only flushes) برای مرحله‌بندی چندین به‌روزرسانی در کش
               بازنویسی دیسک استفاده می‌کند و سپس یک fsync کامل روی یک فایل
               ساختگی انجام می‌دهد تا تخلیه کش دیسک را در پایان عملیات فعال
               سازد.

               در حال حاضر حالت batch تنها برای فایل‌های loose-object اعمال
               می‌شود. سایر داده‌های مخزن به گونه‌ای پایدارسازی می‌شوند که گویی
               fsync مشخص شده است. انتظار می‌رود این حالت روی macOS برای مخازن
               ذخیره‌شده در سیستم‌های فایل HFS+ یا APFS و روی Windows برای مخازن
               ذخیره‌شده در سیستم‌های فایل NTFS یا ReFS به اندازه fsync امن
               باشد.

       core.fsyncObjectFiles
           این متغیر بولی fsync() را هنگام نوشتن فایل‌های شیء فعال می‌کند. این
           تنظیم منسوخ شده است. به جای آن از core.fsync استفاده کنید.

           این تنظیم بر داده‌هایی اثر می‌گذارد که در قالب loose-object به مخزن
           گیت اضافه می‌شوند. در صورت تنظیم روی true، Git یک فراخوانی سیستمی
           fsync یا مشابه آن را برای تخلیه کش‌ها صادر می‌کند تا اشیاء مجزا
           (loose-objects) در مواجهه با خاموش شدن غیرعادی سیستم سازگار باقی
           بمانند.

       core.preloadIndex
           پیش‌بارگذاری موازی ایندکس را برای عملیاتی مانند git diff فعال می‌کند

           این قابلیت می‌تواند به عملیاتی مانند git diff و git status به‌ویژه
           روی سیستم‌های فایلی مانند NFS که معناشناسی ضعیفی در کش کردن دارند و
           بنابراین تأخیر ورودی/خروجی (IO) نسبتاً بالایی دارند، سرعت ببخشد. در
           صورت فعال بودن، Git مقایسه ایندکس با داده‌های سیستم فایل را به صورت
           موازی انجام می‌دهد که امکان همپوشانی عملیات IO را فراهم می‌سازد. به
           طور پیش‌فرض true است.

       core.unsetenvvars
           فقط ویندوز: فهرستی جداشده با کاما از نام‌های متغیرهای محیطی که باید
           پیش از ایجاد هر فرآیند دیگری لغو (unset) شوند. به طور پیش‌فرض روی
           PERL5LIB تنظیم شده است تا این واقعیت را در نظر بگیرد که Git for
           Windows بر استفاده از مفسر پرل اختصاصی خود اصرار دارد.

       core.createObject
           می‌توانید این متغیر را روی link تنظیم کنید، که در این صورت از یک
           پیوند سخت (hardlink) و به دنبال آن حذف مبدا استفاده می‌شود تا
           اطمینان حاصل شود که ایجاد شیء، اشیاء موجود را بازنویسی نخواهد کرد.

           در برخی ترکیب‌های سیستم فایل/سیستم‌عامل، این سازوکار غیرقابل اطمینان
           است. در آنجا این تنظیم پیکربندی را روی rename تنظیم کنید؛ با این
           حال، این کار بررسی اطمینان از بازنویسی نشدن فایل‌های شیء موجود را
           حذف خواهد کرد.

       core.notesRef
           هنگام نمایش پیام‌های کامیت، یادداشت‌هایی (notes) را که در ref داده‌شده
           ذخیره شده‌اند نیز نشان می‌دهد. این ref باید به طور کامل مشخص باشد
           (fully qualified). اگر ref داده‌شده وجود نداشته باشد، خطا به شمار
           نمی‌آید بلکه به این معناست که هیچ یادداشتی نباید چاپ شود.

           این تنظیم به طور پیش‌فرض "refs/notes/commits" است، و می‌تواند توسط
           متغیر محیطی GIT_NOTES_REF بازنویسی شود. به git-notes(1) مراجعه
           کنید.

       core.commitGraph
           اگر روی true تنظیم شود، آنگاه git فایل commit-graph را (در صورت
           وجود) می‌خواند تا ساختار گراف کامیت‌ها را تجزیه کند. به طور پیش‌فرض
           true است. برای اطلاعات بیشتر به git-commit-graph(1) مراجعه کنید.

       core.useReplaceRefs
           اگر روی false تنظیم شود، طوری رفتار می‌کند که گویی گزینه
           --no-replace-objects در خط فرمان داده شده است. برای اطلاعات بیشتر
           به git(1) و git-replace(1) مراجعه کنید.

       core.multiPackIndex
           از فایل multi-pack-index برای ردگیری چندین packfile با استفاده از
           یک ایندکس واحد استفاده می‌کند. برای اطلاعات بیشتر به git-multi-pack-
           index(1) مراجعه کنید. به طور پیش‌فرض true است.

       core.sparseCheckout
           قابلیت "sparse checkout" (دریافت گزینشی/تنک) را فعال می‌کند. برای
           اطلاعات بیشتر به git-sparse-checkout(1) مراجعه کنید.

       core.sparseCheckoutCone
           "حالت مخروطی" (cone mode) قابلیت sparse checkout را فعال می‌کند.
           هنگامی که فایل sparse-checkout شامل مجموعه‌ای محدود از الگوها باشد،
           این حالت مزایای عملکردی قابل‌توجهی ارائه می‌دهد. می‌توان با تنظیم این
           متغیر روی false "حالت غیرمخروطی" را درخواست کرد تا امکان مشخص کردن
           الگوهای انعطاف‌پذیرتر فراهم شود. برای اطلاعات بیشتر به git-sparse-
           checkout(1) مراجعه کنید.

       core.abbrev
           طولی را که نام اشیاء به آن کوتاه می‌شوند تعیین می‌کند. اگر مشخص نشود
           یا روی "auto" تنظیم شود، مقداری مناسب بر اساس تعداد تقریبی اشیاء
           بسته‌بندی‌شده در مخزن شما محاسبه می‌شود، که امیدواریم کافی باشد تا
           نام‌های کوتاه اشیاء برای مدتی یکتا باقی بمانند. اگر روی "no" تنظیم
           شود، هیچ اختصاری صورت نمی‌گیرد و نام اشیاء با طول کامل نمایش داده
           می‌شوند. حداقل طول 4 است.

       core.maxTreeDepth
           حداکثر عمقی که Git مایل است هنگام پیمایش یک درخت وارد بازگشت
           (recurse) شود (برای نمونه، "a/b/cde/f" دارای عمق 4 است). این یک
           تدبیر ایمنی است تا به Git اجازه دهد به طور پاک متوقف شود، و عموماً
           نیازی به تغییر آن نیست. هنگامی که Git با MSVC کامپایل شده باشد،
           مقدار پیش‌فرض 512 است. در غیر این صورت، مقدار پیش‌فرض 2048 است.

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

           توجه داشته باشید که می‌توان چندین دستیار کمکی تعریف کرد. برای جزئیات
           و مثال‌ها به gitcredentials(7) مراجعه کنید.

       credential.interactive
           به طور پیش‌فرض، Git و هر دستیار کمکی اعتبارنامه پیکربندی‌شده، در زمان
           نیاز به اطلاعات هویتی جدید، از کاربر درخواست ورودی می‌کنند. بسیاری
           از این دستیاران در صورتی که اطلاعات هویتی ذخیره‌شده هنوز معتبر
           باشند، بر اساس آن‌ها کار را با موفقیت انجام می‌دهند. برای جلوگیری از
           امکان تعامل با کاربر از سوی Git، مقدار credential.interactive=false
           را تنظیم کنید. برخی دستیاران کمکی اعتبارنامه نیز این گزینه را رعایت
           می‌کنند.

       credential.useHttpPath
           هنگام دریافت اطلاعات هویتی، مؤلفه "path" نشانی اینترنتی http یا
           https را مهم تلقی می‌کند. به طور پیش‌فرض false است. برای اطلاعات
           بیشتر به gitcredentials(7) مراجعه کنید.

       credential.sanitizePrompt
           به طور پیش‌فرض، نام‌های کاربری و میزبان‌هایی که به عنوان بخشی از اعلان
           گذرواژه نمایش داده می‌شوند مجاز به داشتن نویسه‌های کنترلی نیستند
           (آن‌ها به طور پیش‌فرض با کدگذاری URL نمایش می‌یابند). این تنظیم را روی
           false پیکربندی کنید تا این رفتار لغو شود.

       credential.protectProtocol
           به طور پیش‌فرض، نویسه‌های Carriage Return در پروتکلی که هنگام ارتباط
           Git با یک دستیار کمکی اعتبارنامه استفاده می‌شود مجاز نیستند. این
           تنظیم به کاربران امکان می‌دهد این مقدار پیش‌فرض را لغو کنند.

       credential.username
           اگر هیچ نام کاربری برای احراز هویت شبکه تنظیم نشده باشد، به طور
           پیش‌فرض از این نام کاربری استفاده می‌کند. به credential.<context>.*
           در ادامه، و gitcredentials(7) مراجعه کنید.

       credential.<url>.*
           هر یک از گزینه‌های credential.* بالا می‌تواند به صورت انتخابی برای
           برخی اطلاعات هویتی اعمال شود. برای نمونه،
           "credential.https://example.com.username" نام کاربری پیش‌فرض را تنها
           برای اتصالات https به example.com تنظیم می‌کند. برای جزئیات درباره
           نحوه تطبیق URLها، به gitcredentials(7) مراجعه کنید.

       credentialCache.ignoreSIGHUP
           به git-credential-cache—daemon اعلام می‌کند که سیگنال SIGHUP را به
           جای خروج نادیده بگیرد.

       credentialStore.lockTimeoutMS
           مدت زمان به میلی‌ثانیه برای تلاش مجدد git-credential-store هنگام
           تلاش برای قفل کردن فایل اطلاعات هویتی. مقدار 0 به معنای اصلاً تلاش
           مجدد نکردن است؛ -1 به معنای تلاش نامحدود است. پیش‌فرض 1000 است (یعنی
           تلاش مجدد برای 1 ثانیه).

       diff.autoRefreshIndex
           هنگام استفاده از git diff برای مقایسه با فایل‌های درخت کاری، تغییرات
           صرفاً مربوط به stat را به عنوان تغییریافته تلقی نمی‌کند. در عوض، به
           صورت خاموش git update-index --refresh را اجرا می‌کند تا اطلاعات
           کش‌شده stat را برای مسیرهایی که محتوای آن‌ها در درخت کاری با محتوای
           ایندکس مطابقت دارد به‌روزرسانی کند. این گزینه به طور پیش‌فرض true
           است. توجه داشته باشید که این موضوع تنها بر دستورات سطح بالای
           (Porcelain) git diff اثر می‌گذارد، و نه بر دستورات سطح پایین‌تر diff
           مانند git diff-files.

       diff.dirstat
           فهرستی جداشده با کاما از پارامترهای --dirstat که رفتار پیش‌فرض گزینه
           --dirstat را برای git-diff(1) و دستورات مرتبط مشخص می‌کند. مقادیر
           پیش‌فرض را می‌توان در خط فرمان بازنویسی کرد (با استفاده از
           --dirstat=<param>,...).  پیش‌فرض‌های جایگزین (هنگامی که توسط
           diff.dirstat تغییر داده نشده باشند) عبارتند از
           changes,noncumulative,3.  پارامترهای زیر در دسترس هستند:

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

           lines
               اعداد dirstat را با انجام تحلیل معمول دیف مبتنی بر خط، و جمع
               کردن تعداد خطوط حذف‌شده/افزوده‌شده محاسبه می‌کند. (برای فایل‌های
               باینری، به جای آن تکه‌های 64 بایتی شمرده می‌شوند، زیرا فایل‌های
               باینری مفهوم طبیعی از خط ندارند). این رفتار --dirstat گران‌تر از
               رفتار changes است، اما خطوط جابه‌جاشده در یک فایل را به اندازه
               سایر تغییرات به شمار می‌آورد. خروجی حاصل با آنچه از سایر
               گزینه‌های --*stat به دست می‌آورید سازگار است.

           files
               اعداد dirstat را با شمارش تعداد فایل‌های تغییریافته محاسبه
               می‌کند. هر فایل تغییریافته در تحلیل dirstat به یک اندازه به حساب
               می‌آید. این رفتار از نظر محاسباتی کم‌هزینه‌ترین رفتار --dirstat
               است، چرا که اصلاً نیازی به بررسی محتویات فایل ندارد.

           cumulative
               تغییرات در یک دایرکتوری فرزند را برای دایرکتوری والد نیز محاسبه
               می‌کند. توجه داشته باشید که هنگام استفاده از cumulative، مجموع
               درصدهای گزارش‌شده ممکن است از 100% فراتر رود. رفتار پیش‌فرض
               (غیرتراکمی) می‌تواند با پارامتر noncumulative مشخص شود.

           <limit>
               یک پارامتر عدد صحیح که درصد آستانه حذف (به طور پیش‌فرض 3%) را
               مشخص می‌کند. دایرکتوری‌هایی که سهمی کمتر از این درصد از تغییرات
               را دارند در خروجی نشان داده نمی‌شوند.

           مثال: عبارت زیر فایل‌های تغییریافته را می‌شمارد، در حالی که
           دایرکتوری‌های دارای کمتر از 10% از کل مقدار فایل‌های تغییریافته را
           نادیده می‌گیرد، و شمارش دایرکتوری‌های فرزند را در دایرکتوری‌های والد
           تجمیع می‌کند: files,10,cumulative.

       diff.statNameWidth
           عرض بخش نام فایل را در خروجی --stat محدود می‌کند. در صورت تنظیم، بر
           تمامی دستورات تولیدکننده خروجی --stat به جز format-patch اعمال
           می‌شود.

       diff.statGraphWidth
           عرض بخش نمودار را در خروجی --stat محدود می‌کند. در صورت تنظیم، بر
           تمامی دستورات تولیدکننده خروجی --stat به جز format-patch اعمال
           می‌شود.

       diff.context
           دیف‌ها را به جای پیش‌فرض 3، با <n> خط زمینه (context) تولید می‌کند.
           این مقدار توسط گزینه -U بازنویسی می‌شود.

       diff.interHunkContext
           زمینه میان تکه‌های دیف (hunks) را تا تعداد خطوط مشخص‌شده نمایش می‌دهد،
           و بدین ترتیب تکه‌هایی را که نزدیک یکدیگر هستند به هم پیوند می‌دهد.
           این مقدار به عنوان پیش‌فرض برای گزینه خط فرمان --inter-hunk-context
           عمل می‌کند.

       diff.external
           اگر این متغیر پیکربندی تنظیم شود، تولید دیف با استفاده از سازوکار
           داخلی دیف انجام نمی‌شود، بلکه با استفاده از دستور داده‌شده صورت
           می‌گیرد. می‌تواند با متغیر محیطی GIT_EXTERNAL_DIFF بازنویسی شود. این
           دستور با پارامترهایی فراخوانی می‌شود که در بخش "git Diffs" در git(1)
           توضیح داده شده است. نکته: اگر می‌خواهید از یک برنامه دیف خارجی تنها
           برای زیرمجموعه‌ای از فایل‌های خود استفاده کنید، ممکن است بهتر باشد به
           جای آن از gitattributes(5) استفاده کنید.

       diff.trustExitCode
           اگر این مقدار بولی روی true تنظیم شود، آنگاه انتظار می‌رود دستور
           diff.external در صورتی که فایل‌های ورودی را برابر بداند کد خروج 0 و
           اگر آن‌ها را متفاوت بداند کد خروج 1 را برگرداند، مانند diff(1).  اگر
           روی false تنظیم شود، که پیش‌فرض است، آنگاه صرف‌نظر از برابری فایل‌ها،
           از دستور انتظار می‌رود کد خروج 0 را برگرداند. هر کد خروج دیگری باعث
           می‌شود Git یک خطای مهلک گزارش دهد.

       diff.ignoreSubmodules
           مقدار پیش‌فرض --ignore-submodules را تنظیم می‌کند. توجه داشته باشید
           که این موضوع تنها بر دستورات سطح بالای (Porcelain) git diff اثر
           می‌گذارد، و نه بر دستورات سطح پایین‌تر diff مانند git diff-files.
           دستورات git checkout و git switch نیز هنگام گزارش تغییرات کامیت‌نشده
           به این تنظیم احترام می‌گذارند. تنظیم آن روی all خلاصه زیرماژول را که
           معمولاً هنگام تنظیم status.submoduleSummary توسط git commit و git
           status نشان داده می‌شود غیرفعال می‌کند، مگر اینکه با استفاده از گزینه
           خط فرمان --ignore-submodules بازنویسی شود. دستورات git submodule
           تحت تأثیر این تنظیم قرار نمی‌گیرند. به طور پیش‌فرض این مقدار روی
           untracked تنظیم شده است تا هرگونه زیرماژول ردگیری‌نشده نادیده گرفته
           شود.

       diff.mnemonicPrefix
           در صورت تنظیم، git diff بسته به اینکه چه چیزی در حال مقایسه است، از
           یک جفت پیشوند متفاوت با پیشوند استاندارد a/ و b/ استفاده می‌کند.
           هنگامی که این پیکربندی برقرار باشد، خروجی دیف معکوس نیز ترتیب
           پیشوندها را جا‌به‌جا می‌کند:

           git diff
               ایندکس (i) و درخت کاری (w) را مقایسه می‌کند؛

           git diff HEAD
               یک کامیت (c) و درخت کاری (w) را مقایسه می‌کند؛

           git diff --cached
               یک کامیت (c) و ایندکس (i) را مقایسه می‌کند؛

           git diff HEAD:<file1> <file2>
               یک شیء (o) و یک موجودیت درخت کاری (w) را مقایسه می‌کند؛

           git diff --no-index <a> <b>
               دو مورد غیرگیت <a> و <b> را مقایسه می‌کند.

       diff.noPrefix
           در صورت تنظیم، git diff هیچ پیشوند مبدا یا مقصدی را نشان نمی‌دهد.

       diff.srcPrefix
           در صورت تنظیم، git diff از این پیشوند مبدا استفاده می‌کند. پیش‌فرض آن
           a/ است.

       diff.dstPrefix
           در صورت تنظیم، git diff از این پیشوند مقصد استفاده می‌کند. پیش‌فرض آن
           b/ است.

       diff.relative
           اگر روی true تنظیم شود، git diff تغییرات خارج از دایرکتوری را نشان
           نمی‌دهد و نام مسیرها را به صورت نسبی نسبت به دایرکتوری جاری نمایش
           می‌دهد.

       diff.orderFile
           فایلی که نحوه مرتب‌سازی فایل‌ها در یک دیف را مشخص می‌کند. برای جزئیات
           به گزینه -O در git-diff(1) مراجعه کنید. اگر diff.orderFile یک مسیر
           نسبی باشد، به عنوان مسیر نسبی نسبت به ریشه درخت کاری تلقی می‌شود.
           diff.renameLimit
               تعداد فایل‌هایی که در بخش جامع تشخیص کپی/تغییر نام در نظر گرفته
               می‌شوند؛ معادل گزینه -l در git diff.  اگر تنظیم نشود، مقدار
               پیش‌فرض در حال حاضر 1000 است. اگر تشخیص تغییر نام غیرفعال باشد،
               این تنظیم هیچ اثری ندارد.

           diff.renames
               آیا و چگونه Git تغییر نام‌ها را تشخیص می‌دهد. اگر بر روی false
               تنظیم شود، تشخیص تغییر نام غیرفعال می‌شود. اگر بر روی true تنظیم
               شود، تشخیص پایه تغییر نام فعال می‌گردد. اگر بر روی copies یا
               copy تنظیم شود، Git کپی‌ها را نیز تشخیص خواهد داد. پیش‌فرض true
               است. توجه داشته باشید که این مورد تنها بر دستورات سطح بالا
               (Porcelain) git diff مانند git-diff(1) و git-log(1) تأثیر
               می‌گذارد و بر دستورات سطح پایین‌تر مانند git-diff-files(1) اثری
               ندارد.

           diff.suppressBlankEmpty
               یک مقدار بولی برای بازداری از رفتار استاندارد چاپ فاصله (space)
               پیش از هر خط خروجی خالی. پیش‌فرض false است.

           diff.submodule
               قالبی را مشخص می‌کند که تفاوت‌ها در زیرماژول‌ها در آن قالب نمایش
               داده می‌شوند. قالب short فقط نام کامیت‌ها را در ابتدا و انتهای
               بازه نشان می‌دهد. قالب log کامیت‌های موجود در بازه را مانند آنچه
               git-submodule(1) summary انجام می‌دهد فهرست می‌کند. قالب diff یک
               diff درون‌خطی از محتویات تغییریافته زیرماژول را نشان می‌دهد.
               پیش‌فرض short است.

           diff.wordRegex
               یک عبارت باقاعده گسترده POSIX که برای تعیین اینکه هنگام انجام
               محاسبات تفاوت کلمه‌به‌کلمه چه چیزی «کلمه» محسوب می‌شود، استفاده
               می‌گردد. دنباله‌های نویسه‌ای که با عبارت باقاعده مطابقت دارند
               «کلمه» هستند، تمام نویسه‌های دیگر فضای خالی ignorable (قابل
               چشم‌پوشی) در نظر گرفته می‌شوند.

           diff.<driver>.command
               دستور درایور سفارشی diff. برای جزئیات به gitattributes(5)
               مراجعه کنید.

           diff.<driver>.trustExitCode
               اگر این مقدار بولی روی true تنظیم شود، آنگاه انتظار می‌رود دستور
               diff.<driver>.command در صورتی که فایل‌های ورودی را برابر بداند
               کد خروج 0 و در صورتی که آن‌ها را متفاوت بداند کد خروج 1 را
               برگرداند، مانند diff(1).  اگر روی false تنظیم شود که مقدار
               پیش‌فرض است، آنگاه انتظار می‌رود دستور صرف‌نظر از برابری، کد خروج
               0 برگرداند. هر کد خروج دیگری باعث می‌شود Git یک خطای مهلک گزارش
               کند.

           diff.<driver>.xfuncname
               عبارت باقاعده‌ای که درایور diff باید برای تشخیص سرآیند قطعه
               (hunk header) استفاده کند. همچنین می‌توان از یک الگوی توکار
               استفاده کرد. برای جزئیات به gitattributes(5) مراجعه کنید.

           diff.<driver>.binary
               این گزینه را روی true تنظیم کنید تا درایور diff فایل‌ها را به
               عنوان باینری در نظر بگیرد. برای جزئیات به gitattributes(5)
               مراجعه کنید.

           diff.<driver>.textconv
               دستوری که درایور diff باید برای تولید نسخه تبدیل‌شده به متنِ یک
               فایل فراخوانی کند. نتیجه تبدیل برای تولید یک diff خوانا برای
               انسان استفاده می‌شود. برای جزئیات به gitattributes(5) مراجعه
               کنید.

           diff.<driver>.wordRegex
               عبارت باقاعده‌ای که درایور diff باید برای تفکیک کلمات در یک خط
               استفاده کند. برای جزئیات به gitattributes(5) مراجعه کنید.

           diff.<driver>.cachetextconv
               این گزینه را روی true تنظیم کنید تا درایور diff خروجی‌های تبدیل
               متن را کِش کند. برای جزئیات به gitattributes(5) مراجعه کنید.

           diff.indentHeuristic
               این گزینه را روی false تنظیم کنید تا روش‌های اکتشافی پیش‌فرضی که
               مرزهای قطعه diff را تغییر می‌دهند تا وصله‌ها آسان‌تر خوانده شوند،
               غیرفعال گردند.

           diff.algorithm
               یک الگوریتم diff انتخاب کنید. گونه‌ها به شرح زیر هستند:

               default, myers
                   الگوریتم پایه‌ای حریصانه diff. در حال حاضر، این پیش‌فرض است.

               minimal
                   زمان بیشتری صرف می‌کند تا مطمئن شود کوچک‌ترین diff ممکن تولید
                   می‌شود.

               patience
                   استفاده از الگوریتم «patience diff» هنگام ایجاد وصله‌ها.

               histogram
                   این الگوریتم، الگوریتم patience را برای «پشتیبانی از عناصر
                   مشترک با تکرار کم» گسترش می‌دهد.

           diff.wsErrorHighlight
               خطاهای فضای خالی را در خطوط context، old یا new در diff برجسته
               کنید. مقادیر چندگانه با کاما جدا می‌شوند، none مقادیر قبلی را
               بازنشانی می‌کند، default فهرست را به new بازنشانی می‌نماید و all
               کوتاه‌شده‌ای برای old,new,context است. خطاهای فضای خالی با
               color.diff.whitespace رنگ‌آمیزی می‌شوند. گزینه خط فرمان
               --ws-error-highlight=<kind> این تنظیم را لغو می‌کند.

           diff.colorMoved
               اگر روی یک <mode> معتبر یا یک مقدار true تنظیم شود، خطوط جابجا
               شده در یک diff با رنگ متفاوتی نمایش داده می‌شوند. برای جزئیات
               حالت‌های معتبر، --color-moved در git-diff(1) را ببینید. اگر صرفاً
               روی true تنظیم شود، حالت رنگ پیش‌فرض استفاده خواهد شد. هنگامی که
               روی false تنظیم گردد، خطوط جابجا شده رنگ‌آمیزی نمی‌شوند.

           diff.colorMovedWS
               هنگامی که خطوط جابجا شده مثلاً با استفاده از تنظیم
               diff.colorMoved رنگ‌آمیزی می‌شوند، این گزینه نحوه برخورد با
               فاصله‌ها را کنترل می‌کند. برای جزئیات حالت‌های معتبر،
               --color-moved-ws در git-diff(1) را ببینید.

           diff.tool
               کنترل می‌کند که کدام ابزار diff توسط git-difftool(1) استفاده
               شود. این متغیر مقدار پیکربندی‌شده در merge.tool را لغو می‌کند.
               فهرست زیر مقادیر توکار معتبر را نشان می‌دهد. هر مقدار دیگری به
               عنوان یک ابزار diff سفارشی در نظر گرفته می‌شود و مستلزم آن است
               که متغیر متناظر difftool.<tool>.cmd تعریف شده باشد.

           diff.guitool
               کنترل می‌کند که هنگام مشخص شدن فلگ -g/--gui، کدام ابزار diff
               توسط git-difftool(1) استفاده شود. این متغیر مقدار پیکربندی‌شده
               در merge.guitool را لغو می‌کند. فهرست زیر مقادیر توکار معتبر را
               نشان می‌دهد. هر مقدار دیگری به عنوان یک ابزار diff سفارشی در نظر
               گرفته می‌شود و مستلزم آن است که متغیر متناظر
               difftool.<guitool>.cmd تعریف شده باشد.

               araxis
                   استفاده از Araxis Merge (نیازمند نشست گرافیکی)

               bc
                   استفاده از Beyond Compare (نیازمند نشست گرافیکی)

               bc3
                   استفاده از Beyond Compare (نیازمند نشست گرافیکی)

               bc4
                   استفاده از Beyond Compare (نیازمند نشست گرافیکی)

               codecompare
                   استفاده از Code Compare (نیازمند نشست گرافیکی)

               deltawalker
                   استفاده از DeltaWalker (نیازمند نشست گرافیکی)

               diffmerge
                   استفاده از DiffMerge (نیازمند نشست گرافیکی)

               diffuse
                   استفاده از Diffuse (نیازمند نشست گرافیکی)

               ecmerge
                   استفاده از ECMerge (نیازمند نشست گرافیکی)

               emerge
                   استفاده از Emacs' Emerge

               examdiff
                   استفاده از ExamDiff Pro (نیازمند نشست گرافیکی)

               guiffy
                   استفاده از Guiffy’s Diff Tool (نیازمند نشست گرافیکی)

               gvimdiff
                   استفاده از gVim (نیازمند نشست گرافیکی)

               kdiff3
                   استفاده از KDiff3 (نیازمند نشست گرافیکی)

               kompare
                   استفاده از Kompare (نیازمند نشست گرافیکی)

               meld
                   استفاده از Meld (نیازمند نشست گرافیکی)

               nvimdiff
                   استفاده از Neovim

               opendiff
                   استفاده از FileMerge (نیازمند نشست گرافیکی)

               p4merge
                   استفاده از HelixCore P4Merge (نیازمند نشست گرافیکی)

               smerge
                   استفاده از Sublime Merge (نیازمند نشست گرافیکی)

               tkdiff
                   استفاده از TkDiff (نیازمند نشست گرافیکی)

               vimdiff
                   استفاده از Vim

               vscode
                   استفاده از Visual Studio Code (نیازمند نشست گرافیکی)

               winmerge
                   استفاده از WinMerge (نیازمند نشست گرافیکی)

               xxdiff
                   استفاده از xxdiff (نیازمند نشست گرافیکی)

           difftool.<tool>.cmd
               دستور لازم برای فراخوانی ابزار diff مشخص‌شده را معین می‌کند.
               دستور مشخص‌شده در شل با در دسترس بودن متغیرهای زیر ارزیابی
               می‌شود: LOCAL روی نام فایل موقت حاوی محتویات پیش‌تصویر diff
               (pre-image) تنظیم می‌شود و REMOTE روی نام فایل موقت حاوی محتویات
               پس‌تصویر diff (post-image) تنظیم می‌گردد.

               برای جزئیات بیشتر به گزینه --tool=<tool> در git-difftool(1)
               مراجعه کنید.

           difftool.<tool>.path
               مسیر ابزار داده‌شده را لغو می‌کند. این در مواردی مفید است که
               ابزار شما در PATH قرار ندارد.

           difftool.trustExitCode
               اگر ابزار diff فراخوانی‌شده وضعیت خروج غیرصفر برگرداند، از
               difftool خارج شود.

               برای جزئیات بیشتر به گزینه --trust-exit-code در git-difftool(1)
               مراجعه کنید.

           difftool.prompt
               قبل از هر بار فراخوانی ابزار diff اعلان تأیید نمایش داده شود.

           difftool.guiDefault
               روی true تنظیم کنید تا به صورت پیش‌فرض از diff.guitool استفاده
               شود (معادل با مشخص کردن آرگومان --gui)، یا auto برای انتخاب
               diff.guitool یا diff.tool بسته به وجود مقدار متغیر محیطی
               DISPLAY.  پیش‌فرض false است، که در آن آرگومان --gui باید صراحتاً
               ارائه شود تا diff.guitool استفاده گردد.

           extensions.*
               مگر در مواردی که خلاف آن ذکر شده باشد، اگر
               core.repositoryFormatVersion برابر 1 نباشد، مشخص کردن یک افزونه
               خطا است. به gitrepository-layout(5) مراجعه کنید.

               compatObjectFormat
                   یک الگوریتم هش سازگاری را برای استفاده مشخص می‌کند. مقادیر
                   قابل قبول sha1 و sha256 هستند. مقدار مشخص‌شده باید با مقدار
                   extensions.objectFormat متفاوت باشد. این امر امکان
                   تعامل‌پذیری در سطح کلاینت را بین مخازن گیت که objectFormat
                   آن‌ها با این compatObjectFormat مطابقت دارد فراهم می‌آورد.
                   به‌ویژه هنگامی که به طور کامل پیاده‌سازی شود، پوش‌ها و پول‌ها
                   از مخزنی که objectFormat آن با compatObjectFormat مطابقت
                   دارد انجام می‌شود، و همچنین امکان استفاده از oidهای
                   کدگذاری‌شده در compatObjectFormat علاوه بر oidهای کدگذاری‌شده
                   با objectFormat برای مشخص کردن اشیاء به صورت محلی وجود
                   خواهد داشت.

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

               noop
                   این افزونه رفتار گیت را به هیچ وجه تغییر نمی‌دهد. این افزونه
                   تنها برای آزمایش سازگاری با فرمت ۱ مفید است.

                   به دلایل تاریخی، این افزونه صرف‌نظر از تنظیم
                   core.repositoryFormatVersion رعایت می‌شود.

               noop-v1
                   این افزونه رفتار گیت را به هیچ وجه تغییر نمی‌دهد. این افزونه
                   تنها برای آزمایش سازگاری با فرمت ۱ مفید است.

               objectFormat
                   الگوریتم هش مورد استفاده را مشخص می‌کند. مقادیر قابل قبول
                   sha1 و sha256 هستند. در صورت عدم مشخص شدن، sha1 فرض می‌شود.

                   توجه داشته باشید که این تنظیم تنها باید توسط git-init(1) یا
                   git-clone(1) تنظیم شود. تلاش برای تغییر آن پس از مقداردهی
                   اولیه کار نخواهد کرد و مشکلاتی به وجود می‌آورد که عیب‌یابی
                   آن‌ها دشوار است.

               partialClone
                   هنگام فعال بودن، نشان می‌دهد که مخزن با یک کلون جزئی ایجاد
                   شده است (یا بعداً واکشی جزئی انجام داده است) و اینکه ریموت
                   ممکن است از ارسال اشیاء ناخواسته خاصی صرف‌نظر کرده باشد.
                   چنین ریموتی «promisor remote» (ریموت متعهد) نامیده می‌شود و
                   قول می‌دهد که تمام اشیاء حذف‌شده این‌چنینی را می‌توان در آینده
                   از آن واکشی کرد.

                   مقدار این کلید، نام ریموت متعهد است.

                   به دلایل تاریخی، این افزونه صرف‌نظر از تنظیم
                   core.repositoryFormatVersion رعایت می‌شود.

               preciousObjects
                   در صورت فعال بودن، نشان می‌دهد که اشیاء موجود در مخزن نباید
                   حذف شوند (مثلاً توسط git-prune یا git repack -d).

                   به دلایل تاریخی، این افزونه صرف‌نظر از تنظیم
                   core.repositoryFormatVersion رعایت می‌شود.

               refStorage
                   فرمت ذخیره‌سازی مراجع و محموله (payload) متناظر آن را مشخص
                   می‌کند. مقدار می‌تواند یک نام فرمت یا یک URI باشد:

                   •   تنها یک نام فرمت (مثلاً reftable یا files).

                   •   یک فرمت URI <format>://<payload> که صراحتاً هم فرمت و هم
                       محموله را مشخص می‌کند (مثلاً reftable:///foo/bar).

                   نام‌های فرمت پشتیبانی‌شده عبارتند از:

                   files
                       برای فایل‌های مستقل همراه با packed-refs. این حالت
                       پیش‌فرض است.

                   reftable
                       برای فرمت reftable.

                   محموله مستقیماً به بک‌اند مراجع ارسال می‌شود. برای بک‌اندهای
                   files و reftable، این باید یک مسیر سیستم‌فایل باشد که مراجع
                   در آن ذخیره می‌شوند. در صورتی که محموله‌ای ارائه نشود، به طور
                   پیش‌فرض commondir در نظر گرفته می‌شود. مسیرهای نسبی نسبت به
                   $GIT_DIR حل می‌شوند. بک‌اندهای آینده ممکن است از طرح‌های
                   محموله دیگری پشتیبانی کنند، مثلاً
                   postgres://127.0.0.1:5432?database=myrepo.

                   توجه داشته باشید که این تنظیم تنها باید توسط git-init(1) یا
                   git-clone(1) تنظیم شود. تلاش برای تغییر آن پس از مقداردهی
                   اولیه کار نخواهد کرد و مشکلاتی به وجود می‌آورد که عیب‌یابی
                   آن‌ها دشوار است.

               relativeWorktrees
                   در صورت فعال بودن، نشان می‌دهد حداقل یک درخت کاری با مسیرهای
                   نسبی پیوند داده شده است. اگر یک درخت کاری با گزینه
                   --relative-paths یا با تنظیم پیکربندی
                   worktree.useRelativePaths روی true ایجاد یا تعمیر شده باشد،
                   به طور خودکار تنظیم می‌گردد.

               submodulePathConfig
                   این افزونه برای اقلیتی از کاربران است که:

                   •   به دلایل مختلف، مانند تداخل‌های سیستم‌فایل غیرحساس به
                       حروف کوچک و بزرگ هنگام ایجاد ماژول‌هایی با نام‌های foo و
                       Foo، با خطاهایی مانند refusing to create ... in another
                       submodule's git dir مواجه می‌شوند.

                   •   به ساختاربندی‌های انعطاف‌پذیرتری برای زیرماژول‌ها نیاز
                       دارند، برای مثال به دلیل نام‌های تو در تو مانند foo،
                       foo/bar و foo/baz که توسط سازوکار پیش‌فرض gitdir که از
                       مکان‌های .git/modules/<plain-name> استفاده می‌کند
                       پشتیبانی نمی‌شوند، و باعث تداخل‌های بیشتری می‌گردند.

                   هنگامی که extensions.submodulePathConfig فعال باشد،
                   پیکربندی submodule.<name>.gitdir به تنها مرجع واحد حقیقت
                   برای تمام مسیرهای gitdir زیرماژول‌ها تبدیل می‌شود و برای تمام
                   زیرماژول‌های جدید هم در طول عملیات clone و هم init به صورت
                   خودکار تنظیم می‌گردد.

                   اگر یک ماژول تنظیم متناظر submodule.<name>.gitdir را نداشته
                   باشد، Git با خطا مواجه خواهد شد.

                   زیرماژول‌های موجود (پیش از فعال‌سازی افزونه) باید با افزودن
                   ورودی‌های پیکربندی ناموجود مهاجرت داده شوند. این کار می‌تواند
                   به صورت دستی انجام شود، مثلاً برای هر زیرماژول: git config
                   submodule.<name>.gitdir .git/modules/<name>، یا از طریق
                   دستور git submodule--helper migrate-gitdir-configs که روی
                   تمام زیرماژول‌ها پیمایش کرده و تلاش می‌کند آن‌ها را مهاجرت
                   دهد.

                   این افزونه می‌تواند با تنظیم init.defaultSubmodulePathConfig
                   روی true، به طور خودکار برای مخازن جدید فعال شود، برای مثال
                   با اجرای git config --global
                   init.defaultSubmodulePathConfig true.

               worktreeConfig
                   در صورت فعال بودن، درخت‌های کاری تنظیمات پیکربندی را علاوه
                   بر فایل $GIT_COMMON_DIR/config از فایل
                   $GIT_DIR/config.worktree نیز بارگذاری خواهند کرد. توجه
                   داشته باشید که $GIT_COMMON_DIR و $GIT_DIR برای درخت کاری
                   اصلی یکسان هستند، در حالی که سایر درخت‌های کاری دارای
                   $GIT_DIR برابر با $GIT_COMMON_DIR/worktrees/<id>/ می‌باشند.
                   تنظیمات موجود در فایل config.worktree تنظیمات هر فایل
                   پیکربندی دیگری را لغو خواهند کرد.

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

                   •   core.worktree باید از $GIT_COMMON_DIR/config به
                       $GIT_COMMON_DIR/config.worktree منتقل شود.

                   •   اگر core.bare برابر true باشد، آنگاه باید از
                       $GIT_COMMON_DIR/config به
                       $GIT_COMMON_DIR/config.worktree منتقل شود.

                   همچنین ممکن است بسته به تمایل شما برای تنظیمات
                   سفارشی‌سازی‌پذیر sparse-checkout برای هر درخت کاری، تنظیم
                   مکان‌های core.sparseCheckout و core.sparseCheckoutCone مفید
                   باشد. به طور پیش‌فرض، دستور توکار git sparse-checkout این
                   افزونه را فعال می‌کند، این مقادیر پیکربندی را بر مبنای هر
                   درخت کاری اختصاص می‌دهد، و از فایل
                   $GIT_DIR/info/sparse-checkout برای تعیین میزان پراکندگی
                   برای هر درخت کاری به طور مستقل استفاده می‌کند. برای جزئیات
                   بیشتر به git-sparse-checkout(1) مراجعه کنید.

                   به دلایل تاریخی، این افزونه صرف‌نظر از تنظیم
                   core.repositoryFormatVersion رعایت می‌شود.

           fastimport.unpackLimit
               اگر تعداد اشیاء واردشده توسط git-fast-import(1) کمتر از این حد
               باشد، اشیاء به صورت فایل‌های شیء مستقل از بسته‌بندی خارج می‌شوند.
               اما اگر تعداد اشیاء واردشده برابر یا بیشتر از این حد باشد، بسته
               به صورت یک فایل بسته (pack) ذخیره خواهد شد. ذخیره بسته حاصل از
               fast-import می‌تواند باعث شود عملیات ورود سریع‌تر انجام شود،
               به‌ویژه روی سیستم‌های فایلی کند. در صورت عدم تنظیم، مقدار
               transfer.unpackLimit به جای آن استفاده می‌شود.

           feature.*
               تنظیمات پیکربندی که با feature. شروع می‌شوند، مقادیر پیش‌فرض
               گروهی از تنظیمات پیکربندی دیگر را تغییر می‌دهند. این گروه‌ها توسط
               جامعه توسعه‌دهندگان Git به عنوان پیش‌فرض‌های توصیه‌شده ایجاد شده‌اند
               و در معرض تغییر هستند. به‌ویژه، ممکن است گزینه‌های پیکربندی جدیدی
               با پیش‌فرض‌های متفاوت اضافه شوند.

           feature.experimental
               گزینه‌های پیکربندی را که در Git جدید هستند و برای پیش‌فرض‌های
               آینده در نظر گرفته شده‌اند فعال کنید. تنظیمات پیکربندی
               گنجانده‌شده در اینجا ممکن است با هر انتشار، از جمله
               به‌روزرسانی‌های نگارش‌های فرعی، اضافه یا حذف شوند. این تنظیمات
               ممکن است به دلیل جدید بودن، اثرات متقابل ناخواسته‌ای داشته
               باشند. لطفاً اگر علاقه‌مند به ارائه بازخورد در مورد ویژگی‌های
               آزمایشی هستید، این تنظیم را فعال کنید. مقادیر پیش‌فرض جدید
               عبارتند از:

               •   fetch.negotiationAlgorithm=skipping ممکن است با پرش از روی
                   کامیت‌های بیشتر در هر مرحله، زمان مذاکره واکشی را بهبود بخشد
                   و تعداد رفت‌وبرگشت‌ها را کاهش دهد.

               •   pack.useBitmapBoundaryTraversal=true ممکن است با پیمایش
                   اشیاء کمتر، زمان پیمایش نگاشت بیتی را بهبود بخشد.

               •   pack.allowPackReuse=multi ممکن است زمان لازم برای ایجاد یک
                   بسته را با استفاده مجدد از اشیاءِ چند بسته به جای تنها یک
                   بسته بهبود بخشد.

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

               •   init.defaultRefFormat=reftable باعث می‌شود مخازن تازه
                   مقداردهی‌شده از فرمت reftable برای ذخیره‌سازی مراجع استفاده
                   کنند. این فرمت جدید مشکلات مربوط به سیستم‌های فایلی غیرحساس
                   به حروف کوچک و بزرگ را برطرف می‌کند، فشرده‌سازی بهتری دارد و
                   در بسیاری از موارد کاربرد عملکرد بسیار بهتری ارائه می‌دهد.
                   برای اطلاعات بیشتر در مورد این فرمت ذخیره‌سازی جدید به
                   Documentation/technical/reftable.adoc مراجعه کنید.

           feature.manyFiles
               گزینه‌های پیکربندی را فعال می‌کند که برای مخازنی با تعداد فایل‌های
               بسیار در دایرکتوری کاری بهینه‌سازی شده‌اند. با وجود فایل‌های
               بسیار، دستوراتی مانند git status و git checkout ممکن است کند
               باشند و این پیش‌فرض‌های جدید عملکرد را بهبود می‌بخشند:

               •   index.skipHash=true با محاسبه نکردن جمع کنترلی پایانی،
                   نوشتن در ایندکس را سرعت می‌بخشد. توجه داشته باشید که این امر
                   باعث می‌شود نگارش‌های Git قدیمی‌تر از 2.13.0 از تجزیه ایندکس
                   خودداری کنند و نگارش‌های Git قدیمی‌تر از 2.40.0 در حین اجرای
                   git fsck یک ایندکس خراب را گزارش دهند.

               •   index.version=4 فشرده‌سازی پیشوند مسیر را در ایندکس فعال
                   می‌کند.

               •   core.untrackedCache=true کِش فایل‌های ردگیری‌نشده را فعال
                   می‌کند. این تنظیم فرض می‌کند که mtime روی سیستم شما کار
                   می‌کند.

           fetch.recurseSubmodules
               این گزینه کنترل می‌کند که آیا git fetch (و واکشی زیربنایی در git
               pull) به صورت بازگشتی در زیرماژول‌های پرشده واکشی انجام دهد یا
               خیر. این گزینه می‌تواند روی یک مقدار بولی یا روی on-demand تنظیم
               شود. تنظیم آن روی یک مقدار بولی رفتار fetch و pull را تغییر
               می‌دهد تا در صورت تنظیم روی true بدون قید و شرط به صورت بازگشتی
               وارد زیرماژول‌ها شوند، یا در صورت تنظیم روی false اصلاً بازگشتی
               عمل نکنند. هنگامی که روی on-demand تنظیم شود، fetch و pull تنها
               زمانی به صورت بازگشتی وارد یک زیرماژول پرشده می‌شوند که ابرپروژه
               آن کامیتی را دریافت کند که مرجع زیرماژول را به‌روزرسانی نماید.
               پیش‌فرض on-demand است، یا مقدار submodule.recurse در صورت تنظیم
               بودن.

           fetch.fsckObjects
               اگر روی true تنظیم شود، git-fetch-pack تمام اشیاء واکشی‌شده را
               بررسی خواهد کرد. برای آنچه بررسی می‌شود به transfer.fsckObjects
               مراجعه کنید. پیش‌فرض false است. در صورت عدم تنظیم، مقدار
               transfer.fsckObjects به جای آن استفاده می‌شود.

           fetch.fsck.<msg-id>
               مانند fsck.<msg-id> عمل می‌کند، اما به جای git-fsck(1) توسط git-
               fetch-pack(1) استفاده می‌شود. برای جزئیات به مستندات
               fsck.<msg-id> مراجعه کنید.

           fetch.fsck.skipList
               مانند fsck.skipList عمل می‌کند، اما به جای git-fsck(1) توسط git-
               fetch-pack(1) استفاده می‌شود. برای جزئیات به مستندات
               fsck.skipList مراجعه کنید.

           fetch.unpackLimit
               اگر تعداد اشیاء واکشی‌شده از طریق انتقال بومی Git کمتر از این حد
               باشد، اشیاء به صورت فایل‌های شیء مستقل از بسته‌بندی خارج می‌شوند.
               اما اگر تعداد اشیاء دریافت‌شده برابر یا بیشتر از این حد باشد،
               بسته دریافت‌شده پس از افزودن هرگونه پایه‌های دلتای ناموجود، به
               عنوان یک بسته ذخیره خواهد شد. ذخیره بسته حاصل از ارسال می‌تواند
               باعث شود عملیات ارسال سریع‌تر انجام شود، به‌ویژه روی سیستم‌های
               فایلی کند. در صورت عدم تنظیم، مقدار transfer.unpackLimit به جای
               آن استفاده می‌شود.

           fetch.prune
               اگر true باشد، fetch به طور خودکار به گونه‌ای عمل می‌کند که گویی
               گزینه --prune در خط فرمان داده شده است. همچنین به
               remote.<name>.prune و بخش PRUNING در git-fetch(1) مراجعه کنید.

           fetch.pruneTags
               اگر true باشد، fetch در هنگام هرس به طور خودکار به گونه‌ای عمل
               می‌کند که گویی مشخصه مرجع refs/tags/*:refs/tags/* ارائه شده است،
               البته اگر قبلاً تنظیم نشده باشد. این امر امکان تنظیم هر دوی این
               گزینه و fetch.prune را برای حفظ نگاشت ۱ به ۱ با مراجع بالادست
               فراهم می‌کند. همچنین به remote.<name>.pruneTags و بخش PRUNING در
               git-fetch(1) مراجعه کنید.

           fetch.all
               اگر true باشد، fetch تلاش می‌کند تمام ریموت‌های موجود را
               به‌روزرسانی کند. این رفتار را می‌توان با فرستادن --no-all یا با
               مشخص کردن صریح یک یا چند ریموت برای واکشی لغو کرد. پیش‌فرض false
               است.

           fetch.output
               نحوه چاپ وضعیت به‌روزرسانی مراجع را کنترل می‌کند. مقادیر معتبر
               عبارتند از full و compact.  مقدار پیش‌فرض full است. برای جزئیات
               به بخش OUTPUT در git-fetch(1) مراجعه کنید.

           fetch.negotiationAlgorithm
               نحوه ارسال اطلاعات مربوط به کامیت‌ها در مخزن محلی را هنگام
               مذاکره بر سر محتویات فایل بسته ارسالی توسط سرور کنترل می‌کند.
               روی consecutive تنظیم کنید تا از الگوریتمی استفاده شود که
               کامیت‌های متوالی را پیمایش کرده و تک‌تک آن‌ها را بررسی می‌کند. روی
               skipping تنظیم کنید تا از الگوریتمی استفاده شود که کامیت‌ها را
               با هدف همگرایی سریع‌تر نادیده می‌گیرد، اما ممکن است منجر به فایل
               بسته‌ای بزرگ‌تر از حد نیاز شود؛ یا روی noop تنظیم کنید تا اصلاً
               هیچ اطلاعاتی ارسال نشود، که تقریباً به طور قطع منجر به فایل
               بسته‌ای بزرگ‌تر از حد نیاز خواهد شد، اما مرحله مذاکره را دور
               می‌زند. روی default تنظیم کنید تا تنظیمات اعمال‌شده قبلی لغو شده
               و از رفتار پیش‌فرض استفاده گردد. پیش‌فرض معمولاً consecutive است،
               اما اگر feature.experimental برابر true باشد، آنگاه پیش‌فرض
               skipping خواهد بود. مقادیر ناشناخته باعث خطای git fetch می‌شوند.

               همچنین گزینه‌های --negotiate-only و --negotiation-restrict در
               git-fetch(1) را ببینید.

           fetch.showForcedUpdates
               روی false تنظیم کنید تا --no-show-forced-updates در دستورات
               git-fetch(1) و git-pull(1) فعال شود. پیش‌فرض true است.

           fetch.parallel
               حداکثر تعداد عملیات واکشی را که می‌توانند به طور هم‌زمان و موازی
               اجرا شوند مشخص می‌کند (زیرماژول‌ها، یا ریموت‌ها هنگامی که گزینه
               --multiple در git-fetch(1) اعمال شده باشد).

               مقدار 0 یک پیش‌فرض معقول تعیین می‌کند. اگر تنظیم نشود، پیش‌فرض 1
               است.

               برای زیرماژول‌ها، این تنظیم را می‌توان با استفاده از تنظیم
               پیکربندی submodule.fetchJobs لغو کرد.

           fetch.writeCommitGraph
               روی true تنظیم کنید تا پس از هر دستور git fetch که یک فایل بسته
               را از ریموت دانلود می‌کند، یک commit-graph نوشته شود. با استفاده
               از گزینه --split، بیشتر اجراها یک فایل commit-graph بسیار کوچک
               روی فایل(های) commit-graph موجود ایجاد می‌کنند. گاهی اوقات این
               فایل‌ها ادغام می‌شوند و نوشتن ممکن است طولانی‌تر شود. داشتن یک
               فایل commit-graph به‌روز به عملکرد بسیاری از دستورات Git کمک
               می‌کند، از جمله git merge-base، git push -f، و git log --graph.
               پیش‌فرض false است.

           fetch.bundleURI
               این مقدار یک URI را برای دانلود داده‌های شیء Git از یک bundle
               URI قبل از انجام واکشی افزایشی از سرور اصلی Git ذخیره می‌کند.
               این شبیه به نحوه رفتار گزینه --bundle-uri در git-clone(1) است.
               دستور git clone --bundle-uri در صورتی که bundle URI ارائه‌شده
               شامل فهرست بسته‌ای باشد که برای واکشی‌های افزایشی سازمان‌یافته
               است، مقدار fetch.bundleURI را تنظیم می‌کند.

               اگر این مقدار را تغییر دهید و مخزن شما دارای مقدار
               fetch.bundleCreationToken باشد، پیش از واکشی از bundle URI
               جدید، آن مقدار fetch.bundleCreationToken را حذف کنید.

           fetch.bundleCreationToken
               هنگام استفاده از fetch.bundleURI برای واکشی افزایشی از یک فهرست
               بسته که از روش اکتشافی «creationToken» استفاده می‌کند، این مقدار
               پیکربندی حداکثر مقدار creationToken بسته‌های دانلودشده را ذخیره
               می‌کند. این مقدار برای جلوگیری از دانلود بسته‌ها در آینده استفاده
               می‌شود اگر creationToken اعلام‌شده اکیداً بزرگ‌تر از این مقدار
               نباشد.

               مقادیر توکن ایجاد توسط ارائه‌دهنده‌ای که bundle URI خاص را ارائه
               می‌دهد انتخاب می‌شوند. اگر URI را در fetch.bundleURI تغییر دادید،
               حتماً پیش از واکشی مقدار fetch.bundleCreationToken را حذف کنید.

           filter.<driver>.clean
               دستوری که برای تبدیل محتوای یک فایل درخت کاری به یک blob در
               هنگام ثبت (checkin) استفاده می‌شود. برای جزئیات به
               gitattributes(5) مراجعه کنید.

           filter.<driver>.smudge
               دستوری که برای تبدیل محتوای یک شیء blob به یک فایل درخت کاری در
               هنگام وارسی (checkout) استفاده می‌شود. برای جزئیات به
               gitattributes(5) مراجعه کنید.

           format.attach
               پیوست‌های multipart/mixed را به عنوان پیش‌فرض برای format-patch
               فعال می‌کند. مقدار همچنین می‌تواند یک رشته درون گیومه باشد که
               پیوست‌ها را به عنوان پیش‌فرض فعال کرده و آن مقدار را به عنوان مرز
               (boundary) تنظیم کند. گزینه --attach را در git-format-patch(1)
               ببینید. برای باطل کردن یک مقدار قبلی، آن را روی رشته خالی تنظیم
               کنید.

           format.from
               مقدار پیش‌فرض را برای گزینه --from در format-patch فراهم می‌کند.
               یک مقدار بولی، یا یک نام و نشانی ایمیل را می‌پذیرد. اگر false
               باشد، format-patch به صورت پیش‌فرض روی --no-from قرار می‌گیرد و
               از نویسندگان کامیت مستقیماً در فیلد «From:» ایمیل‌های وصله
               استفاده می‌کند. اگر true باشد، format-patch به صورت پیش‌فرض روی
               --from قرار می‌گیرد و از هویت کامیت‌کننده شما در فیلد «From:»
               ایمیل‌های وصله استفاده می‌نماید و در صورت تفاوت، یک فیلد «From:»
               در بدنه ایمیل وصله درج می‌کند. اگر روی یک مقدار غیربولی تنظیم
               شود، format-patch از آن مقدار به جای هویت کامیت‌کننده شما
               استفاده می‌کند. پیش‌فرض false است.

           format.forceInBodyFrom
               مقدار پیش‌فرض را برای گزینه --[no-]force-in-body-from در
               format-patch فراهم می‌کند. پیش‌فرض false است.

           format.numbered
               یک مقدار بولی که می‌تواند شماره‌های ترتیبی را در موضوعات وصله
               فعال یا غیرفعال کند. پیش‌فرض آن «auto» است که فقط در صورت وجود
               بیش از یک وصله آن را فعال می‌کند. با تنظیم آن روی «true» یا
               «false» می‌توان آن را برای همه پیام‌ها فعال یا غیرفعال کرد. گزینه
               --numbered در git-format-patch(1) را ببینید.

           format.headers
               سرآیندهای ایمیل اضافی برای گنجاندن در وصله‌ای که قرار است با
               ایمیل ارسال شود. به git-format-patch(1) مراجعه کنید.

           format.to, format.cc
               گیرندگان اضافی برای گنجاندن در وصله‌ای که قرار است با ایمیل
               ارسال شود. گزینه‌های --to و --cc را در git-format-patch(1)
               ببینید.

           format.subjectPrefix
               پیش‌فرض برای format-patch خروجی دادن فایل‌ها با پیشوند موضوع
               [PATCH] است. از این متغیر برای تغییر آن پیشوند استفاده کنید.

           format.coverFromDescription
               حالت پیش‌فرض برای format-patch جهت تعیین اینکه کدام بخش‌های نامه
               پوششی با استفاده از توضیحات شاخه پر می‌شوند. گزینه
               --cover-from-description در git-format-patch(1) را ببینید.

           format.signature
               پیش‌فرض برای format-patch خروجی دادن امضایی حاوی شماره نسخه Git
               است. از این متغیر برای تغییر آن پیش‌فرض استفاده کنید. این متغیر
               را روی رشته خالی ("") تنظیم کنید تا از تولید امضا جلوگیری شود.

           format.signatureFile
               دقیقاً مانند format.signature کار می‌کند مگر آنکه محتویات فایل
               مشخص‌شده توسط این متغیر به عنوان امضا استفاده خواهد شد.

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

           format.encodeEmailHeaders
               سرآیندهای ایمیل دارای نویسه‌های غیر ASCII را با «Q-encoding»
               (توصیف‌شده در RFC 2047) برای ارسال از طریق ایمیل کدگذاری می‌کند.
               پیش‌فرض true است.

           format.pretty
               قالب زیبای پیش‌فرض برای دستورات log/show/whatchanged. به git-
               log(1)، git-show(1)، git-whatchanged(1) مراجعه کنید.

           format.thread
               سبک پیش‌فرض رشته‌بندی (threading) برای git format-patch. می‌تواند
               یک مقدار بولی، یا shallow یا deep باشد. رشته‌بندی shallow کاری
               می‌کند که هر ایمیل پاسخی به سرِ مجموعه (head of the series) باشد،
               که در آن سرِ مجموعه به ترتیب از نامه روی جلد (cover letter)،
               --in-reply-to و اولین ایمیل وصله انتخاب می‌شود. رشته‌بندی deep هر
               ایمیل را به پاسخی برای ایمیل قبلی تبدیل می‌کند. مقدار بولی درست
               (true) معادل shallow است و مقدار نادرست (false) رشته‌بندی را
               غیرفعال می‌کند.

           format.signOff
               یک مقدار بولی که به شما امکان می‌دهد گزینه -s/--signoff در
               format-patch را به‌طور پیش‌فرض فعال کنید.  توجه: افزودن دنباله
               (trailer) Signed-off-by به یک وصله باید اقدامی آگاهانه باشد و
               بدین معناست که شما گواهی می‌دهید حق ارسال این اثر را تحت همان
               مجوز متن‌باز دارید. لطفاً برای توضیحات بیشتر به سند
               SubmittingPatches مراجعه کنید.

           format.coverLetter
               یک مقدار بولی که کنترل می‌کند آیا هنگام فراخوانی format-patch
               نامه روی جلد (cover-letter) ایجاد شود یا خیر؛ علاوه بر این
               می‌تواند روی "auto" تنظیم شود تا تنها زمانی که بیش از یک وصله
               وجود دارد نامه روی جلد ایجاد گردد. پیش‌فرض false است.

           format.commitListFormat
               هنگامی که گزینه --commit-list-format داده نشده باشد،
               format-patch از مقدار این متغیر برای تصمیم‌گیری در مورد نحوه
               قالب‌بندی مدخل هر کامیت استفاده می‌کند. پیش‌فرض shortlog است.

           format.outputDirectory
               یک پوشه سفارشی را برای ذخیره فایل‌های خروجی به جای پوشه کاری
               فعلی تنظیم می‌کند. تمام بخش‌های مسیر پوشه در صورت نیاز ایجاد
               خواهند شد.

           format.filenameMaxLength
               حداکثر طول نام فایل‌های خروجی تولیدشده توسط دستور format-patch؛
               پیش‌فرض 64 است. می‌تواند با گزینه خط فرمان
               --filename-max-length=<n> بازنویسی (override) شود.

           format.useAutoBase
               یک مقدار بولی که به شما امکان می‌دهد گزینه --base=auto در
               format-patch را به‌طور پیش‌فرض فعال کنید. همچنین می‌تواند روی
               "whenAble" تنظیم شود تا در صورت در دسترس بودن یک پایه (base)
               مناسب، --base=auto فعال گردد، اما در غیر این صورت بدون متوقف
               شدن و خطای فرآیند، از افزودن اطلاعات پایه صرف‌نظر شود.

           format.notes
               مقدار پیش‌فرض گزینه --notes را برای format-patch فراهم می‌کند. یک
               مقدار بولی یا یک مرجع (ref) را می‌پذیرد که مشخص می‌کند یادداشت‌ها
               از کجا دریافت شوند. اگر false باشد، format-patch به‌طور پیش‌فرض
               از --no-notes استفاده می‌کند. اگر true باشد، format-patch به‌طور
               پیش‌فرض از --notes استفاده می‌کند. اگر روی یک مقدار غیربولی تنظیم
               شود، format-patch به‌طور پیش‌فرض از --notes=<ref> استفاده می‌کند،
               که در آن ref همان مقدار غیربولی است. پیش‌فرض false است.

               اگر کسی بخواهد از مرجع refs/notes/true استفاده کند، لطفاً در عوض
               از همان عبارت دقیق استفاده کند.

               این پیکربندی می‌تواند چندین بار مشخص شود تا امکان گنجاندن چند
               مرجع یادداشت وجود داشته باشد. در این حالت، رفتاری مشابه ارسال
               چندین گزینه --[no-]notes[=] خواهد داشت. به این معنا که مقدار
               true یادداشت‌های پیش‌فرض را نشان می‌دهد، مقدار <ref> همچنین
               یادداشت‌های حاصل از آن مرجع یادداشت را نشان می‌دهد و مقدار false
               پیکربندی‌های قبلی را لغو کرده و یادداشتی نشان نمی‌دهد.

               برای مثال،

                   [format]
                           notes = true
                           notes = foo
                           notes = false
                           notes = bar

               تنها یادداشت‌های مربوط به refs/notes/bar را نشان خواهد داد.

           format.mboxrd
               یک مقدار بولی که فرمت مطمئن "mboxrd" را هنگام استفاده از
               --stdout برای اسکیپ کردن خطوط "^>+From " فعال می‌کند.

           format.noprefix
               در صورت تنظیم، هیچ پیشوند مبدأ یا مقصدی در وصله‌ها نشان داده
               نمی‌شود. این معادل گزینه diff.noprefix است که توسط git diff
               استفاده می‌شود (اما توسط format-patch رعایت نمی‌گردد). توجه داشته
               باشید که با تنظیم این متغیر، دریافت‌کننده وصله‌های تولیدی شما
               باید آن‌ها را با استفاده از گزینه -p0 اعمال کند.

           fsck.<msg-id>
               در طول fsck، ممکن است git مشکلاتی را در داده‌های قدیمی (legacy)
               پیدا کند که توسط نسخه‌های فعلی git تولید نمی‌شوند و در صورت تنظیم
               بودن transfer.fsckObjects روی شبکه ارسال نمی‌شدند. این ویژگی
               برای پشتیبانی از کار با مخازن قدیمی حاوی چنین داده‌هایی در نظر
               گرفته شده است.

               تنظیم fsck.<msg-id> توسط git-fsck(1) خوانده می‌شود، اما برای
               پذیرش پوش‌های حاوی چنین داده‌هایی به جای آن receive.fsck.<msg-id>
               را تنظیم کنید، یا برای شبیه‌سازی (clone) یا واکشی (fetch) آن،
               fetch.fsck.<msg-id> را تنظیم نمایید.

               بقیه مستندات برای اختصار در مورد fsck.* بحث می‌کند، اما همین
               موضوع در مورد متغیرهای متناظر receive.fsck.* و fetch.fsck.* نیز
               صدق می‌کند.

               برخلاف متغیرهایی مانند color.ui و core.editor، متغیرهای
               receive.fsck.<msg-id> و fetch.fsck.<msg-id> در صورت عدم تنظیم،
               به پیکربندی fsck.<msg-id> رجوع نخواهند کرد (fall back نمی‌کنند).
               برای پیکربندی یکنواخت تنظیمات fsck در شرایط مختلف، هر سه آن‌ها
               باید روی مقادیر یکسان تنظیم شوند.

               هنگامی که fsck.<msg-id> تنظیم شود، می‌توان با پیکربندی تنظیم
               fsck.<msg-id> خطاها را به هشدار و برعکس تبدیل کرد، جایی که
               <msg-id> همان شناسه پیام fsck است و مقدار یکی از error، warn یا
               ignore می‌باشد. برای راحتی، fsck پیشوند خطا/هشدار را با شناسه
               پیام مشخص می‌کند، به عنوان مثال "missingEmail: invalid
               author/committer line - missing email" به این معنی است که تنظیم
               fsck.missingEmail = ignore آن مشکل را پنهان خواهد کرد.

               به‌طور کلی، بهتر است اشیاء مشکل‌دار موجود را با fsck.skipList
               فهرست کنید، به جای آنکه نوع خرابی‌های مشترک این اشیاء را برای
               نادیده گرفته شدن فهرست نمایید؛ چرا که انجام مورد دوم اجازه
               می‌دهد نمونه‌های جدید همان خرابی‌ها ناشناخته باقی بمانند.

               تنظیم مقدار ناشناخته برای fsck.<msg-id> باعث متوقف شدن و خروج
               غیرعادی fsck می‌شود، اما انجام همین کار برای
               receive.fsck.<msg-id> و fetch.fsck.<msg-id> تنها باعث صدور
               هشدار توسط git خواهد شد.

               برای مقادیر پشتیبانی‌شده <msg-id>، بخش Fsck Messages در git-
               fsck(1) را ببینید.

           fsck.skipList
               مسیر یک فهرست از نام‌های اشیاء (یعنی یک SHA-1 کامل و بدون اختصار
               در هر خط) که مشخص شده به‌گونه‌ای غیرمهلک خراب هستند و باید نادیده
               گرفته شوند. در نسخه‌های Git 2.20 و جدیدتر، توضیحات (#)، خطوط
               خالی، و هرگونه فاصله خالی ابتدایی و انتهایی نادیده گرفته
               می‌شوند. در نسخه‌های قدیمی‌تر، هر چیزی جز یک SHA-1 در هر خط با خطا
               مواجه خواهد شد.

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

               مشابه fsck.<msg-id>، این متغیر دارای انواع متناظر
               receive.fsck.skipList و fetch.fsck.skipList است.

               برخلاف متغیرهایی مانند color.ui و core.editor، متغیرهای
               receive.fsck.skipList و fetch.fsck.skipList در صورت عدم تنظیم،
               به پیکربندی fsck.skipList رجوع نمی‌کنند. برای پیکربندی یکنواخت
               تنظیمات fsck در شرایط مختلف، هر سه آن‌ها باید روی مقادیر یکسان
               تنظیم شوند.

               نسخه‌های قدیمی‌تر Git (قبل از 2.20) مستند کرده بودند که فهرست
               نام‌های اشیاء باید مرتب شده باشد. این موضوع هرگز یک الزام نبود؛
               نام‌های اشیاء می‌توانستند به هر ترتیبی ظاهر شوند، اما هنگام
               خواندن فهرست، برای اهداف پیاده‌سازی جستجوی دودویی داخلی که
               می‌توانست با فهرست از قبل مرتب‌شده کار کمتری انجام دهد، مرتب بودن
               فهرست ردیابی می‌شد. مگر اینکه فهرستی بسیار عظیم داشتید، دلیلی
               برای مرتب‌سازی اولیه فهرست وجود نداشت. پس از نسخه Git 2.20
               پیاده‌سازی درهم‌سازی (hash) در عوض استفاده می‌شود، بنابراین اکنون
               دلیلی برای مرتب‌سازی اولیه فهرست وجود ندارد.

           fsmonitor.allowRemote
               به‌طور پیش‌فرض، دیمن fsmonitor از کار با مخازن متصل‌شده از طریق
               شبکه (network-mounted) خودداری می‌کند. تنظیم
               fsmonitor.allowRemote روی true این رفتار را بازنویسی می‌کند.
               تنها زمانی رعایت می‌شود که core.fsmonitor روی true تنظیم شده
               باشد.

           fsmonitor.socketDir
               این گزینه مخصوص Mac OS و Linux در صورت تنظیم، پوشه‌ای را مشخص
               می‌کند که سوکت دامنه یونیکس (Unix domain socket) مورد استفاده
               برای ارتباط بین دیمن fsmonitor و دستورات مختلف Git در آن ایجاد
               شود. این پوشه باید روی یک سیستم‌فایل بومی (native) قرار داشته
               باشد. تنها زمانی رعایت می‌شود که core.fsmonitor روی true تنظیم
               شده باشد.

           gc.aggressiveDepth
               پارامتر عمق (depth) مورد استفاده در الگوریتم فشرده‌سازی دلتا که
               توسط git gc --aggressive به کار می‌رود. مقدار پیش‌فرض آن 50 است،
               که پیش‌فرض گزینه --depth در زمان عدم استفاده از --aggressive
               می‌باشد.

               برای جزئیات بیشتر مستندات مربوط به گزینه --depth در git-
               repack(1) را ببینید.

           gc.aggressiveWindow
               پارامتر اندازه پنجره مورد استفاده در الگوریتم فشرده‌سازی دلتا که
               توسط git gc --aggressive به کار می‌رود. مقدار پیش‌فرض آن 250 است،
               که اندازه پنجره‌ای بسیار تهاجمی‌تر از مقدار پیش‌فرض 10 برای
               --window است.

               برای جزئیات بیشتر مستندات مربوط به گزینه --window در git-
               repack(1) را ببینید.

           gc.auto
               هنگامی که تقریباً بیش از این تعداد شیء مجزا (loose objects) در
               مخزن وجود داشته باشد، git gc --auto آن‌ها را بسته‌بندی (pack)
               می‌کند. برخی دستورات سطح بالا (Porcelain) از این دستور برای
               انجام گه‌گاه جمع‌آوری زباله سبک استفاده می‌کنند. مقدار پیش‌فرض 6700
               است.

               تنظیم این مقدار روی 0 نه تنها بسته‌بندی خودکار بر اساس تعداد
               اشیاء مجزا را غیرفعال می‌کند، بلکه هر روش شهودی دیگری را نیز که
               git gc --auto در غیر این صورت برای تشخیص وجود کار انجام‌دادنی
               استفاده می‌کرد (مانند gc.autoPackLimit)، غیرفعال می‌سازد.

           gc.autoPackLimit
               هنگامی که بیش از این تعداد بسته وجود داشته باشد که با فایل
               *.keep در مخزن علامت‌گذاری نشده‌اند، git gc --auto آن‌ها را در یک
               بسته بزرگ‌تر تجمیع می‌کند. مقدار پیش‌فرض 50 است. تنظیم آن روی 0
               این قابلیت را غیرفعال می‌کند. تنظیم gc.auto روی 0 نیز این را
               غیرفعال خواهد کرد.

               متغیر پیکربندی gc.bigPackThreshold در زیر را ببینید. در صورت
               استفاده، بر نحوه عملکرد محدودیت بسته‌بندی خودکار تأثیر می‌گذارد.

           gc.autoDetach
               کاری می‌کند که git gc --auto در صورت پشتیبانی سیستم، بلافاصله
               بازگردد و در پس‌زمینه اجرا شود. پیش‌فرض true است. این متغیر
               پیکربندی به عنوان جایگزین پشتیبان در صورت تنظیم نبودن
               maintenance.autoDetach عمل می‌کند.

           gc.bigPackThreshold
               اگر غیرصفر باشد، هنگام اجرای git gc تمام بسته‌های غیرکرافتی
               (non-cruft) بزرگ‌تر از این حد نگه‌داشته می‌شوند. این بسیار شبیه به
               --keep-largest-pack است با این تفاوت که تمام بسته‌های غیرکرافتی
               که به این حد آستانه می‌رسند نگه‌داشته می‌شوند، نه فقط بزرگ‌ترین
               بسته. پیش‌فرض صفر است. پسوندهای رایج واحد k، m یا g پشتیبانی
               می‌شوند.

               توجه داشته باشید که اگر تعداد بسته‌های نگه‌داشته‌شده بیش از
               gc.autoPackLimit باشد، این متغیر پیکربندی نادیده گرفته می‌شود و
               تمام بسته‌ها به جز بسته پایه دوباره بسته‌بندی (repack) خواهند شد.
               پس از این، تعداد بسته‌ها باید به زیر gc.autoPackLimit برسد و
               gc.bigPackThreshold دوباره رعایت شود.

               اگر مقدار حافظه تخمینی برای اجرای روان git repack در دسترس
               نباشد و gc.bigPackThreshold تنظیم نشده باشد، بزرگ‌ترین بسته نیز
               مستثنی خواهد شد (این معادل اجرای git gc با --keep-largest-pack
               است).

           gc.writeCommitGraph
               اگر true باشد، هنگام اجرای git-gc(1) فرآیند gc فایل
               commit-graph را بازنویسی خواهد کرد. هنگام استفاده از git gc
               --auto، در صورت نیاز به خانه‌تکانی و نگهداری (housekeeping)،
               نمودار کامیت به‌روزرسانی خواهد شد. پیش‌فرض true است. برای جزئیات
               به git-commit-graph(1) مراجعه کنید.

           gc.logExpiry
               اگر فایل gc.log وجود داشته باشد، git gc --auto به جای اجرا،
               محتوای آن را چاپ کرده و با وضعیت صفر خارج می‌شود، مگر اینکه عمر
               آن فایل بیشتر از gc.logExpiry باشد. پیش‌فرض "1.day" است. برای
               روش‌های بیشتر تعیین مقدار آن، به gc.pruneExpire مراجعه کنید.

           gc.packRefs
               اجرای git pack-refs در یک مخزن، آن را برای نسخه‌های Git قبل از
               1.5.1.2 روی پروتکل‌های انتقال ساده (dumb transports) مانند HTTP
               غیرقابل کلون می‌کند. این متغیر تعیین می‌کند که آیا git gc دستور
               git pack-refs را اجرا کند یا خیر. می‌تواند روی notbare تنظیم شود
               تا در تمام مخازن غیرلخت (non-bare) فعال گردد یا می‌تواند روی یک
               مقدار بولی تنظیم شود. پیش‌فرض true است.

           gc.cruftPacks
               ذخیره اشیاء غیرقابل‌دسترس در یک بسته کرافت (cruft pack؛ نگاه
               کنید به git-repack(1)) به جای اشیاء مجزا (loose objects).
               پیش‌فرض true است.

           gc.maxCruftSize
               محدود کردن اندازه بسته‌های کرافت جدید هنگام بسته‌بندی مجدد. در
               صورت تعیین هم‌زمان با --max-cruft-size، گزینه خط فرمان اولویت
               دارد. گزینه --max-cruft-size در git-repack(1) را ببینید.

           gc.pruneExpire
               هنگامی که git gc اجرا می‌شود، دستور prune --expire 2.weeks.ago
               (و در صورت استفاده از بسته‌های کرافت از طریق gc.cruftPacks یا
               --cruft، دستور repack --cruft --cruft-expiration 2.weeks.ago)
               را فراخوانی می‌کند. مهلت مقرر (grace period) را با این متغیر
               پیکربندی تغییر دهید. مقدار "now" می‌تواند برای غیرفعال کردن این
               مهلت و پاک‌سازی فوری اشیاء غیرقابل‌دسترس استفاده شود، یا "never"
               می‌تواند برای متوقف کردن کامل پاک‌سازی استفاده گردد. این ویژگی به
               جلوگیری از خرابی داده‌ها در زمانی که git gc هم‌زمان با فرآیند
               دیگری در حال نوشتن روی مخزن اجرا می‌شود کمک می‌کند؛ بخش "NOTES"
               در git-gc(1) را ببینید.

           gc.worktreePruneExpire
               هنگامی که git gc اجرا می‌شود، دستور git worktree prune --expire
               3.months.ago را فراخوانی می‌کند. این متغیر پیکربندی می‌تواند برای
               تعیین مهلت مقرر متفاوتی استفاده شود. مقدار "now" ممکن است برای
               غیرفعال کردن مهلت مقرر و هرس فوری $GIT_DIR/worktrees استفاده
               شود، یا "never" برای متوقف کردن پاک‌سازی به کار رود.

           gc.reflogExpire, gc.<pattern>.reflogExpire
               دستور git reflog expire مدخل‌های رف‌لاگ (reflog) قدیمی‌تر از این
               زمان را حذف می‌کند؛ پیش‌فرض 90 روز است. مقدار "now" تمام مدخل‌ها
               را فوراً منقضی می‌کند، و "never" انقضا را به‌طور کامل متوقف
               می‌سازد. با قرار دادن "<pattern>" (مثلاً "refs/stash") در وسط،
               این تنظیم تنها بر مراجعی که با <pattern> مطابقت دارند اعمال
               می‌شود.

           gc.reflogExpireUnreachable, gc.<pattern>.reflogExpireUnreachable
               دستور git reflog expire مدخل‌های رف‌لاگ قدیمی‌تر از این زمان را که
               از نوک (tip) فعلی قابل دسترس نیستند حذف می‌کند؛ پیش‌فرض 30 روز
               است. مقدار "now" تمام مدخل‌ها را فوراً منقضی می‌کند، و "never"
               انقضا را به‌طور کامل متوقف می‌سازد. با قرار دادن "<pattern>"
               (مثلاً "refs/stash") در وسط، تنظیم تنها بر مراجعی که با
               <pattern> مطابقت دارند اعمال می‌شود.

               این نوع مدخل‌ها معمولاً در نتیجه استفاده از git commit --amend یا
               git rebase ایجاد می‌شوند و کامیت‌های قبل از رخ دادن اصلاح (amend)
               یا ری‌بیس هستند. از آنجا که این تغییرات بخشی از پروژه فعلی
               نیستند، بیشتر کاربران تمایل دارند آن‌ها را زودتر منقضی کنند، به
               همین دلیل پیش‌فرض تهاجمی‌تر از gc.reflogExpire است.

           gc.recentObjectsHook
               هنگام بررسی اینکه آیا یک شیء حذف شود یا خیر (چه هنگام تولید یک
               بسته کرافت یا ذخیره اشیاء غیرقابل‌دسترس به‌صورت مجزا)، از شل برای
               اجرای دستور(های) مشخص‌شده استفاده می‌کند. خروجی آن‌ها به عنوان
               شناسه‌های اشیائی تفسیر می‌شود که Git صرف‌نظر از سن واقعی‌شان، آن‌ها
               را به عنوان "اخیر" (recent) در نظر می‌گیرد. با در نظر گرفتن
               mtime آن‌ها به عنوان "اکنون"، هر شیء (و نوادگان آن) ذکرشده در
               خروجی، صرف‌نظر از سن واقعی‌شان نگه‌داشته خواهند شد.

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

           gc.repackFilter
               هنگام بسته‌بندی مجدد (repack)، از فیلتر مشخص‌شده برای انتقال
               اشیاء خاص به یک فایل بسته جداگانه استفاده می‌کند. گزینه
               --filter=<filter-spec> در git-repack(1) را ببینید.

           gc.repackFilterTo
               هنگام بسته‌بندی مجدد و استفاده از یک فیلتر (نگاه کنید به
               gc.repackFilter)، مکان مشخص‌شده برای ایجاد فایل بسته‌ای که شامل
               اشیاء فیلترشده است استفاده خواهد شد.  هشدار: مکان مشخص‌شده باید
               قابل دسترس باشد، برای مثال با استفاده از مکانیزم Git
               alternates، در غیر این صورت ممکن است مخزن توسط Git فاسد در نظر
               گرفته شود چرا که ممکن است نتواند به اشیاء موجود در آن فایل بسته
               دسترسی پیدا کند. گزینه --filter-to=<dir> در git-repack(1) و بخش
               objects/info/alternates از gitrepository-layout(5) را ببینید.

           gc.rerereResolved
               ثبت‌های ادغام با تعارضی که قبلاً حل کرده‌اید، هنگام اجرای git
               rerere gc برای این تعداد روز نگه‌داری می‌شوند. همچنین می‌توانید از
               عبارات خواناتر برای انسان مانند "1.month.ago" و غیره استفاده
               کنید. پیش‌فرض 60 روز است. به git-rerere(1) مراجعه کنید.

           gc.rerereUnresolved
               ثبت‌های ادغام با تعارضی که حل نکرده‌اید، هنگام اجرای git rerere
               gc برای این تعداد روز نگه‌داری می‌شوند. همچنین می‌توانید از عبارات
               خواناتر برای انسان مانند "1.month.ago" و غیره استفاده کنید.
               پیش‌فرض 15 روز است. به git-rerere(1) مراجعه کنید.

           gitcvs.commitMsgAnnotation
               این رشته را به انتهای هر پیام کامیت پیوست می‌کند. برای غیرفعال
               کردن این ویژگی، آن را روی رشته خالی تنظیم کنید. پیش‌فرض "via
               git-CVS emulator" است.

           gitcvs.enabled
               مشخص می‌کند که آیا رابط سرور CVS برای این مخزن فعال است یا خیر.
               به git-cvsserver(1) مراجعه کنید.

           gitcvs.logFile
               مسیر فایل لاگی که رابط کاربری سرور CVS در آن خب... موارد مختلف
               را لاگ می‌کند. به git-cvsserver(1) مراجعه کنید.

           gitcvs.usecrlfattr
               اگر true باشد، سرور ویژگی‌های تبدیل پایان خط را برای فایل‌ها
               جستجو می‌کند تا حالت‌های -k مورد استفاده را تعیین کند. اگر این
               مشخصه‌ها Git را وادار کنند فایلی را به عنوان متنی در نظر بگیرد،
               حالت -k خالی رها می‌شود تا کلاینت‌های CVS با آن به عنوان متن
               رفتار کنند. اگر آن‌ها تبدیل متن را سرکوب کنند، فایل با حالت -kb
               تنظیم می‌شود که هرگونه دستکاری خطوط جدید را که کلاینت ممکن است
               در غیر این صورت انجام دهد، سرکوب می‌کند. اگر مشخصه‌ها اجازه تعیین
               نوع فایل را ندهند، gitcvs.allBinary استفاده می‌شود. به
               gitattributes(5) مراجعه کنید.

           gitcvs.allBinary
               اگر gitcvs.usecrlfattr حالت صحیح -kb را تعیین نکند، این متغیر
               به کار می‌رود. اگر true باشد، تمام فایل‌های تعیین‌تکلیف‌نشده در
               حالت -kb به کلاینت ارسال می‌شوند. این کار باعث می‌شود کلاینت با
               آن‌ها به عنوان فایل‌های باینری رفتار کند، که هرگونه دستکاری خطوط
               جدید را سرکوب می‌کند. از طرف دیگر، اگر روی "guess" تنظیم شود،
               محتویات فایل برای تصمیم‌گیری در مورد باینری بودن آن بررسی می‌شود،
               مشابه core.autocrlf.

           gitcvs.dbName
               پایگاه داده‌ای که توسط git-cvsserver برای کش کردن اطلاعات
               بازبینی برگرفته از مخزن Git استفاده می‌شود. معنی دقیق به درایور
               پایگاه داده استفاده‌شده بستگی دارد؛ برای SQLite (که درایور
               پیش‌فرض است) این یک نام فایل است. از جایگزینی متغیرها پشتیبانی
               می‌کند (برای جزئیات به git-cvsserver(1) مراجعه کنید). نباید شامل
               نقطه‌ویرگول (;) باشد. پیش‌فرض: %Ggitcvs.%m.sqlite

           gitcvs.dbDriver
               درایور Perl DBI استفاده‌شده. در اینجا می‌توانید هر درایور موجود
               را برای این منظور مشخص کنید، اما ممکن است کار نکند. نرم‌افزار
               git-cvsserver با DBD::SQLite آزمایش شده، گزارش شده که با
               DBD::Pg کار می‌کند، و گزارش شده که با DBD::mysql کار نمی‌کند.
               ویژگی آزمایشی. نباید شامل دو دونقطه (:) باشد. پیش‌فرض: SQLite.
               به git-cvsserver(1) مراجعه کنید.

           gitcvs.dbUser, gitcvs.dbPass
               کاربر و رمز عبور پایگاه داده. تنها در صورتی مفید است که
               gitcvs.dbDriver تنظیم شده باشد، زیرا SQLite مفهومی از کاربران
               و/یا رمزهای عبور پایگاه داده ندارد.  gitcvs.dbUser از جایگزینی
               متغیرها پشتیبانی می‌کند (برای جزئیات به git-cvsserver(1) مراجعه
               کنید).

           gitcvs.dbTableNamePrefix
               پیشوند نام جداول پایگاه داده. به نام تمام جداول پایگاه داده
               مورد استفاده اضافه می‌شود و امکان استفاده از یک پایگاه داده واحد
               برای چندین مخزن را فراهم می‌کند. از جایگزینی متغیر پشتیبانی
               می‌کند (برای جزئیات به git-cvsserver(1) مراجعه کنید). هر کاراکتر
               غیرالفبایی با زیرخط (underscore) جایگزین خواهد شد.

           تمام متغیرهای gitcvs به جز gitcvs.usecrlfattr و gitcvs.allBinary را
           می‌توان به عنوان gitcvs.<access_method>.<varname> نیز مشخص کرد (که
           در آن access_method یکی از مقادیر "ext" و "pserver" است) تا فقط
           برای روش دسترسی مشخص‌شده اعمال شوند.

           gitweb.category, gitweb.description, gitweb.owner, gitweb.url
               برای توضیحات به gitweb(1) مراجعه کنید.

           gitweb.avatar, gitweb.blame, gitweb.grep, gitweb.highlight,
           gitweb.patches, gitweb.pickaxe, gitweb.remote_heads,
           gitweb.showSizes, gitweb.snapshot
               برای توضیحات به gitweb.conf(5) مراجعه کنید.

           gpg.program
               مسیر برنامه‌ای که باید هنگام ایجاد یا اعتبارسنجی امضای PGP به
               جای "gpg" استفاده شود. این برنامه باید از همان رابط خط فرمان
               GPG پشتیبانی کند، به این صورت که برای اعتبارسنجی یک امضای مجزا
               (detached signature)، دستور "gpg --verify $signature - <$file"
               اجرا می‌شود، و انتظار می‌رود برنامه با خروج با کد 0 امضای معتبر
               را اعلام کند. برای تولید یک امضای مجزای محافظت‌شده با زره اسکی
               (ASCII-armored)، ورودی استاندارد "gpg -bsau $key" با محتوایی که
               باید امضا شود تغذیه می‌گردد و انتظار می‌رود برنامه نتیجه را به
               خروجی استاندارد خود بفرستد.

           gpg.format
               فرمت کلید مورد استفاده هنگام امضا با --gpg-sign را مشخص می‌کند.
               پیش‌فرض "openpgp" است. سایر مقادیر مجاز عبارتند از "x509" و
               "ssh".

               برای فرمت امضا که بر اساس gpg.format انتخاب‌شده متفاوت است، به
               gitformat-signature(5) مراجعه کنید.

           gpg.<format>.program
               از این برای سفارشی‌سازی برنامه استفاده‌شده برای فرمت امضایی که
               انتخاب کرده‌اید استفاده کنید (نگاه کنید به gpg.program و
               gpg.format).  gpg.program هنوز می‌تواند به عنوان یک مترادف قدیمی
               برای gpg.openpgp.program استفاده شود. مقدار پیش‌فرض برای
               gpg.x509.program برابر "gpgsm" و برای gpg.ssh.program برابر
               "ssh-keygen" است.

           gpg.minTrustLevel
               حداقل سطح اعتماد را برای اعتبارسنجی امضا مشخص می‌کند. اگر این
               گزینه تنظیم نشده باشد، اعتبارسنجی امضا برای عملیات‌های ادغام
               نیازمند کلیدی با حداقل سطح اعتماد marginal است. سایر عملیات‌هایی
               که اعتبارسنجی امضا را انجام می‌دهند به کلیدی با حداقل اعتماد
               undefined نیاز دارند. تنظیم این گزینه سطح اعتماد مورد نیاز را
               برای تمام عملیات‌ها بازنویسی می‌کند. مقادیر پشتیبانی‌شده به ترتیب
               صعودی اهمیت:

               •   undefined

               •   never

               •   marginal

               •   fully

               •   ultimate

           gpg.ssh.defaultKeyCommand
               این دستور زمانی اجرا می‌شود که user.signingkey تنظیم نشده باشد و
               امضای ssh درخواست شود. در صورت خروج موفق، انتظار می‌رود یک کلید
               عمومی معتبر ssh که با پیشوند key:: شروع می‌شود در خط اول خروجی
               آن باشد. این امر امکان استفاده از اسکریپتی را برای جستجوی پویای
               کلید عمومی صحیح فراهم می‌کند، زمانی که پیکربندی ایستا برای
               user.signingKey عملی نباشد؛ برای مثال هنگامی که کلیدها یا
               گواهی‌های SSH به‌طور مکرر تعویض (rotate) می‌شوند یا انتخاب کلید
               مناسب به عوامل خارجی وابسته است که برای git ناشناخته هستند.

           gpg.ssh.allowedSignersFile
               فایلی شامل کلیدهای عمومی ssh که مایل به اعتماد به آن‌ها هستید.
               فایل شامل یک یا چند خط از هویت‌ها (principals) و به دنبال آن یک
               کلید عمومی ssh است. به عنوان مثال:
               user1@example.com,user2@example.com ssh-rsa AAAAX1... برای
               جزئیات به بخش "ALLOWED SIGNERS" در ssh-keygen(1) مراجعه کنید.
               هویت (principal) فقط برای شناسایی کلید استفاده می‌شود و هنگام
               اعتبارسنجی امضا در دسترس است.

               برخلاف gpg، در SSH مفهومی از سطوح اعتماد وجود ندارد. برای تمایز
               بین امضاهای معتبر و امضاهای قابل اعتماد، سطح اعتماد اعتبارسنجی
               امضا در صورتی که کلید عمومی در allowedSignersFile وجود داشته
               باشد روی fully تنظیم می‌شود. در غیر این صورت سطح اعتماد
               undefined خواهد بود و دستور git verify-commit/tag ناموفق خواهد
               شد.

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

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

               از OpenSSH 8.8 به بعد، این فایل امکان تعیین طول عمر کلید را با
               استفاده از گزینه‌های valid-after و valid-before فراهم می‌کند. اگر
               کلید امضاکننده در زمان ایجاد امضا معتبر بوده باشد، Git امضاها
               را معتبر علامت‌گذاری می‌کند. این به کاربران امکان می‌دهد کلید امضا
               را بدون باطل کردن تمام امضاهای قبلی تغییر دهند.

               استفاده از یک کلید CA مربوط به SSH با گزینه cert-authority
               (نگاه کنید به بخش "CERTIFICATES" در ssh-keygen(1)) نیز معتبر
               است.

           gpg.ssh.revocationFile
               یک SSH KRL یا فهرستی از کلیدهای عمومی باطل‌شده (بدون پیشوند
               هویت). برای جزئیات به ssh-keygen(1) مراجعه کنید. اگر یک کلید
               عمومی در این فایل پیدا شود، همیشه دارای سطح اعتماد "never" در
               نظر گرفته می‌شود و امضاها نامعتبر نمایش داده خواهند شد.

           grep.lineNumber
               اگر روی true تنظیم شود، گزینه -n را به‌طور پیش‌فرض فعال می‌کند.

           grep.column
               اگر روی true تنظیم شود، گزینه --column را به‌طور پیش‌فرض فعال
               می‌کند.

           grep.patternType
               رفتار پیش‌فرض تطبیق الگو را تنظیم می‌کند. استفاده از مقدار basic،
               extended، fixed یا perl به ترتیب گزینه --basic-regexp،
               --extended-regexp، --fixed-strings یا --perl-regexp را فعال
               می‌کند، در حالی که مقدار default از گزینه grep.extendedRegexp
               برای انتخاب بین basic و extended استفاده خواهد کرد.

           grep.extendedRegexp
               اگر روی true تنظیم شود، گزینه --extended-regexp را به‌طور پیش‌فرض
               فعال می‌کند. این گزینه زمانی که گزینه grep.patternType روی
               مقداری غیر از default تنظیم شده باشد، نادیده گرفته می‌شود.

           grep.threads
               تعداد نخ‌های پردازشی (worker threads) دستور grep که باید استفاده
               شوند. اگر تنظیم نشود (یا روی 0 تنظیم شود)، Git به اندازه تعداد
               هسته‌های منطقی موجود از نخ‌ها استفاده خواهد کرد.

           grep.fullName
               اگر روی true تنظیم شود، گزینه --full-name را به‌طور پیش‌فرض فعال
               می‌کند.

           grep.fallbackToNoIndex
               اگر روی true تنظیم شود، در صورتی که git grep خارج از یک مخزن
               git اجرا گردد، به git grep --no-index رجوع خواهد کرد. پیش‌فرض
               false است.

           gui.commitMsgWidth
               عرض پنجره پیام کامیت را در git-gui(1) تعیین می‌کند. پیش‌فرض "75"
               است.

           gui.diffContext
               مشخص می‌کند که چه تعداد خط بافت (context lines) باید در
               فراخوانی‌های diff ایجادشده توسط git-gui(1) استفاده شود. پیش‌فرض
               "5" است.

           gui.displayUntracked
               مشخص می‌کند که آیا git-gui(1) فایل‌های ردیابی‌نشده (untracked) را
               در فهرست فایل‌ها نمایش دهد یا خیر. پیش‌فرض "true" است.

           gui.encoding
               رمزگذاری کاراکتر پیش‌فرض را برای نمایش محتوای فایل در git-gui(1)
               و gitk(1) مشخص می‌کند. این مقدار می‌تواند با تنظیم صفت encoding
               برای فایل‌های مربوطه بازنویسی شود (نگاه کنید به
               gitattributes(5)).  اگر این گزینه تنظیم نشود، ابزارها به
               کدگذاری محلی (locale) بازمی‌گردند.

           gui.matchTrackingBranch
               مشخص می‌کند که آیا شاخه‌های جدید ایجادشده با git-gui(1) به‌طور
               پیش‌فرض باید شاخه‌های ریموت با نام‌های مطابقت‌دار را ردیابی کنند یا
               خیر. پیش‌فرض: "false".

           gui.newBranchTemplate
               به عنوان نام پیشنهادی هنگام ایجاد شاخه‌های جدید با استفاده از
               git-gui(1) استفاده می‌شود.

           gui.pruneDuringFetch
               مقدار "true" اگر git-gui(1) باید هنگام انجام واکشی (fetch)،
               شاخه‌های ردیابی ریموت را هرس (prune) کند. مقدار پیش‌فرض "false"
               است.

           gui.trustmtime
               مشخص می‌کند که آیا git-gui(1) باید به برچسب زمانی تغییر فایل
               (modification timestamp) اعتماد کند یا خیر. به‌طور پیش‌فرض به
               برچسب‌های زمانی اعتماد نمی‌شود.

           gui.spellingDictionary
               لغت‌نامه مورد استفاده برای غلط‌گیری املایی پیام‌های کامیت در git-
               gui(1) را مشخص می‌کند. در صورت تنظیم روی "none"، بررسی املا
               خاموش می‌شود.

           gui.fastCopyBlame
               اگر true باشد، git gui blame برای تشخیص مکان اصلی به جای -C -C
               از -C استفاده می‌کند. این کار در مخازن بسیار بزرگ، عمل blame را
               به بهای تشخیص کمتر رونوشت‌ها (copy detection)، به‌طور چشمگیری
               سریع‌تر می‌کند.

           gui.copyBlameThreshold
               آستانه مورد استفاده در تشخیص مکان اصلی در git gui blame را که
               بر حسب کاراکترهای حرفی‌عددی اندازه‌گیری می‌شود، مشخص می‌کند. برای
               اطلاعات بیشتر در مورد تشخیص رونوشت به راهنمای git-blame(1)
               مراجعه کنید.

           gui.blamehistoryctx
               شعاع بافت تاریخچه را بر حسب روز برای نمایش در gitk(1) برای
               کامیت انتخاب‌شده مشخص می‌کند، زمانی که آیتم منوی Show History
               Context از git gui blame فراخوانی شود. اگر این متغیر روی صفر
               تنظیم شود، کل تاریخچه نشان داده می‌شود.

           gui.GCWarning
               مشخص می‌کند که آیا git-gui(1) هنگامی که git تعداد زیادی شیء مجزا
               را در مخزن شناسایی می‌کند، باید درخواست جمع‌آوری زباله را نمایش
               دهد یا خیر. مقدار پیش‌فرض "true" است.

           guitool.<name>.cmd
               خط فرمان شل را برای اجرا در هنگام فراخوانی مورد مربوطه از منوی
               Tools در git-gui(1) مشخص می‌کند. این گزینه برای هر ابزاری الزامی
               است. دستور از ریشه پوشه کاری اجرا می‌شود و در محیط، نام ابزار را
               به عنوان GIT_GUITOOL، نام فایل انتخاب‌شده فعلی را به عنوان
               FILENAME، و نام شاخه فعلی را به عنوان CUR_BRANCH دریافت می‌کند
               (اگر هد جداشده [detached] باشد، CUR_BRANCH خالی است).

           guitool.<name>.needsFile
               ابزار را تنها در صورتی اجرا می‌کند که یک تفاوت (diff) در رابط
               کاربری انتخاب شده باشد. این تضمین می‌کند که FILENAME خالی نباشد.

           guitool.<name>.noConsole
               دستور را به‌طور بی‌صدا و بدون ایجاد پنجره‌ای برای نمایش خروجی آن
               اجرا می‌کند.

           guitool.<name>.noRescan
               پس از اتمام اجرای ابزار، پوشه کاری را برای تغییرات دوباره پویش
               (rescan) نمی‌کند.

           guitool.<name>.confirm
               قبل از اجرای واقعی ابزار، یک کادر گفتگوی تأیید را نمایش می‌دهد.

           guitool.<name>.argPrompt
               یک آرگومان رشته‌ای از کاربر درخواست می‌کند و آن را از طریق متغیر
               محیطی ARGS به ابزار ارسال می‌نماید. از آنجا که درخواست آرگومان
               متضمن تأیید است، در صورت فعال بودن این گزینه، گزینه confirm هیچ
               اثری ندارد. اگر گزینه روی true، yes یا 1 تنظیم شده باشد، کادر
               گفتگو از یک اعلان عمومی توکار استفاده می‌کند؛ در غیر این صورت
               مقدار دقیق متغیر به کار می‌رود.

           guitool.<name>.revPrompt
               یک بازنگری (revision) معتبر واحد را از کاربر درخواست می‌کند و
               متغیر محیطی REVISION را تنظیم می‌نماید. از جنبه‌های دیگر این
               گزینه شبیه به argPrompt است و می‌تواند همراه با آن استفاده شود.

           guitool.<name>.revUnmerged
               تنها شاخه‌های ادغام‌نشده را در زیرگفتگوی revPrompt نشان می‌دهد.
               این برای ابزارهای مشابه merge یا rebase مفید است، اما برای
               مواردی مانند checkout یا reset کاربرد ندارد.

           guitool.<name>.title
               عنوان مورد استفاده برای کادر گفتگوی ورودی را مشخص می‌کند. پیش‌فرض
               نام ابزار است.

           guitool.<name>.prompt
               رشته اعلان عمومی را برای نمایش در بالای کادر گفتگو، قبل از
               بخش‌های مربوط به argPrompt و revPrompt مشخص می‌کند. مقدار پیش‌فرض
               شامل خود دستور واقعی است.

           help.browser
               مرورگری را مشخص می‌کند که برای نمایش راهنما در قالب web استفاده
               خواهد شد. به git-help(1) مراجعه کنید.

           help.format
               قالب پیش‌فرض راهنمای استفاده‌شده توسط git-help(1) را بازنویسی
               می‌کند. مقادیر man، info، web و html پشتیبانی می‌شوند.  man
               پیش‌فرض است.  web و html یکسان هستند.

           help.autoCorrect
               اگر git غلط‌های املایی را تشخیص دهد و بتواند دقیقاً یک دستور
               معتبر شبیه به خطا را شناسایی کند، سعی می‌کند دستور صحیح را
               پیشنهاد دهد یا حتی پیشنهاد را به‌طور خودکار اجرا نماید. مقادیر
               ممکن برای پیکربندی عبارتند از:

               •   0، "false"، "off"، "no"، "show": نمایش دستور پیشنهادی
                   (پیش‌فرض).

               •   1، "true"، "on"، "yes"، "immediate": اجرای فوری دستور
                   پیشنهادی.

               •   عدد مثبت > 1: اجرای دستور پیشنهادی پس از دهم‌ثانیه‌های
                   مشخص‌شده (0.1 ثانیه).

               •   "never": هیچ دستور پیشنهادی را اجرا یا نمایش ندهد.

               •   "prompt": پیشنهاد را نشان داده و برای اجرای دستور تأییدیه
                   بخواهد.

           help.htmlPath
               مسیری را مشخص می‌کند که مستندات HTML در آن قرار دارند. مسیرهای
               سیستم‌فایل و نشانی‌های وب (URLs) پشتیبانی می‌شوند. هنگامی که
               راهنما در قالب web نمایش داده می‌شود، صفحات HTML با این مسیر
               پیشوند خواهند شد. پیش‌فرض این مسیر مستندات مربوط به نصب Git شما
               است.

           hook.<friendly-name>.command
               دستوری که برای hook.<friendly-name> باید اجرا شود.
               <friendly-name> نامی یکتاست که این قلاب را شناسایی می‌کند.
               رویدادهای قلابی که دستور را فراخوانی می‌کنند با
               hook.<friendly-name>.event پیکربندی می‌شوند. این مقدار می‌تواند
               یک مسیر اجرایی یا یک تک‌خطی شل (shell oneliner) باشد. اگر بیش از
               یک مقدار برای همان <friendly-name> مشخص شود، تنها آخرین مقدار
               تجزیه‌شده استفاده می‌شود. به git-hook(1) مراجعه کنید.

           hook.<friendly-name>.event
               رویدادهای قلاب که hook.<friendly-name> را فعال می‌کنند. این
               مقدار نام یک رویداد قلاب مانند "pre-commit" یا "update" است.
               (برای فهرست کامل رویدادهای قلاب به githooks(5) مراجعه کنید.) در
               رویداد مشخص‌شده، دستور مرتبط hook.<friendly-name>.command اجرا
               می‌شود. این یک کلید چندمقداری است. برای اجرای
               hook.<friendly-name> روی چندین رویداد، کلید را بیش از یک بار
               مشخص کنید. یک مقدار خالی فهرست رویدادها را بازنشانی می‌کند و
               رویدادهای تعریف‌شده قبلی را برای hook.<friendly-name> پاک
               می‌نماید. به git-hook(1) مراجعه کنید.

               نام <friendly-name> نباید مشابه نام یک رویداد قلاب شناخته‌شده
               باشد (برای مثال از hook.pre-commit.event استفاده نکنید).
               استفاده از نام یک رویداد شناخته‌شده به عنوان friendly-name یک
               خطای مهلک است زیرا باعث ایجاد ابهام با hook.<event>.enabled و
               hook.<event>.jobs می‌شود. برای نام‌های رویداد ناشناخته، زمانی که
               <friendly-name> با مقدار رویداد مطابقت داشته باشد یک هشدار صادر
               می‌شود.

           hook.<friendly-name>.enabled
               مشخص می‌کند که آیا قلاب hook.<friendly-name> فعال است یا خیر.
               پیش‌فرض true است. برای غیرفعال کردن قلاب بدون حذف پیکربندی آن،
               روی false تنظیم کنید. این به‌ویژه زمانی مفید است که قلاب در یک
               فایل پیکربندی سیستمی یا سراسری تعریف شده باشد و نیاز باشد برای
               یک مخزن خاص غیرفعال گردد. به git-hook(1) مراجعه کنید.

           hook.<friendly-name>.parallel
               مشخص می‌کند که آیا قلاب hook.<friendly-name> ممکن است به صورت
               موازی با سایر قلاب‌ها برای همان رویداد اجرا شود یا خیر. پیش‌فرض
               false است. تنها زمانی روی true تنظیم کنید که اسکریپت قلاب برای
               اجرای هم‌روند با سایر قلاب‌ها برای همان رویداد ایمن باشد. اگر هر
               قلابی برای یک رویداد این گزینه را روی true تنظیم نکرده باشد،
               تمام قلاب‌ها برای آن رویداد صرف‌نظر از hook.jobs به صورت متوالی
               اجرا می‌شوند. فقط قلاب‌های پیکربندی‌شده (نام‌گذاری‌شده) نیاز به
               اعلام این مورد دارند. قلاب‌های سنتی موجود در پوشه hooks نیازی به
               این کار ندارند و زمانی که تعداد کارهای مؤثر بزرگ‌تر از 1 باشد به
               صورت موازی اجرا می‌شوند. به git-hook(1) مراجعه کنید.

           hook.<event>.enabled
               کلید برای فعال یا غیرفعال کردن تمام قلاب‌ها برای رویداد قلاب
               <event> است. هنگامی که روی false تنظیم شود، هیچ قلابی برای آن
               رویداد اجرا نمی‌شود، صرف‌نظر از هرگونه تنظیمات اختصاصی
               hook.<friendly-name>.enabled برای هر قلاب. مقدار پیش‌فرض true
               است. رجوع کنید به git-hook(1).

               نکته در مورد نام‌گذاری: <event> باید نام رویداد باشد (مثلاً
               pre-commit)، نه نام دوستانه (friendly-name) قلاب. از آنجا که
               استفاده از یک نام رویداد شناخته‌شده به عنوان friendly-name مجاز
               نیست (ببینید hook.<friendly-name>.event در بالا)، هیچ ابهامی
               بین تنظیمات .enabled در سطح رویداد و در سطح هر قلاب برای
               رویدادهای شناخته‌شده وجود ندارد. برای رویدادهای ناشناخته، اگر یک
               friendly-name برخلاف هشدار با نام رویداد مطابقت داشته باشد،
               .enabled تنها به عنوان تنظیم اختصاصی هر قلاب در نظر گرفته
               می‌شود.

           hook.<event>.jobs
               مشخص می‌کند چه تعداد قلاب می‌توانند به طور هم‌زمان برای رویداد
               قلاب <event> اجرا شوند (مثلاً hook.post-receive.jobs = 4).
               مقدار hook.jobs را برای این رویداد خاص بازنویسی می‌کند. همان
               محدودیت‌های موازی‌سازی اعمال می‌شوند: این تنظیم هیچ تاثیری ندارد
               مگر آنکه تمام قلاب‌های پیکربندی‌شده برای آن رویداد دارای
               hook.<friendly-name>.parallel تنظیم‌شده روی true باشند. مقدار را
               روی -1 تنظیم کنید تا از تعداد هسته‌های موجود CPU استفاده شود.
               باید یک عدد صحیح مثبت یا -1 باشد؛ مقدار صفر همراه با یک هشدار
               رد می‌شود. رجوع کنید به git-hook(1).

               نکته در مورد نام‌گذاری: هرچند این کلید شبیه به
               hook.<friendly-name>.* (یک تنظیم اختصاصی هر قلاب) است، <event>
               باید نام رویداد باشد، نه نام دوستانه قلاب. جزء کلید به صورت
               تحت‌اللفظی ذخیره می‌شود و در زمان اجرا بر اساس نام رویداد و بدون
               هیچ ترجمه‌ای بین این دو فضای نام جستجو می‌شود. کلیدی مانند
               hook.my-hook.jobs تحت "my-hook" ذخیره می‌شود اما جستجو در زمان
               اجرا از نام رویداد (مثلاً "post-receive") استفاده می‌کند،
               بنابراین hook.my-hook.jobs حتی در صورت ثبت بودن my-hook برای آن
               رویداد، بدون هشدار نادیده گرفته می‌شود. هنگام تنظیم
               hook.<event>.jobs از hook.post-receive.jobs یا هر نام رویداد
               معتبر دیگری استفاده کنید.

           hook.jobs
               مشخص می‌کند چه تعداد قلاب می‌توانند در طول اجرای موازی قلاب‌ها به
               طور هم‌زمان اجرا شوند. در صورت عدم تعیین، مقدار پیش‌فرض ۱ (اجرای
               ترتیبی) است. برای استفاده از تعداد هسته‌های موجود CPU، آن را روی
               -1 تنظیم کنید. می‌تواند بر مبنای هر رویداد با hook.<event>.jobs
               بازنویسی شود. برخی قلاب‌ها صرف‌نظر از این تنظیم همیشه به صورت
               ترتیبی اجرا می‌شوند، زیرا روی داده‌های مشترک عمل می‌کنند و
               نمی‌توانند با اطمینان موازی شوند:

               applypatch-msg, prepare-commit-msg, commit-msg
                   یک فایل پیام ثبت را دریافت می‌کنند و ممکن است در همان جا آن
                   را بازنویسی کنند.

               pre-commit, post-checkout, push-to-checkout, post-commit
                   به درخت کاری، ایندکس یا وضعیت مخزن دسترسی پیدا می‌کنند.

               این تنظیم هیچ اثری ندارد مگر آنکه تمام قلاب‌های پیکربندی‌شده برای
               آن رویداد، hook.<friendly-name>.parallel را روی true تنظیم کرده
               باشند.

               برای قلاب‌های pre-push که به طور عادی stdout و stderr را مجزا
               نگه می‌دارند، تنظیم این مقدار به بیش از ۱ (یا ارسال -j) باعث
               ادغام خروجی استاندارد در خطای استاندارد می‌شود تا تفکیک موازی
               خروجی‌ها به درستی صورت گیرد.

           http.proxy
               پروکسی HTTP را بازنویسی می‌کند، که معمولاً با استفاده از متغیرهای
               محیطی http_proxy, https_proxy, و all_proxy پیکربندی می‌شود (رجوع
               کنید به curl(1)). علاوه بر نحو قابل فهم برای curl، امکان تعیین
               یک رشته پروکسی با نام کاربری اما بدون گذرواژه وجود دارد که در
               این حالت git تلاش می‌کند به همان شیوه‌ای که برای سایر
               اعتبارنامه‌ها عمل می‌کند، گذرواژه‌ای به دست آورد. برای اطلاعات
               بیشتر gitcredentials(7) را ببینید. بنابراین ساختار نگارش به
               صورت [protocol://][user[:password]@]proxyhost[:port][/path]
               است. این مقدار می‌تواند برای هر ریموت بازنویسی شود؛ ببینید
               remote.<name>.proxy

               هر پروکسی، صرف‌نظر از نحوه پیکربندی، باید کاملاً شفاف باشد و
               نباید به هیچ وجه درخواست یا پاسخ را تغییر دهد، تبدیل کند یا
               بافر نماید. پروکسی‌هایی که کاملاً شفاف نیستند، شناخته شده است که
               موجب انواع مختلفی از خرابی‌ها در کار با Git می‌شوند.

           http.proxyAuthMethod
               روشی را تعیین می‌کند که با آن احراز هویت در برابر پروکسی HTTP
               انجام شود. این تنها در صورتی اعمال می‌شود که رشته پروکسی
               پیکربندی‌شده حاوی بخش نام کاربری باشد (یعنی به فرم user@host یا
               user@host:port باشد). این می‌تواند برای هر ریموت بازنویسی شود؛
               ببینید remote.<name>.proxyAuthMethod. هر دو می‌توانند توسط متغیر
               محیطی GIT_HTTP_PROXY_AUTHMETHOD بازنویسی شوند. مقادیر ممکن
               عبارتند از:

               •   anyauth - انتخاب خودکار یک روش احراز هویت مناسب. فرض بر این
                   است که پروکسی به یک درخواست احراز هویت‌نشده با کد وضعیت 407
                   و یک یا چند سرآیند Proxy-authenticate با روش‌های احراز هویت
                   پشتیبانی‌شده پاسخ می‌دهد. این مقدار پیش‌فرض است.

               •   basic - احراز هویت HTTP Basic

               •   digest - احراز هویت HTTP Digest؛ این روش از ارسال گذرواژه
                   به صورت متن آشکار به پروکسی جلوگیری می‌کند

               •   negotiate - احراز هویت GSS-Negotiate (مقایسه کنید با گزینه
                   --negotiate در curl(1))

               •   ntlm - احراز هویت NTLM (مقایسه کنید با گزینه --ntlm در
                   curl(1))

           http.proxySSLCert
               مسیر فایلی که یک گواهی کلاینت را برای احراز هویت در برابر یک
               پروکسی HTTPS ذخیره می‌کند. می‌تواند توسط متغیر محیطی
               GIT_PROXY_SSL_CERT بازنویسی شود.

           http.proxySSLKey
               مسیر فایلی که یک کلید خصوصی را برای احراز هویت در برابر یک
               پروکسی HTTPS ذخیره می‌کند. می‌تواند توسط متغیر محیطی
               GIT_PROXY_SSL_KEY بازنویسی شود.

           http.proxySSLCertPasswordProtected
               درخواست گذرواژه Git برای گواهی SSL پروکسی را فعال می‌کند. در غیر
               این صورت، اگر گواهی یا کلید خصوصی رمزنگاری شده باشد، OpenSSL
               ممکن است مکرراً از کاربر درخواست گذرواژه کند. می‌تواند توسط متغیر
               محیطی GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED بازنویسی شود.

           http.proxySSLCAInfo
               مسیر فایل حاوی بسته گواهی که باید هنگام استفاده از پروکسی HTTPS
               برای اعتبارسنجی پروکسی استفاده شود. می‌تواند توسط متغیر محیطی
               GIT_PROXY_SSL_CAINFO بازنویسی شود.

           http.emptyAuth
               تلاش برای احراز هویت بدون درخواست نام کاربری یا گذرواژه. این
               می‌تواند برای تلاش جهت احراز هویت GSS-Negotiate بدون تعیین نام
               کاربری در URL استفاده شود، زیرا libcurl معمولاً برای احراز هویت
               به نام کاربری نیاز دارد. مقادیر ممکن عبارتند از:

               •   auto (پیش‌فرض) - ارسال اطلاعات اعتبارنامه خالی تنها در صورتی
                   که پاسخ 401 سرور سازوکار احراز هویتی را اعلام کند که به
                   آنها نیاز دارد (مانند GSS-Negotiate)؛ در غیر این صورت به
                   درخواست از طریق دستیار اعتبارنامه رجوع می‌کند.

               •   true - همیشه در همان اولین درخواست، پیش از دریافت هرگونه
                   پاسخ 401 از سرور، اعتبارنامه‌های خالی ارسال شود.

               •   false - هرگز اعتبارنامه‌های خالی ارسال نشود. سازوکارهایی که
                   به اعتبارنامه‌های خالی یا یک نام کاربری صریح نیاز دارند،
                   مانند GSS-Negotiate، کار نخواهند کرد.

           http.proactiveAuth
               تلاش برای احراز هویت بدون انجام تلاش اولیه بدون احراز هویت و
               دریافت پاسخ 401. این می‌تواند برای اطمینان از احراز هویت تمام
               درخواست‌ها استفاده شود. اگر http.emptyAuth روی true تنظیم شده
               باشد، این مقدار تاثیری ندارد.

               اگر دستیار اعتبارنامه مورد استفاده، یک طرح احراز هویت را مشخص
               کند (یعنی از طریق فیلد authtype)، آن مقدار استفاده خواهد شد؛
               اگر نام کاربری و گذرواژه بدون طرح مشخصی ارائه شوند، احراز هویت
               Basic استفاده می‌شود. مقدار این گزینه، طرح درخواستی از دستیار را
               تعیین می‌کند. مقادیر ممکن عبارتند از:

               •   basic - درخواست احراز هویت Basic از دستیار.

               •   auto - اجازه دادن به دستیار برای انتخاب طرح مناسب.

               •   none - غیرفعال کردن احراز هویت پیش‌دستانه.

               توجه داشته باشید که با این پیکربندی همیشه باید از TLS استفاده
               شود، زیرا در غیر این صورت، در صورت انتخاب احراز هویت Basic،
               اعتبارنامه‌های متنی ساده ممکن است به راحتی و تصادفاً افشا شوند.

           http.delegation
               تفویض اعتبارنامه GSSAPI را کنترل می‌کند. تفویض به طور پیش‌فرض در
               libcurl از نسخه 7.21.7 غیرفعال است. این پارامتر را تنظیم کنید
               تا به سرور اعلام شود در مورد اعتبارنامه‌های کاربر مجاز به تفویض
               چه چیزی است. همراه با GSS/kerberos استفاده می‌شود. مقادیر ممکن
               عبارتند از:

               •   none - هیچ تفویضی مجاز نباشد.

               •   policy - تفویض تنها و تنها در صورتی انجام شود که پرچم
                   OK-AS-DELEGATE در بلیت سرویس Kerberos تنظیم شده باشد، که به
                   خط‌مشی قلمرو مربوط می‌شود.

               •   always - سرور بدون قید و شرط مجاز به تفویض باشد.

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

           http.cookieFile
               مسیر فایلی حاوی خطوط کوکی قبلاً ذخیره‌شده، که در صورت تطابق با
               سرور باید در نشست http گیت استفاده شوند. قالب فایل برای خواندن
               کوکی‌ها باید سرآیندهای ساده HTTP یا قالب فایل کوکی
               Netscape/Mozilla باشد (ببینید curl(1)). آن را روی یک رشته خالی
               تنظیم کنید تا فقط کوکی‌های جدید از سرور پذیرفته شوند و در
               درخواست‌های متوالی در همان اتصال بازگردانده شوند. توجه داشته
               باشید که فایل مشخص‌شده با http.cookieFile تنها به عنوان ورودی
               استفاده می‌شود مگر اینکه http.saveCookies تنظیم شده باشد.

           http.saveCookies
               در صورت تنظیم، کوکی‌های دریافت‌شده در طول درخواست‌ها را در فایل
               مشخص‌شده توسط http.cookieFile ذخیره می‌کند. اگر http.cookieFile
               تنظیم نشده باشد یا روی یک رشته خالی تنظیم شده باشد، هیچ اثری
               ندارد.

           http.version
               هنگام برقراری ارتباط با یک سرور از نسخه پروتکل مشخص‌شده HTTP
               استفاده می‌کند، در صورتی که بخواهید بر مقدار پیش‌فرض پافشاری
               کنید. نسخه موجود و پیش‌فرض به libcurl بستگی دارد. در حال حاضر
               مقادیر ممکن برای این گزینه عبارتند از:

               •   HTTP/2

               •   HTTP/1.1

           http.curloptResolve
               اطلاعات تفکیک نام میزبان که هنگام ارسال درخواست‌های HTTP ابتدا
               توسط libcurl استفاده خواهد شد. این اطلاعات باید در یکی از
               قالب‌های زیر باشد:

               •   [+]HOST:PORT:ADDRESS[,ADDRESS]

               •   -HOST:PORT

               قالب اول تمام درخواست‌ها به HOST:PORT داده‌شده را به ADDRESS(های)
               ارائه‌شده هدایت می‌کند. قالب دوم تمام مقادیر پیکربندی قبلی را
               برای آن ترکیب HOST:PORT پاک می‌کند. برای امکان بازنویسی آسان
               تمام تنظیمات به ارث رسیده از پیکربندی سیستم، یک مقدار خالی تمام
               اطلاعات تفکیک را به فهرست خالی بازنشانی می‌کند.

           http.sslVersion
               نسخه SSL برای استفاده هنگام مذاکره بر سر اتصال SSL، در صورتی که
               بخواهید بر مقدار پیش‌فرض پافشاری کنید. نسخه موجود و پیش‌فرض به
               این بستگی دارد که آیا libcurl در برابر NSS ساخته شده است یا
               OpenSSL و همچنین به پیکربندی خاص کتابخانه رمزنوشتاری مورد
               استفاده وابسته است. به صورت داخلی این متغیر گزینه
               CURLOPT_SSL_VERSION را تنظیم می‌کند؛ برای جزئیات بیشتر در مورد
               قالب این گزینه و نسخه ssl پشتیبانی‌شده به مستندات libcurl مراجعه
               کنید. در حال حاضر مقادیر ممکن برای این گزینه عبارتند از:

               •   sslv2

               •   sslv3

               •   tlsv1

               •   tlsv1.0

               •   tlsv1.1

               •   tlsv1.2

               •   tlsv1.3

               می‌تواند توسط متغیر محیطی GIT_SSL_VERSION بازنویسی شود. برای
               اجبار git به استفاده از نسخه پیش‌فرض ssl در libcurl و نادیده
               گرفتن هر گزینه صریح http.sslversion، متغیر GIT_SSL_VERSION را
               روی یک رشته خالی تنظیم کنید.

           http.sslCipherList
               فهرستی از الگوریتم‌های رمزنگاری (ciphers) SSL برای استفاده هنگام
               مذاکره بر سر یک اتصال SSL. الگوریتم‌های رمزنگاری در دسترس به این
               بستگی دارند که libcurl در برابر NSS ساخته شده است یا OpenSSL و
               همچنین به پیکربندی خاص کتابخانه رمزنوشتاری مورد استفاده وابسته
               است. به صورت داخلی این متغیر گزینه CURLOPT_SSL_CIPHER_LIST را
               تنظیم می‌کند؛ برای جزئیات بیشتر درباره قالب این فهرست به مستندات
               libcurl مراجعه کنید.

               می‌تواند توسط متغیر محیطی GIT_SSL_CIPHER_LIST بازنویسی شود. برای
               اجبار git به استفاده از فهرست پیش‌فرض الگوریتم‌های رمزنگاری
               libcurl و نادیده گرفتن هر گزینه صریح http.sslCipherList، متغیر
               GIT_SSL_CIPHER_LIST را روی یک رشته خالی تنظیم کنید.

           http.sslVerify
               آیا گواهی SSL هنگام واکشی یا ارسال روی HTTPS اعتبارسنجی شود یا
               خیر. پیش‌فرض true است. می‌تواند توسط متغیر محیطی
               GIT_SSL_NO_VERIFY بازنویسی شود.

           http.sslCert
               فایل حاوی گواهی SSL هنگام واکشی یا ارسال روی HTTPS. می‌تواند
               توسط متغیر محیطی GIT_SSL_CERT بازنویسی شود.

           http.sslKey
               فایل حاوی کلید خصوصی SSL هنگام واکشی یا ارسال روی HTTPS.
               می‌تواند توسط متغیر محیطی GIT_SSL_KEY بازنویسی شود.

           http.sslCertPasswordProtected
               درخواست دریافت گذرواژه Git برای گواهی SSL را فعال می‌کند. در غیر
               این صورت، اگر گواهی یا کلید خصوصی رمزنگاری شده باشد، OpenSSL
               ممکن است مکرراً از کاربر درخواست گذرواژه کند. می‌تواند توسط متغیر
               محیطی GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED بازنویسی شود.

           http.sslCAInfo
               فایل حاوی گواهی‌ها برای اعتبارسنجی طرف مقابل (peer) هنگام واکشی
               یا ارسال روی HTTPS. می‌تواند توسط متغیر محیطی GIT_SSL_CAINFO
               بازنویسی شود.

           http.sslCAPath
               مسیر حاوی فایل‌های گواهی‌های CA برای اعتبارسنجی طرف مقابل هنگام
               واکشی یا ارسال روی HTTPS. می‌تواند توسط متغیر محیطی
               GIT_SSL_CAPATH بازنویسی شود.

           http.sslBackend
               نام بک‌اند SSL برای استفاده (مثلاً "openssl" یا "schannel"). اگر
               cURL فاقد پشتیبانی برای انتخاب بک‌اند SSL در زمان اجرا باشد، این
               گزینه نادیده گرفته می‌شود.

           http.sslCertType
               نوع گواهی کلاینت مورد استفاده هنگام واکشی یا ارسال روی HTTPS.
               مقادیر "PEM" و "DER" هنگام استفاده از بک‌اندهای openssl یا
               gnutls پشتیبانی می‌شوند. مقدار "P12" روی "openssl"، "schannel"،
               "securetransport" و gnutls نسخه 8.11+ پشتیبانی می‌شود. همچنین
               رجوع کنید به CURLOPT_SSLCERTTYPE در libcurl. می‌تواند توسط متغیر
               محیطی GIT_SSL_CERT_TYPE بازنویسی شود.

           http.sslKeyType
               نوع کلید خصوصی کلاینت مورد استفاده هنگام واکشی یا ارسال روی
               HTTPS (مثلاً "PEM"، "DER" یا "ENG"). تنها هنگام استفاده از بک‌اند
               "openssl" قابل اعمال است. مقدار "DER" با openssl پشتیبانی
               نمی‌شود. به ویژه هنگام تنظیم روی "ENG" برای احراز هویت با
               توکن‌های PKCS#11 به همراه یک URL مربوط به PKCS#11 در گزینه
               sslCert بسیار مفید است. همچنین رجوع کنید به CURLOPT_SSLKEYTYPE
               در libcurl. می‌تواند توسط متغیر محیطی GIT_SSL_KEY_TYPE بازنویسی
               شود.

           http.schannelCheckRevoke
               برای اجبار یا غیرفعال کردن بررسی ابطال گواهی در cURL هنگامی که
               http.sslBackend روی "schannel" تنظیم شده است، استفاده می‌شود. در
               صورت عدم تنظیم، پیش‌فرض true است. غیرفعال کردن این گزینه تنها در
               صورتی ضروری است که Git مداوماً با خطا مواجه شود و پیام خطا مربوط
               به بررسی وضعیت ابطال یک گواهی باشد. اگر cURL فاقد پشتیبانی برای
               تنظیم گزینه مربوطه SSL در زمان اجرا باشد، این گزینه نادیده
               گرفته می‌شود.

           http.schannelUseSSLCAInfo
               از نسخه cURL v7.60.0 به بعد، بک‌اند Secure Channel می‌تواند از
               بسته گواهی ارائه‌شده از طریق http.sslCAInfo استفاده کند، اما این
               کار انبار گواهی ویندوز (Windows Certificate Store) را بازنویسی
               می‌کند. از آنجا که این رفتار به طور پیش‌فرض مطلوب نیست، Git به
               cURL می‌گوید هنگامی که بک‌اند schannel از طریق http.sslBackend
               پیکربندی شده است، به طور پیش‌فرض از آن بسته استفاده نکند، مگر
               اینکه http.schannelUseSSLCAInfo این رفتار را بازنویسی کند.

           http.pinnedPubkey
               کلید عمومی سرویس https. این می‌تواند نام فایل یک فایل کلید عمومی
               با کدگذاری PEM یا DER باشد، یا رشته‌ای که با sha256// آغاز شده و
               پس از آن هش sha256 کدگذاری‌شده با base64 از کلید عمومی قرار
               دارد. همچنین رجوع کنید به CURLOPT_PINNEDPUBLICKEY در libcurl.
               اگر این گزینه تنظیم شود اما توسط cURL پشتیبانی نشود، git با یک
               خطا خارج خواهد شد.

           http.sslTry
               تلاش برای استفاده از AUTH SSL/TLS و انتقال داده‌های رمزشده هنگام
               اتصال از طریق پروتکل معمولی FTP. این ممکن است در صورتی لازم
               باشد که سرور FTP به دلایل امنیتی به آن نیاز داشته باشد یا شما
               بخواهید هر زمان که سرور FTP ریموت از آن پشتیبانی می‌کند به صورت
               امن متصل شوید. مقدار پیش‌فرض false است زیرا ممکن است در سرورهایی
               با پیکربندی نادرست خطاهای اعتبارسنجی گواهی ایجاد کند.

           http.maxRequests
               چه تعداد درخواست HTTP به صورت موازی اجرا شوند. می‌تواند توسط
               متغیر محیطی GIT_HTTP_MAX_REQUESTS بازنویسی شود. پیش‌فرض 5 است.

           http.minSessions
               تعداد نشست‌های curl (شمارش‌شده در اسلات‌ها) که باید در طول
               درخواست‌ها باز نگه داشته شوند. آن‌ها تا زمان فراخوانی
               http_cleanup() با curl_easy_cleanup() پایان نخواهند یافت. اگر
               USE_CURL_MULTI تعریف نشده باشد، این مقدار حداکثر به ۱ محدود
               می‌شود. پیش‌فرض ۱ است.

           http.postBuffer
               حداکثر اندازه بر حسب بایت برای بافر مورد استفاده توسط انتقالات
               هوشمند HTTP هنگام ارسال داده به سیستم ریموت با POST. برای
               درخواست‌های بزرگتر از این اندازه بافر، از HTTP/1.1 و
               Transfer-Encoding: chunked استفاده می‌شود تا از ایجاد یک فایل
               بسته بسیار بزرگ به صورت محلی جلوگیری شود. مقدار پیش‌فرض 1 MiB
               است که برای اکثر درخواست‌ها کافی می‌باشد.

               توجه داشته باشید که افزایش این حد تنها برای غیرفعال کردن
               کدگذاری انتقال تکه‌ای موثر است و بنابراین فقط باید در جایی
               استفاده شود که سرور ریموت یا پروکسی تنها از HTTP/1.0 پشتیبانی
               می‌کند یا با استاندارد HTTP سازگار نیست. افزایش این مقدار به طور
               کلی راه‌حل موثری برای اکثر مشکلات push نیست، اما می‌تواند مصرف
               حافظه را به شدت افزایش دهد زیرا کل بافر حتی برای ارسال‌های کوچک
               نیز تخصیص داده می‌شود.

           http.lowSpeedLimit, http.lowSpeedTime
               اگر سرعت انتقال HTTP بر حسب بایت در ثانیه، کمتر از
               http.lowSpeedLimit برای مدت زمانی بیش از http.lowSpeedTime
               ثانیه باشد، انتقال متوقف می‌شود. می‌تواند توسط متغیرهای محیطی
               GIT_HTTP_LOW_SPEED_LIMIT و GIT_HTTP_LOW_SPEED_TIME بازنویسی
               شود.

           http.keepAliveIdle
               مدت زمان انتظار بر حسب ثانیه را روی یک اتصال بیکار پیش از ارسال
               کاوشگرهای TCP keepalive (در صورت پشتیبانی سیستم‌عامل) مشخص
               می‌کند. اگر تنظیم نشده باشد، مقدار پیش‌فرض curl استفاده می‌شود.
               می‌تواند توسط متغیر محیطی GIT_HTTP_KEEPALIVE_IDLE بازنویسی شود.

           http.keepAliveInterval
               مدت زمان انتظار بر حسب ثانیه میان کاوشگرهای TCP keepalive را
               (در صورت پشتیبانی سیستم‌عامل) مشخص می‌کند. اگر تنظیم نشده باشد،
               مقدار پیش‌فرض curl استفاده می‌شود. می‌تواند توسط متغیر محیطی
               GIT_HTTP_KEEPALIVE_INTERVAL بازنویسی شود.

           http.keepAliveCount
               مشخص می‌کند چه تعداد کاوشگر TCP keepalive پیش از صرف‌نظر کردن و
               قطع اتصال (در صورت پشتیبانی سیستم‌عامل) ارسال شود. اگر تنظیم
               نشده باشد، مقدار پیش‌فرض curl استفاده می‌شود. می‌تواند توسط متغیر
               محیطی GIT_HTTP_KEEPALIVE_COUNT بازنویسی شود.

           http.retryAfter
               زمان انتظار پیش‌فرض بر حسب ثانیه قبل از تلاش مجدد، زمانی که سرور
               پاسخ HTTP 429 (Too Many Requests) را بدون سرآیند Retry-After
               برمی‌گرداند. پیش‌فرض 0 (تلاش مجدد فوری) است. هنگامی که سرآیند
               Retry-After وجود داشته باشد، مقدار آن بر این تنظیم اولویت دارد؛
               با این حال، استفاده خودکار از سرآیند Retry-After ارائه‌شده توسط
               سرور نیازمند libcurl نسخه 7.66.0 یا جدیدتر است. در نسخه‌های
               قدیمی‌تر، این تنظیم را به صورت دستی پیکربندی کنید تا تاخیر تلاش
               مجدد را کنترل نمایید. می‌تواند توسط متغیر محیطی
               GIT_HTTP_RETRY_AFTER بازنویسی شود. همچنین ببینید
               http.maxRetries و http.maxRetryTime.

           http.maxRetries
               حداکثر تعداد دفعات تلاش مجدد پس از دریافت پاسخ‌های HTTP 429 (Too
               Many Requests). برای غیرفعال کردن تلاش‌های مجدد، آن را روی 0
               (پیش‌فرض) قرار دهید. می‌تواند توسط متغیر محیطی
               GIT_HTTP_MAX_RETRIES بازنویسی شود. همچنین ببینید
               http.retryAfter و http.maxRetryTime.

           http.maxRetryTime
               حداکثر زمان بر حسب ثانیه برای انتظار جهت یک تلاش مجدد منفرد
               هنگام رسیدگی به پاسخ‌های HTTP 429 (Too Many Requests). اگر سرور
               درخواست تاخیر کند (از طریق سرآیند Retry-After) یا اگر
               http.retryAfter با مقداری پیکربندی شده باشد که از این حداکثر
               فراتر رود، Git به جای انتظار بلافاصله با خطا متوقف می‌شود.
               پیش‌فرض 300 ثانیه (5 دقیقه) است. می‌تواند توسط متغیر محیطی
               GIT_HTTP_MAX_RETRY_TIME بازنویسی شود. همچنین ببینید
               http.retryAfter و http.maxRetries.

           http.noEPSV
               یک مقدار بولی که استفاده از دستور ftp موسوم به EPSV توسط curl
               را غیرفعال می‌کند. این می‌تواند در مواجهه با برخی سرورهای ftp
               ضعیف که از حالت EPSV پشتیبانی نمی‌کنند مفید باشد. می‌تواند توسط
               متغیر محیطی GIT_CURL_FTP_NO_EPSV بازنویسی شود. پیش‌فرض false است
               (curl از EPSV استفاده خواهد کرد).

           http.userAgent
               رشته USER_AGENT پروتکل HTTP ارائه‌شده به یک سرور HTTP. مقدار
               پیش‌فرض بیانگر نسخه کلاینت Git است، مانند git/1.7.1. این گزینه
               به شما امکان می‌دهد این مقدار را با مقداری متداول‌تر مانند
               Mozilla/4.0 بازنویسی کنید. برای نمونه، در صورتی که اتصال از
               طریق یک فایروال انجام شود که اتصالات HTTP را به مجموعه‌ای از
               رشته‌های متداول USER_AGENT محدود می‌کند (و مواردی مانند git/1.7.1
               را در بر نمی‌گیرد)، ممکن است لازم باشد. می‌تواند توسط متغیر محیطی
               GIT_HTTP_USER_AGENT بازنویسی شود.

           http.followRedirects
               آیا git باید تغییر مسیرهای HTTP را دنبال کند یا خیر. اگر روی
               true تنظیم شود، git به صورت شفاف هرگونه تغییر مسیری که توسط
               سرور صادر شود را دنبال خواهد کرد. اگر روی false تنظیم شود، git
               با تمام تغییر مسیرها به عنوان خطا برخورد می‌کند. اگر روی initial
               تنظیم شود، git تغییر مسیرها را تنها برای درخواست اولیه به یک
               ریموت دنبال می‌کند، اما نه برای درخواست‌های متوالی بعدی HTTP. از
               آنجا که git از URL تغییر مسیر یافته به عنوان مبنا برای
               درخواست‌های بعدی استفاده می‌کند، این حالت عموماً کافی است. مقدار
               پیش‌فرض initial است.

           http.<url>.*
               هر یک از گزینه‌های http.* بالا را می‌توان به صورت انتخابی روی
               برخی URLها اعمال کرد. برای اینکه یک کلید پیکربندی با یک URL
               مطابقت داشته باشد، هر عنصر از کلید پیکربندی با عنصر متناظر در
               URL، به ترتیب زیر مقایسه می‌شود:

                1. طرح (مثلاً https در https://example.com/). این فیلد باید بین
                   کلید پیکربندی و URL دقیقاً مطابقت داشته باشد.

                2. نام میزبان/دامنه (مثلاً example.com در
                   https://example.com/). این فیلد باید بین کلید پیکربندی و
                   URL مطابقت داشته باشد. امکان تعیین یک * به عنوان بخشی از
                   نام میزبان برای تطبیق با تمام زیردامنه‌ها در این سطح وجود
                   دارد.  برای مثال https://*.example.com/ با
                   https://foo.example.com/ مطابقت دارد، اما با
                   https://foo.bar.example.com/ تطابق ندارد.

                3. شماره پورت (مثلاً 8080 در http://example.com:8080/). این
                   فیلد باید بین کلید پیکربندی و URL دقیقاً مطابقت داشته باشد.
                   شماره پورت‌های حذف‌شده قبل از تطبیق به طور خودکار به مقدار
                   پیش‌فرض صحیح برای طرح مربوطه تبدیل می‌شوند.

                4. مسیر (مثلاً repo.git در https://example.com/repo.git). فیلد
                   مسیر کلید پیکربندی باید با فیلد مسیر URL به صورت دقیق یا به
                   عنوان پیشوندی از عناصر مسیر تفکیک‌شده با اسلش مطابقت داشته
                   باشد. این بدان معناست که یک کلید پیکربندی با مسیر foo/ با
                   مسیر URL foo/bar تطابق دارد. یک پیشوند تنها می‌تواند روی مرز
                   اسلش (/) مطابقت یابد. تطابق‌های طولانی‌تر اولویت دارند
                   (بنابراین یک کلید پیکربندی با مسیر foo/bar نسبت به کلید
                   پیکربندی با صرف مسیر foo/ تطابق بهتری با مسیر URL foo/bar
                   دارد).

                5. نام کاربری (مثلاً user در
                   https://user@example.com/repo.git). اگر کلید پیکربندی دارای
                   نام کاربری باشد، باید دقیقاً با نام کاربری موجود در URL
                   مطابقت داشته باشد. اگر کلید پیکربندی نام کاربری نداشته
                   باشد، آن کلید با هر نام کاربری در URL (از جمله بدون نام
                   کاربری) مطابقت خواهد داشت، اما با اولویتی کمتر نسبت به کلید
                   دارای نام کاربری.

               فهرست فوق به ترتیب اولویت نزولی مرتب شده است؛ یک URL که با مسیر
               یک کلید پیکربندی مطابقت دارد، نسبت به موردی که با نام کاربری آن
               مطابقت دارد ترجیح داده می‌شود. برای مثال، اگر URL برابر با
               https://user@example.com/foo/bar باشد، تطابق کلید پیکربندی با
               https://example.com/foo بر تطابق کلید پیکربندی با
               https://user@example.com ترجیح داده خواهد شد.

               تمامی URLها قبل از هرگونه تلاش برای تطبیق، یکسان‌سازی
               (نرمال‌سازی) می‌شوند (بخش گذرواژه، در صورت وجود در URL، برای
               مقاصد تطبیق همیشه نادیده گرفته می‌شود) تا URLهای معادل که صرفاً
               املای متفاوتی دارند به درستی تطبیق یابند. تنظیمات متغیرهای
               محیطی همواره بر هرگونه تطبیقی اولویت دارند. URLهایی که مورد
               مقایسه قرار می‌گیرند، مواردی هستند که مستقیماً به دستورات Git
               داده می‌شوند. این بدان معنی است که هرگونه URL بازدیدشده در نتیجه
               تغییر مسیر در تطبیق شرکت نمی‌کند.

           i18n.commitEncoding
               کدگذاری نویسه‌ها که پیام‌های ثبت در آن ذخیره می‌شوند؛ خود Git به
               خودی خود اهمیتی به آن نمی‌دهد، اما این اطلاعات مثلاً هنگام وارد
               کردن کامیت‌ها از ایمیل‌ها یا در مرورگر گرافیکی تاریخچه gitk (و
               احتمالاً در مکان‌های دیگر در آینده یا در سایر رابط‌های سطح بالا)
               ضروری است. به عنوان مثال رجوع کنید به git-mailinfo(1). مقدار
               پیش‌فرض utf-8 است.

           i18n.logOutputEncoding
               کدگذاری نویسه‌ها که هنگام اجرای git log و دستورات مرتبط، پیام‌های
               ثبت به آن تبدیل می‌شوند.

           imap.folder
               پوشه‌ای که نامه‌ها باید در آن قرار گیرند، که معمولاً پوشه
               پیش‌نویس‌ها (Drafts) است. برای مثال: INBOX.Drafts, INBOX/Drafts
               یا [Gmail]/Drafts. پوشه IMAP برای تعامل حتماً باید مشخص شود؛
               مقدار این متغیر پیکربندی به عنوان مقدار پیش‌فرض جایگزین در صورتی
               که گزینه --folder داده نشده باشد، استفاده می‌شود.

           imap.tunnel
               دستوری که برای ایجاد یک تونل به سرور IMAP استفاده می‌شود تا
               دستورات به جای استفاده از اتصال مستقیم شبکه‌ای به سرور، از طریق
               آن هدایت شوند. در صورتی که imap.host تنظیم نشده باشد، الزامی
               است.

           imap.host
               یک URL که سرور را مشخص می‌کند. از یک پیشوند imap:// برای اتصالات
               غیرامن و یک پیشوند imaps:// برای اتصالات امن استفاده کنید.
               هنگامی که imap.tunnel تنظیم شده باشد نادیده گرفته می‌شود، اما در
               غیر این صورت الزامی است.

           imap.user
               نام کاربری مورد استفاده هنگام ورود به سرور.

           imap.pass
               گذرواژه مورد استفاده هنگام ورود به سرور.

           imap.port
               یک عدد صحیح برای پورت اتصال به سرور. پیش‌فرض 143 برای میزبان‌های
               imap:// و 993 برای میزبان‌های imaps:// است. هنگامی که
               imap.tunnel تنظیم شده باشد نادیده گرفته می‌شود.

           imap.sslverify
               یک مقدار بولی برای فعال/غیرفعال کردن اعتبارسنجی گواهی سرور مورد
               استفاده توسط اتصال SSL/TLS. پیش‌فرض true است. هنگامی که
               imap.tunnel تنظیم شده باشد نادیده گرفته می‌شود.

           imap.preformattedHTML
               یک مقدار بولی برای فعال/غیرفعال کردن استفاده از کدگذاری html
               هنگام ارسال وصله. یک وصله کدگذاری‌شده با html درون تگ‌های <pre>
               قرار می‌گیرد و نوع محتوای text/html خواهد داشت. جالب اینجاست که
               فعال کردن این گزینه باعث می‌شود Thunderbird وصله را به صورت یک
               ایمیل plain/text با format=fixed ارسال کند. مقدار پیش‌فرض false
               است.

           imap.authMethod
               روش احراز هویت را برای احراز هویت در سرور IMAP مشخص می‌کند. اگر
               Git با گزینه NO_CURL ساخته شده باشد، یا اگر نسخه curl شما
               قدیمی‌تر از 7.34.0 باشد، یا اگر git-imap-send را با گزینه
               --no-curl اجرا می‌کنید، تنها روش‌های پشتیبانی‌شده عبارتند از
               PLAIN, CRAM-MD5, OAUTHBEARER و XOAUTH2. اگر این مقدار تنظیم
               نشده باشد، git imap-send از دستور متنی ساده IMAP یعنی LOGIN
               استفاده می‌کند.

           include.path, includeIf.<condition>.path
               متغیرهای ویژه برای گنجاندن سایر فایل‌های پیکربندی. به بخش
               "CONFIGURATION FILE" در مستندات اصلی git-config(1)، به ویژه
               زیربخش‌های "Includes" و "Conditional Includes" مراجعه کنید.

           index.recordEndOfIndexEntries
               مشخص می‌کند که آیا فایل ایندکس باید شامل بخش "End Of Index
               Entry" باشد یا خیر. این کار زمان بارگذاری ایندکس را در ماشین‌های
               چندپردازنده‌ای کاهش می‌دهد، اما هنگام خواندن ایندکس با استفاده از
               نسخه‌های Git پیش از 2.20 پیام "ignoring EOIE extension" تولید
               می‌کند. در صورتی که index.threads به طور صریح فعال شده باشد
               پیش‌فرض true است، در غیر این صورت false می‌باشد.

           index.recordOffsetTable
               مشخص می‌کند که آیا فایل ایندکس باید شامل بخش "Index Entry Offset
               Table" باشد یا خیر. این کار زمان بارگذاری ایندکس را در ماشین‌های
               چندپردازنده‌ای کاهش می‌دهد، اما هنگام خواندن ایندکس با استفاده از
               نسخه‌های Git پیش از 2.20 پیام "ignoring IEOT extension" تولید
               می‌کند. در صورتی که index.threads به طور صریح فعال شده باشد
               پیش‌فرض true است، در غیر این صورت false می‌باشد.

           index.sparse
               در صورت فعال بودن، ایندکس را با استفاده از مدخل‌های دایرکتوری
               خلوت (sparse-directory) می‌نویسد. این گزینه تاثیری ندارد مگر
               اینکه هر دو core.sparseCheckout و core.sparseCheckoutCone فعال
               باشند. پیش‌فرض false است.

           index.threads
               تعداد نخ‌هایی را مشخص می‌کند که باید هنگام بارگذاری ایندکس ایجاد
               شوند. هدف از این کار کاهش زمان بارگذاری ایندکس روی ماشین‌های
               چندپردازنده‌ای است. تعیین 0 یا true باعث می‌شود Git تعداد CPUها
               را به طور خودکار شناسایی کرده و تعداد نخ‌ها را متناسب با آن
               تنظیم کند. تعیین 1 یا false چندنخی را غیرفعال می‌کند. پیش‌فرض
               true است.

           index.version
               نسخه‌ای را مشخص می‌کند که فایل‌های ایندکس جدید باید با آن مقداردهی
               اولیه شوند. این گزینه بر مخازن موجود تاثیری ندارد. اگر
               feature.manyFiles فعال باشد، مقدار پیش‌فرض 4 است.

           index.skipHash
               در صورت فعال بودن، هش پایانی فایل ایندکس محاسبه نمی‌شود. این کار
               به اجرای سریع‌تر دستورات Git که ایندکس را دستکاری می‌کنند، مانند
               git add, git commit, یا git status کمک می‌کند. به جای ذخیره
               مجموع مقابله‌ای (checksum)، مجموعه‌ای از بایت‌های پایانی با مقدار
               صفر نوشته می‌شود که نشان می‌دهد از محاسبه صرف‌نظر شده است.

               اگر index.skipHash را فعال کنید، کلاینت‌های Git قدیمی‌تر از
               2.13.0 از تجزیه ایندکس خودداری می‌کنند و کلاینت‌های Git قدیمی‌تر
               از 2.40.0 در حین اجرای git fsck خطا گزارش می‌دهند.

           init.templateDir
               دایرکتوری را مشخص می‌کند که الگوها از آن کپی خواهند شد. (به بخش
               "TEMPLATE DIRECTORY" در git-init(1) مراجعه کنید.)

           init.defaultBranch
               امکان بازنویسی نام شاخه پیش‌فرض را مثلاً هنگام مقداردهی اولیه یک
               مخزن جدید فراهم می‌کند.

           init.defaultObjectFormat
               امکان بازنویسی قالب پیش‌فرض شیء را برای مخازن جدید فراهم می‌کند.
               ببینید --object-format= در git-init(1). هم گزینه خط فرمان و هم
               متغیر محیطی GIT_DEFAULT_HASH بر این پیکربندی اولویت دارند.

           init.defaultRefFormat
               امکان بازنویسی قالب پیش‌فرض ذخیره‌سازی مراجع را برای مخازن جدید
               فراهم می‌کند. ببینید --ref-format= در git-init(1). هم گزینه خط
               فرمان و هم متغیر محیطی GIT_DEFAULT_REF_FORMAT بر این پیکربندی
               اولویت دارند.

           init.defaultSubmodulePathConfig
               یک مقدار بولی که مشخص می‌کند آیا git init و git clone باید به
               طور خودکار extensions.submodulePathConfig را روی true تنظیم
               کنند یا خیر. این به تمام مخازن جدید اجازه می‌دهد تا به صورت
               خودکار از افزونه مسیر زیرماژول استفاده کنند. در صورت عدم تنظیم،
               پیش‌فرض false است.

           instaweb.browser
               برنامه‌ای را مشخص می‌کند که برای مرور مخزن کاری شما در gitweb
               استفاده خواهد شد. ببینید git-instaweb(1).

           instaweb.httpd
               خط فرمان دیمن HTTP برای راه‌اندازی gitweb روی مخزن کاری شما.
               ببینید git-instaweb(1).

           instaweb.local
               اگر روی true تنظیم باشد، وب‌سرور راه‌اندازی‌شده توسط git-
               instaweb(1) به IP محلی (127.0.0.1) متصل خواهد شد.

           instaweb.modulePath
               مسیر پیش‌فرض ماژول برای استفاده توسط git-instaweb(1) به جای
               /usr/lib/apache2/modules. تنها در صورتی استفاده می‌شود که httpd
               آپاچی باشد.

           instaweb.port
               شماره پورتی که httpd مربوط به gitweb باید به آن متصل شود.
               ببینید git-instaweb(1).

           interactive.singleKey
               هنگامی که روی true تنظیم شود، به کاربر اجازه می‌دهد در دستورات
               تعاملی ورودی یک‌حرفی را با فشردن یک کلید (یعنی بدون فشردن کلید
               Enter) ارائه دهد. این در حال حاضر توسط حالت --patch در دستورات
               git-add(1), git-checkout(1), git-restore(1), git-commit(1),
               git-reset(1) و git-stash(1) استفاده می‌شود.

           interactive.diffFilter
               هنگامی که یک دستور تعاملی (مانند git add --patch) یک diff رنگی
               را نشان می‌دهد، git تفاضل (diff) را از طریق دستور شل تعریف‌شده
               توسط این متغیر پیکربندی هدایت (pipe) می‌کند. این دستور می‌تواند
               diff را برای درک بهتر توسط انسان بیشتر نشانه‌گذاری کند، به شرط
               آنکه تطابق یک‌به‌یک با خطوط diff اصلی حفظ شود. پیش‌فرض غیرفعال است
               (بدون فیلتر کردن).

           log.abbrevCommit
               اگر true باشد، باعث می‌شود git-log(1), git-show(1) و git-
               whatchanged(1) گزینه --abbrev-commit را فرض بگیرند. می‌توانید
               این گزینه را با --no-abbrev-commit بازنویسی کنید.

           log.date
               حالت پیش‌فرض تاریخ-زمان را برای دستور log تنظیم می‌کند. تنظیم یک
               مقدار برای log.date مشابه استفاده از گزینه --date در git log
               است. برای جزئیات به git-log(1) مراجعه کنید.

               اگر قالب روی "auto:foo" تنظیم شده باشد و صفحه‌بند در حال استفاده
               باشد، از قالب "foo" برای تاریخ استفاده خواهد شد. در غیر این
               صورت از "default" استفاده می‌شود.

           log.decorate
               نام‌های مراجع مربوط به هر کامیت نمایش‌داده‌شده توسط دستور log را
               چاپ می‌کند. مقادیر ممکن عبارتند از:

               short
                   پیشوندهای نام مرجع refs/heads/, refs/tags/ و refs/remotes/
                   چاپ نمی‌شوند.

               full
                   نام کامل مرجع (شامل پیشوند) چاپ می‌شود.

               auto
                   اگر خروجی به یک ترمینال برود، نام‌های مراجع به گونه‌ای نمایش
                   داده می‌شوند که گویی short داده شده است، در غیر این صورت هیچ
                   نام مرجعی نمایش داده نمی‌شود.

               این معادل با گزینه --decorate در git log است.

           log.initialDecorationSet
               به‌طور پیش‌فرض، git log نشانه‌ها (decorations) را فقط برای فضاهای
               نام مرجع شناخته‌شده مشخصی نمایش می‌دهد. اگر all مشخص شود، همه
               مراجع به عنوان نشانه نمایش داده می‌شوند.

           log.excludeDecoration
               الگوهای مشخص‌شده را از نشانه‌های لاگ مستثنی می‌کند. این شبیه به
               گزینه خط فرمان --decorate-refs-exclude است، اما این گزینه
               پیکربندی می‌تواند توسط گزینه --decorate-refs لغو و بازنویسی شود.

           log.diffMerges
               قالب diff مورد استفاده را زمانی که --diff-merges=on مشخص شده
               است تنظیم می‌کند؛ برای جزئیات --diff-merges را در git-log(1)
               ببینید. پیش‌فرض روی separate است.

           log.follow
               اگر true باشد، زمانی که یک <path> واحد داده می‌شود، git log به
               گونه‌ای عمل می‌کند که گویی گزینه --follow استفاده شده است. این
               مورد همان محدودیت‌های --follow را دارد، یعنی نمی‌توان از آن برای
               دنبال کردن چندین فایل استفاده کرد و روی تاریخچه غیرخطی به خوبی
               کار نمی‌کند.

           log.graphColors
               فهرستی از رنگ‌ها، جداشده با کاما، که می‌توان از آن‌ها برای رسم
               خطوط تاریخچه در git log --graph استفاده کرد.

           log.showRoot
               اگر true باشد، کامیت اولیه به عنوان یک رویداد بزرگ ایجاد نمایش
               داده خواهد شد. این معادل یک diff در برابر یک درخت خالی است.
               ابزارهایی مانند git-log(1) یا git-whatchanged(1) که معمولاً
               کامیت ریشه را پنهان می‌کنند، اکنون آن را نمایش خواهند داد. به‌طور
               پیش‌فرض true است.

           log.showSignature
               اگر true باشد، باعث می‌شود git-log(1)، git-show(1) و git-
               whatchanged(1) فرض کنند که --show-signature مشخص شده است.

           log.mailmap
               اگر true باشد، باعث می‌شود git-log(1)، git-show(1) و git-
               whatchanged(1) فرض کنند که --use-mailmap مشخص شده است، در غیر
               این صورت --no-use-mailmap فرض می‌شود. به‌طور پیش‌فرض true است.

           lsrefs.unborn
               می‌تواند "advertise" (پیش‌فرض)، "allow" یا "ignore" باشد. اگر
               "advertise" باشد، کارساز (سرور) به کلاینتی که "unborn" ارسال
               می‌کند پاسخ خواهد داد (همان‌طور که در gitprotocol-v2(5) توصیف شده
               است) و پشتیبانی از این ویژگی را در طول اعلان قابلیت‌های پروتکل
               نسخه ۲ تبلیغ (اعلام) خواهد کرد. مقدار "allow" همانند
               "advertise" است با این تفاوت که سرور پشتیبانی از این ویژگی را
               اعلام نخواهد کرد؛ این قابلیت برای سرورهای با بار متوازن
               (load-balanced) که نمی‌توانند به‌صورت هم‌زمان و یکپارچه به‌روزرسانی
               شوند مفید است (برای مثال)، زیرا مدیر سیستم می‌تواند ابتدا
               "allow" را پیکربندی کرده و سپس پس از مدتی تأخیر، "advertise" را
               تنظیم نماید.

           mailinfo.scissors
               اگر true باشد، باعث می‌شود git-mailinfo(1) (و در نتیجه git-
               am(1)) به‌طور پیش‌فرض به گونه‌ای عمل کنند که گویی گزینه --scissors
               در خط فرمان ارائه شده است. هنگامی که فعال باشد، این ویژگی همه
               چیز را از بدنه پیام قبل از خط قیچی (scissors line، یعنی خطی
               عمدتاً شامل ">8"، "8<" و "-") حذف می‌کند.

           mailmap.file
               مکان یک فایل mailmap تکمیلی. فایل mailmap پیش‌فرض واقع در ریشه
               مخزن، ابتدا بارگذاری می‌شود و سپس فایل mailmap که توسط این متغیر
               مشخص شده است. مکان فایل mailmap می‌تواند در یک زیرپوشه از مخزن
               یا در جایی بیرون از خود مخزن باشد. ببینید: git-shortlog(1) و
               git-blame(1).

           mailmap.blob
               مشابه mailmap.file، اما مقدار را به عنوان مرجعی به یک blob در
               مخزن در نظر می‌گیرد. اگر هر دو mailmap.file و mailmap.blob مشخص
               شوند، هر دو تجزیه می‌شوند و مدخل‌های mailmap.file اولویت خواهند
               داشت. در یک مخزن bare، مقدار پیش‌فرض آن HEAD:.mailmap است. در
               مخزن غیر bare، مقدار پیش‌فرض خالی است.

           maintenance.auto
               این گزینه پیکربندی بولی کنترل می‌کند که آیا برخی دستورات پس از
               انجام کار عادی خود، git maintenance run --auto را اجرا کنند یا
               خیر. پیش‌فرض روی true است.

           maintenance.autoDetach
               بسیاری از دستورات Git پس از نوشتن داده‌ها در مخزن، نگهداری
               خودکار را راه‌اندازی می‌کنند. این گزینه پیکربندی بولی کنترل می‌کند
               که آیا این نگهداری خودکار باید در پیش‌زمینه انجام شود یا اینکه
               فرآیند نگهداری باید جدا شده (detach) و در پس‌زمینه به اجرا ادامه
               دهد.

               در صورت تنظیم نشدن، مقدار gc.autoDetach به عنوان جایگزین
               استفاده می‌شود. اگر هر دو تنظیم نشده باشند، پیش‌فرض true است، به
               این معنی که فرآیند نگهداری جدا خواهد شد.

           maintenance.strategy
               این گزینه پیکربندی رشته‌ای راهکاری برای تعیین یکی از راهبردهای
               توصیه‌شده برای نگهداری مخزن فراهم می‌کند. این تنظیم تعیین می‌کند
               که در حین اجرای git maintenance run چه وظایفی اجرا شوند، به
               شرطی که هیچ آرگومان --task=<task> ارائه نشده باشد. این تنظیم بر
               نگهداری دستی، نگهداری خودکار و همچنین نگهداری زمان‌بندی‌شده تأثیر
               می‌گذارد. وظایفی که اجرا می‌شوند ممکن است بسته به نوع نگهداری
               متفاوت باشند.

               راهبرد نگهداری را می‌توان با تنظیم maintenance.<task>.enabled و
               maintenance.<task>.schedule بیشتر سفارشی کرد. در صورت تنظیم،
               این مقادیر به جای مقادیر پیش‌فرض ارائه‌شده توسط
               maintenance.strategy استفاده می‌شوند.

               راهبردهای ممکن عبارتند از:

               •   none: این راهبرد به این معنی است که هیچ وظیفه‌ای اصلاً اجرا
                   نمی‌شود. این راهبرد پیش‌فرض برای نگهداری زمان‌بندی‌شده است.

               •   gc: این راهبرد وظیفه gc را اجرا می‌کند.

               •   geometric: این راهبرد بسته‌بندی مجدد هندسی (geometric
                   repacking) فایل‌های بسته را انجام داده و ساختارهای داده کمکی
                   را به‌روز نگه می‌دارد. این راهبرد داده‌ها را در reflog منقضی
                   می‌کند و درخت‌های کاری (worktrees) را که دیگر قابل مکان‌یابی
                   نیستند حذف می‌نماید. هنگامی که راهبرد بسته‌بندی مجدد هندسی
                   تصمیم بگیرد یک بسته‌بندی همه در یک (all-into-one) انجام دهد،
                   برای تمام اشیاء غیرقابل‌دسترس یک cruft pack ایجاد می‌کند.
                   اشیایی که از قبل بخشی از یک cruft pack هستند منقضی خواهند
                   شد.

                   این راهبرد بسته‌بندی مجدد، جایگزینی کامل برای راهبرد gc بوده
                   و برای مخازن بزرگ توصیه می‌شود. این راهبرد پیش‌فرض برای
                   نگهداری دستی است. * incremental: این تنظیم برای انجام
                   فعالیت‌های نگهداری کوچک که هیچ داده‌ای را حذف نمی‌کنند
                   بهینه‌سازی شده است. این گزینه وظیفه gc را زمان‌بندی نمی‌کند،
                   بلکه وظایف prefetch و commit-graph را به‌صورت ساعتی، وظایف
                   loose-objects و incremental-repack را به‌صورت روزانه، و
                   وظیفه pack-refs را به‌صورت هفتگی اجرا می‌کند. نگهداری دستی
                   مخزن از وظیفه gc استفاده می‌کند.

           maintenance.<task>.enabled
               این گزینه پیکربندی بولی کنترل می‌کند که آیا وظیفه نگهداری با نام
               <task> زمانی که هیچ گزینه --task به git maintenance run مشخص
               نشده باشد اجرا شود یا خیر. در صورت وجود گزینه --task، این
               مقادیر پیکربندی نادیده گرفته می‌شوند. به‌طور پیش‌فرض، فقط
               maintenance.gc.enabled برابر با true است.

           maintenance.<task>.schedule
               این گزینه پیکربندی کنترل می‌کند که آیا <task> داده‌شده در طول یک
               دستور git maintenance run --schedule=<frequency> اجرا شود یا
               خیر. مقدار باید یکی از "hourly"، "daily" یا "weekly" باشد.

           maintenance.commit-graph.auto
               این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه commit-graph
               هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run
               --auto اجرا شود. اگر صفر باشد، وظیفه commit-graph با گزینه
               --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر
               بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که
               دستور باید زمانی اجرا شود که تعداد کامیت‌های قابل‌دسترس که در
               فایل commit-graph نیستند حداقل به اندازه مقدار
               maintenance.commit-graph.auto باشد. مقدار پیش‌فرض ۱۰۰ است.

           maintenance.loose-objects.auto
               این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه loose-objects
               هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run
               --auto اجرا شود. اگر صفر باشد، وظیفه loose-objects با گزینه
               --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر
               بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که
               دستور باید زمانی اجرا شود که تعداد اشیاء مستقل (loose objects)
               حداقل به اندازه مقدار maintenance.loose-objects.auto باشد.
               مقدار پیش‌فرض ۱۰۰ است.

           maintenance.loose-objects.batchSize
               این گزینه پیکربندی عدد صحیح حداکثر تعداد اشیاء مستقل نوشته‌شده
               در یک فایل بسته در طول وظیفه loose-objects را کنترل می‌کند.
               پیش‌فرض پنجاه هزار است. از مقدار 0 برای نشان دادن عدم وجود
               محدودیت استفاده کنید.

           maintenance.incremental-repack.auto
               این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه
               incremental-repack هر چند وقت یک‌بار باید به عنوان بخشی از git
               maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه
               incremental-repack با گزینه --auto اجرا نخواهد شد. یک مقدار
               منفی وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت،
               یک مقدار مثبت به این معنی است که دستور باید زمانی اجرا شود که
               تعداد فایل‌های بسته خارج از multi-pack-index حداقل به اندازه
               مقدار maintenance.incremental-repack.auto باشد. مقدار پیش‌فرض ۱۰
               است.

           maintenance.geometric-repack.auto
               این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه
               geometric-repack هر چند وقت یک‌بار باید به عنوان بخشی از git
               maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه
               geometric-repack با گزینه --auto اجرا نخواهد شد. یک مقدار منفی
               وظیفه را مجبور می‌کند که هر بار اجرا شود. در غیر این صورت، یک
               مقدار مثبت به این معنی است که دستور باید یا زمانی اجرا شود که
               فایل‌های بسته‌ای وجود داشته باشند که برای حفظ تصاعد هندسی نیاز به
               ادغام با یکدیگر دارند، یا زمانی که حداقل این تعداد شیء مستقل
               وجود داشته باشد که در یک فایل بسته جدید نوشته شوند. مقدار
               پیش‌فرض ۱۰۰ است.

           maintenance.geometric-repack.splitFactor
               این گزینه پیکربندی عدد صحیح ضریب مورد استفاده برای دنباله هندسی
               را کنترل می‌کند. برای جزئیات بیشتر گزینه --geometric= را در git-
               repack(1) ببینید. پیش‌فرض 2 است.

           maintenance.reflog-expire.auto
               این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه reflog-expire
               هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run
               --auto اجرا شود. اگر صفر باشد، وظیفه reflog-expire با گزینه
               --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر
               بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که
               دستور باید زمانی اجرا شود که تعداد مدخل‌های منقضی‌شده reflog در
               وقایع‌نگار مرجع "HEAD" حداقل به اندازه مقدار
               maintenance.loose-objects.auto باشد. مقدار پیش‌فرض ۱۰۰ است.

           maintenance.rerere-gc.auto
               این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه rerere-gc هر
               چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto
               اجرا شود. اگر صفر باشد، وظیفه rerere-gc با گزینه --auto اجرا
               نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر بار اجرا
               شود. در غیر این صورت، هر مقدار مثبت به این معنی است که دستور
               زمانی اجرا خواهد شد که پوشه "rr-cache" وجود داشته باشد و حداقل
               یک مدخل داشته باشد، صرف‌نظر از اینکه بیات (stale) است یا خیر.
               این روش تجربی (heuristic) ممکن است در آینده بهبود یابد. مقدار
               پیش‌فرض ۱ است.

           maintenance.worktree-prune.auto
               این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه worktree-prune
               هر چند وقت یک‌بار باید به عنوان بخشی از git maintenance run
               --auto اجرا شود. اگر صفر باشد، وظیفه worktree-prune با گزینه
               --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند که هر
               بار اجرا شود. در غیر این صورت، یک مقدار مثبت به این معنی است که
               دستور باید زمانی اجرا شود که تعداد درخت‌های کاری قابل هرس از این
               مقدار بیشتر شود. مقدار پیش‌فرض ۱ است.

           man.viewer
               برنامه‌هایی را که می‌توان برای نمایش راهنما در قالب man استفاده
               کرد مشخص می‌کند. ببینید: git-help(1).

           man.<tool>.cmd
               دستور فراخوانی نمایش‌دهنده man مشخص‌شده را تعیین می‌کند. دستور
               مشخص‌شده در پوسته با صفحه man که به عنوان یک آرگومان ارسال شده
               است، ارزیابی می‌گردد. (ببینید: git-help(1).)

           man.<tool>.path
               مسیر ابزار داده‌شده را که ممکن است برای نمایش راهنما در قالب man
               استفاده شود لغو و جایگزین می‌کند. ببینید: git-help(1).

           merge.conflictStyle
               سبکی را که در آن قطعه‌های دچار تعارض هنگام ادغام در فایل‌های درخت
               کاری نوشته می‌شوند مشخص می‌کند. حالت پیش‌فرض "merge" است که یک
               نشانگر تعارض <<<<<<<، تغییرات ایجاد شده توسط یک طرف، یک نشانگر
               =======، تغییرات ایجاد شده توسط طرف دیگر، و سپس یک نشانگر
               >>>>>>> را نشان می‌دهد. یک سبک جایگزین، "diff3"، یک نشانگر
               ||||||| و متن اصلی را قبل از نشانگر ======= اضافه می‌کند. سبک
               "merge" معمولاً نواحی تعارض کوچک‌تری نسبت به diff3 ایجاد می‌کند،
               هم به دلیل حذف متن اصلی و هم به این دلیل که وقتی زیرمجموعه‌ای از
               خطوط در هر دو طرف مطابقت دارند، آن‌ها به سادگی از ناحیه تعارض
               خارج می‌شوند. سبک جایگزین دیگر، "zdiff3"، شبیه به diff3 است اما
               خطوط منطبق در هر دو طرف را از ناحیه تعارض حذف می‌کند، در صورتی
               که آن خطوط منطبق در نزدیکی ابتدا یا انتهای یک ناحیه تعارض ظاهر
               شوند.

           merge.defaultToUpstream
               اگر merge بدون هیچ آرگومان کامیتی فراخوانی شود، شاخه‌های بالادست
               (upstream) پیکربندی‌شده برای شاخه فعلی را با استفاده از آخرین
               مقادیر مشاهده‌شده ذخیره‌شده در شاخه‌های ردیابی ریموت آن‌ها ادغام
               می‌کند. مقادیر branch.<current branch>.merge که شاخه‌های موجود در
               ریموت مشخص‌شده توسط branch.<current-branch>.remote را نام می‌برند
               بررسی شده، و سپس از طریق remote.<remote>.fetch به شاخه‌های
               ردیابی ریموت متناظرشان نگاشت می‌شوند و نوک (tip) این شاخه‌های
               ردیابی ادغام می‌گردند. پیش‌فرض روی true است.

           merge.ff
               به‌طور پیش‌فرض، Git هنگام ادغام کامیتی که از نوادگان کامیت فعلی
               است، یک کامیت ادغام اضافی ایجاد نمی‌کند. در عوض، نوک شاخه فعلی
               به‌صورت فوروارد سریع (fast-forward) پیش می‌رود. هنگامی که روی
               false تنظیم شود، این متغیر به Git می‌گوید در چنین حالتی یک کامیت
               ادغام اضافی ایجاد کند (معادل ارسال گزینه --no-ff از خط فرمان).
               هنگامی که روی only تنظیم شود، تنها این‌گونه ادغام‌های فوروارد
               سریع مجاز هستند (معادل ارسال گزینه --ff-only از خط فرمان).

           merge.verifySignatures
               اگر true باشد، این معادل گزینه خط فرمان --verify-signatures
               است. برای جزئیات git-merge(1) را ببینید.

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

           merge.log
               علاوه بر نام شاخه‌ها، پیام لاگ را حداکثر با تعداد مشخص‌شده‌ای از
               توضیحات تک‌خطی از کامیت‌های واقعی که در حال ادغام هستند پر می‌کند.
               پیش‌فرض false است و true مترادف با ۲۰ می‌باشد.

           merge.suppressDest
               با افزودن یک الگوی عمومی (glob) که با نام‌های شاخه‌های
               یکپارچه‌سازی تطابق دارد به این متغیر پیکربندی چندمقداری، پیام
               پیش‌فرض ادغام محاسبه‌شده برای ادغام در این شاخه‌های یکپارچه‌سازی،
               عبارت "into <branch-name>" را از عنوان خود حذف خواهد کرد.

               یک عنصر با مقدار خالی می‌تواند برای پاک کردن فهرست الگوهای عمومی
               انباشته‌شده از مدخل‌های پیکربندی قبلی استفاده شود. هنگامی که هیچ
               متغیر merge.suppressDest تعریف نشده باشد، مقدار پیش‌فرض master
               برای سازگاری با گذشته استفاده می‌شود.

           merge.renameLimit
               تعداد فایل‌هایی که در بخش جامع تشخیص تغییر نام در حین ادغام باید
               در نظر گرفته شوند. در صورت عدم تعیین، مقدار پیش‌فرض آن برابر با
               مقدار diff.renameLimit خواهد بود. اگر نه merge.renameLimit و نه
               diff.renameLimit مشخص نشده باشند، در حال حاضر مقدار پیش‌فرض ۷۰۰۰
               است. این تنظیم در صورت غیرفعال بودن تشخیص تغییر نام هیچ اثری
               ندارد.

           merge.renames
               آیا Git تغییر نام‌ها را تشخیص دهد یا خیر. اگر روی false تنظیم
               شود، تشخیص تغییر نام غیرفعال می‌گردد. اگر روی true تنظیم شود،
               تشخیص پایه تغییر نام فعال می‌شود. به‌طور پیش‌فرض برابر با مقدار
               diff.renames است.

           merge.directoryRenames
               آیا Git تغییر نام پوشه‌ها را تشخیص دهد یا خیر، که بر سرنوشت
               فایل‌های جدید اضافه‌شده به یک پوشه در یک طرف تاریخچه در زمان
               ادغام، هنگامی که آن پوشه در طرف دیگر تاریخچه تغییر نام یافته
               است، تأثیر می‌گذارد. مقادیر ممکن عبارتند از:

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

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

               conflict
                   برای چنین مسیرهایی یک تعارض گزارش خواهد شد.

               اگر merge.renames برابر با false باشد، merge.directoryRenames
               نادیده گرفته شده و مانند false با آن رفتار می‌شود. پیش‌فرض
               conflict است.

           merge.renormalize
               به Git اعلام می‌کند که نمایش متعارف فایل‌ها در مخزن در طول زمان
               تغییر کرده است (به عنوان مثال کامیت‌های قبلی فایل‌های متنی را با
               پایان خط CRLF ثبت کرده‌اند، اما کامیت‌های اخیر از پایان خط LF
               استفاده می‌کنند). در چنین مخزنی، برای هر فایلی که در آن به یک
               ادغام محتوایی سه‌طرفه نیاز است، Git می‌تواند داده‌های ثبت‌شده در
               کامیت‌ها را قبل از انجام ادغام به یک شکل متعارف تبدیل کند تا
               تعارض‌های غیرضروری کاهش یابند. برای اطلاعات بیشتر، بخش "Merging
               branches with differing checkin/checkout attributes" را در
               gitattributes(5) ببینید.

           merge.stat
               چه چیزی (در صورت وجود) بین ORIG_HEAD و نتیجه ادغام در پایان
               ادغام چاپ شود. مقادیر ممکن عبارتند از:

               false
                   چیزی نشان داده نشود.

               true
                   نمایش git diff --diffstat --summary ORIG_HEAD.

               compact
                   نمایش git diff --compact-summary ORIG_HEAD.

               اما هر مقدار ناشناخته (مثلاً مقداری که توسط نسخه آینده Git اضافه
               شده باشد) به جای ایجاد خطا به عنوان true در نظر گرفته می‌شود.
               پیش‌فرض true است.

           merge.autoStash
               هنگامی که روی true تنظیم شود، پیش از شروع عملیات به‌طور خودکار
               یک مدخل موقت استش (stash) ایجاد کرده و پس از پایان عملیات آن را
               اعمال می‌کند. این بدان معناست که می‌توانید ادغام را روی یک درخت
               کاری کثیف (دارای تغییرات ثبت‌نشده) اجرا کنید. با این حال، با
               احتیاط استفاده کنید: اعمال نهایی استش پس از یک ادغام موفقیت‌آمیز
               ممکن است به تعارض‌های غیرپیش‌پاافتاده منجر شود. این گزینه می‌تواند
               توسط گزینه‌های --no-autostash و --autostash در git-merge(1) لغو
               و بازنویسی شود. پیش‌فرض روی false است.

           merge.tool
               کنترل می‌کند که کدام ابزار ادغام توسط git-mergetool(1) استفاده
               شود. فهرست زیر مقادیر معتبر توکار را نشان می‌دهد. هر مقدار دیگری
               به عنوان یک ابزار ادغام سفارشی در نظر گرفته می‌شود و مستلزم آن
               است که متغیر متناظر mergetool.<tool>.cmd تعریف شده باشد.

           merge.guitool
               کنترل می‌کند که در زمان مشخص شدن فلگ -g/--gui، کدام ابزار ادغام
               توسط git-mergetool(1) استفاده شود. فهرست زیر مقادیر معتبر توکار
               را نشان می‌دهد. هر مقدار دیگری به عنوان یک ابزار ادغام سفارشی در
               نظر گرفته می‌شود و مستلزم آن است که متغیر متناظر
               mergetool.<guitool>.cmd تعریف شده باشد.

               araxis
                   استفاده از Araxis Merge (نیازمند نشست گرافیکی)

               bc
                   استفاده از Beyond Compare (نیازمند نشست گرافیکی)

               bc3
                   استفاده از Beyond Compare (نیازمند نشست گرافیکی)

               bc4
                   استفاده از Beyond Compare (نیازمند نشست گرافیکی)

               codecompare
                   استفاده از Code Compare (نیازمند نشست گرافیکی)

               deltawalker
                   استفاده از DeltaWalker (نیازمند نشست گرافیکی)

               diffmerge
                   استفاده از DiffMerge (نیازمند نشست گرافیکی)

               diffuse
                   استفاده از Diffuse (نیازمند نشست گرافیکی)

               ecmerge
                   استفاده از ECMerge (نیازمند نشست گرافیکی)

               emerge
                   استفاده از Emerge در Emacs

               examdiff
                   استفاده از ExamDiff Pro (نیازمند نشست گرافیکی)

               guiffy
                   استفاده از ابزار Diff گویفی (Guiffy) (نیازمند نشست گرافیکی)

               gvimdiff
                   استفاده از gVim (نیازمند نشست گرافیکی) با یک چیدمان سفارشی
                   (بخش BACKEND SPECIFIC HINTS در git help mergetool را
                   ببینید)

               gvimdiff1
                   استفاده از gVim (نیازمند نشست گرافیکی) با چیدمان ۲ پانلی
                   (LOCAL و REMOTE)

               gvimdiff2
                   استفاده از gVim (نیازمند نشست گرافیکی) با چیدمان ۳ پانلی
                   (LOCAL، MERGED و REMOTE)

               gvimdiff3
                   استفاده از gVim (نیازمند نشست گرافیکی) که در آن فقط فایل
                   MERGED نمایش داده می‌شود

               kdiff3
                   استفاده از KDiff3 (نیازمند نشست گرافیکی)

               meld
                   استفاده از Meld (نیازمند نشست گرافیکی) با ادغام خودکار
                   اختیاری (بخش CONFIGURATION در git help mergetool را ببینید)

               nvimdiff
                   استفاده از Neovim با یک چیدمان سفارشی (بخش BACKEND SPECIFIC
                   HINTS در git help mergetool را ببینید)

               nvimdiff1
                   استفاده از Neovim با چیدمان ۲ پانلی (LOCAL و REMOTE)

               nvimdiff2
                   استفاده از Neovim با چیدمان ۳ پانلی (LOCAL، MERGED و
                   REMOTE)

               nvimdiff3
                   استفاده از Neovim که در آن فقط فایل MERGED نمایش داده می‌شود

               opendiff
                   استفاده از FileMerge (نیازمند نشست گرافیکی)

               p4merge
                   استفاده از HelixCore P4Merge (نیازمند نشست گرافیکی)

               smerge
                   استفاده از Sublime Merge (نیازمند نشست گرافیکی)

               tkdiff
                   استفاده از TkDiff (نیازمند نشست گرافیکی)

               tortoisemerge
                   استفاده از TortoiseMerge (نیازمند نشست گرافیکی)

               vimdiff
                   استفاده از Vim با یک چیدمان سفارشی (بخش BACKEND SPECIFIC
                   HINTS در git help mergetool را ببینید)

               vimdiff1
                   استفاده از Vim با چیدمان ۲ پانلی (LOCAL و REMOTE)

               vimdiff2
                   استفاده از Vim با چیدمان ۳ پانلی (LOCAL، MERGED و REMOTE)

               vimdiff3
                   استفاده از Vim که در آن فقط فایل MERGED نمایش داده می‌شود

               vscode
                   استفاده از Visual Studio Code (نیازمند نشست گرافیکی)

               winmerge
                   استفاده از WinMerge (نیازمند نشست گرافیکی)

               xxdiff
                   استفاده از xxdiff (نیازمند نشست گرافیکی)

           merge.verbosity
               میزان خروجی نمایش‌داده‌شده توسط راهبرد ادغام بازگشتی را کنترل
               می‌کند. سطح ۰ هیچ چیزی به جز پیام خطای نهایی در صورت تشخیص تعارض
               خروجی نمی‌دهد. سطح ۱ فقط تعارض‌ها را خروجی می‌دهد، سطح ۲ تعارض‌ها و
               تغییرات فایل را خروجی می‌دهد. سطح ۵ و بالاتر اطلاعات اشکال‌زدایی
               را خروجی می‌دهد. پیش‌فرض سطح ۲ است. می‌تواند توسط متغیر محیطی
               GIT_MERGE_VERBOSITY لغو و بازنویسی شود.

           merge.<driver>.name
               یک نام خوانا برای انسان برای یک راه‌انداز ادغام سطح‌پایین سفارشی
               تعریف می‌کند. برای جزئیات gitattributes(5) را ببینید.

           merge.<driver>.driver
               دستوری را که یک راه‌انداز ادغام سطح‌پایین سفارشی را پیاده‌سازی
               می‌کند تعریف می‌نماید. برای جزئیات gitattributes(5) را ببینید.

           merge.<driver>.recursive
               نام یک راه‌انداز ادغام سطح‌پایین را تعیین می‌کند که هنگام انجام
               ادغام داخلی میان نیاکان مشترک استفاده شود. برای جزئیات
               gitattributes(5) را ببینید.

           mergetool.<tool>.path
               مسیر ابزار داده‌شده را لغو و بازنویسی می‌کند. این در صورتی مفید
               است که ابزار شما در $PATH نباشد.

           mergetool.<tool>.cmd
               دستور فراخوانی ابزار ادغام مشخص‌شده را تعیین می‌کند. دستور
               مشخص‌شده در پوسته با متغیرهای زیر در دسترس ارزیابی می‌شود: BASE
               نام یک فایل موقت حاوی پایه مشترک فایل‌های در حال ادغام است (در
               صورت موجود بودن)؛ LOCAL نام یک فایل موقت حاوی محتویات فایل در
               شاخه فعلی است؛ REMOTE نام یک فایل موقت حاوی محتویات فایل از
               شاخه‌ای است که در حال ادغام است؛ MERGED شامل نام فایلی است که
               ابزار ادغام باید نتایج یک ادغام موفقیت‌آمیز را در آن بنویسد.

           mergetool.<tool>.hideResolved
               به کاربر اجازه می‌دهد مقدار سراسری mergetool.hideResolved را
               برای یک ابزار خاص لغو و بازنویسی کند. برای شرح کامل
               mergetool.hideResolved را ببینید.

           mergetool.<tool>.trustExitCode
               برای یک دستور ادغام سفارشی، مشخص می‌کند که آیا می‌توان از کد خروج
               دستور ادغام برای تعیین موفقیت‌آمیز بودن ادغام استفاده کرد یا
               خیر. اگر این روی true تنظیم نشده باشد، برچسب زمانی فایل مقصد
               ادغام بررسی می‌شود و در صورتی که فایل به‌روزرسانی شده باشد فرض
               می‌شود ادغام موفقیت‌آمیز بوده است؛ در غیر این صورت، از کاربر
               خواسته می‌شود موفقیت ادغام را مشخص کند.

           mergetool.meld.hasOutput
               نسخه‌های قدیمی‌تر meld از گزینه --output پشتیبانی نمی‌کنند. Git با
               بررسی خروجی meld --help تلاش خواهد کرد تشخیص دهد که آیا meld از
               --output پشتیبانی می‌کند یا خیر. پیکربندی
               mergetool.meld.hasOutput باعث می‌شود Git از این بررسی‌ها صرف‌نظر
               کرده و در عوض از مقدار پیکربندی‌شده استفاده کند. تنظیم
               mergetool.meld.hasOutput روی true به Git می‌گوید بدون قیدوشرط از
               گزینه --output استفاده کند، و false از استفاده از --output
               خودداری می‌کند.

           mergetool.meld.useAutoMerge
               هنگامی که گزینه --auto-merge داده می‌شود، meld تمام بخش‌های بدون
               تعارض را به‌طور خودکار ادغام می‌کند، بخش‌های دارای تعارض را برجسته
               می‌سازد و منتظر تصمیم کاربر می‌ماند. تنظیم
               mergetool.meld.useAutoMerge روی true به Git می‌گوید بدون قیدوشرط
               از گزینه --auto-merge همراه با meld استفاده کند. تنظیم این
               مقدار روی auto باعث می‌شود git تشخیص دهد که آیا --auto-merge
               پشتیبانی می‌شود یا خیر و تنها زمانی که در دسترس باشد از
               --auto-merge استفاده کند. مقدار false به‌طور کلی از استفاده از
               --auto-merge خودداری می‌کند و مقدار پیش‌فرض است.

           mergetool.<variant>.layout
               چیدمان پنجره تقسیم‌شده (split window) را برای <variant> مربوط به
               vimdiff پیکربندی می‌کند، که می‌تواند هر یک از vimdiff، nvimdiff
               یا gvimdiff باشد. هنگام راه‌اندازی git mergetool با
               --tool=<variant> (یا بدون --tool اگر merge.tool به عنوان
               <variant> پیکربندی شده باشد)، Git به mergetool.<variant>.layout
               مراجعه می‌کند تا چیدمان ابزار را تعیین کند. اگر پیکربندی مخصوص
               نسخه موجود نباشد، چیدمان vimdiff به عنوان جایگزین استفاده
               می‌شود. اگر آن هم موجود نباشد، یک چیدمان پیش‌فرض با ۴ پنجره
               استفاده خواهد شد. برای پیکربندی چیدمان، بخش BACKEND SPECIFIC
               HINTS را در git-mergetool(1) ببینید.

           mergetool.hideResolved
               در حین یک ادغام، Git به‌طور خودکار تا حد امکان تعارض‌ها را برطرف
               کرده و فایل $MERGED را می‌نویسد که حاوی نشانگرهای تعارض در اطراف
               هر تعارضی است که نتوانسته آن را برطرف کند؛ $LOCAL و $REMOTE
               به‌طور معمول نسخه‌های فایل از قبل از حل تعارض توسط Git هستند. این
               فلگ باعث می‌شود $LOCAL و $REMOTE رونویسی شوند تا فقط تعارض‌های
               حل‌نشده به ابزار ادغام ارائه گردند. می‌تواند برای هر ابزار از
               طریق متغیر پیکربندی mergetool.<tool>.hideResolved پیکربندی شود.
               پیش‌فرض روی false است.

           mergetool.keepBackup
               پس از انجام ادغام، فایل اصلی همراه با نشانگرهای تعارض می‌تواند
               به عنوان فایلی با پسوند .orig ذخیره شود. اگر این متغیر روی
               false تنظیم شود، این فایل حفظ نمی‌گردد. پیش‌فرض true است (یعنی
               فایل‌های پشتیبان نگه‌داری شوند).

           mergetool.keepTemporaries
               هنگام فراخوانی یک ابزار ادغام سفارشی، Git از مجموعه‌ای از
               فایل‌های موقت برای ارسال به ابزار استفاده می‌کند. اگر ابزار خطایی
               بازگرداند و این متغیر روی true تنظیم شده باشد، این فایل‌های موقت
               حفظ خواهند شد؛ در غیر این صورت، پس از خروج ابزار حذف می‌شوند.
               پیش‌فرض false است.

           mergetool.writeToTemp
               به‌طور پیش‌فرض Git نسخه‌های موقت BASE، LOCAL و REMOTE از فایل‌های
               دارای تعارض را در درخت کاری می‌نویسد. هنگامی که روی true تنظیم
               شود، Git تلاش خواهد کرد از یک دایرکتوری موقت برای این فایل‌ها
               استفاده کند. پیش‌فرض false است.

           mergetool.prompt
               پیش از هر بار فراخوانی برنامه حل تعارض ادغام، اعلان نمایش می‌دهد
               (تایید می‌گیرد).

           mergetool.guiDefault
               روی true تنظیم کنید تا به‌طور پیش‌فرض از merge.guitool استفاده
               شود (معادل مشخص کردن آرگومان --gui)، یا auto تا بسته به وجود
               مقدار متغیر محیطی DISPLAY، بین merge.guitool یا merge.tool
               انتخاب شود. مقدار پیش‌فرض false است که در آن آرگومان --gui باید
               صریحاً ارائه شود تا merge.guitool استفاده گردد.

           notes.mergeStrategy
               کدام راهبرد ادغام به‌طور پیش‌فرض هنگام حل تعارض‌های یادداشت‌ها
               انتخاب شود. باید یکی از manual، ours، theirs، union یا
               cat_sort_uniq باشد. پیش‌فرض روی manual است. برای اطلاعات بیشتر
               درباره هر راهبرد، بخش "NOTES MERGE STRATEGIES" را در git-
               notes(1) ببینید.

               این تنظیم را می‌توان با ارسال گزینه --strategy به git-notes(1)
               لغو و بازنویسی کرد.

           notes.<name>.mergeStrategy
               کدام راهبرد ادغام هنگام انجام ادغام یادداشت‌ها در
               refs/notes/<name> انتخاب شود. این گزینه راهبرد عمومی‌تر
               notes.mergeStrategy را لغو و بازنویسی می‌کند. برای اطلاعات بیشتر
               در مورد راهبردهای موجود، بخش "NOTES MERGE STRATEGIES" را در
               git-notes(1) ببینید.

           notes.displayRef
               علاوه بر مقدار پیش‌فرض تعیین‌شده توسط core.notesRef یا
               GIT_NOTES_REF، هنگام نمایش پیام‌های کامیت با خانواده دستورات git
               log، یادداشت‌ها از کدام مرجع (یا مراجع، در صورت استفاده از الگو
               یا تعیین چندباره) خوانده شوند.

               این تنظیم را می‌توان با متغیر محیطی GIT_NOTES_DISPLAY_REF که
               باید فهرستی از مراجع یا الگوهای عمومی جداشده با دو نقطه (:)
               باشد، لغو و بازنویسی کرد.

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

               این تنظیم را می‌توان با گزینه --no-notes در خانواده دستورات git-
               log(1) یا با گزینه --notes=<ref> که توسط آن دستورات پذیرفته
               می‌شود، غیرفعال کرد.

               مقدار مؤثر core.notesRef (که احتمالاً توسط GIT_NOTES_REF
               بازنویسی شده است) نیز به‌طور ضمنی به فهرست مراجع قابل نمایش
               اضافه می‌شود.

           notes.rewrite.<command>
               هنگام بازنویسی کامیت‌ها با <command> (در حال حاضر amend یا
               rebase)، اگر این متغیر false باشد، git یادداشت‌ها را از کامیت
               اصلی به کامیت بازنویسی‌شده کپی نخواهد کرد. پیش‌فرض true است.
               همچنین notes.rewriteRef را در زیر ببینید.

               این تنظیم را می‌توان با متغیر محیطی GIT_NOTES_REWRITE_REF که
               باید فهرستی از مراجع یا الگوهای عمومی جداشده با دو نقطه (:)
               باشد، لغو و بازنویسی کرد.

           notes.rewriteMode
               هنگام کپی کردن یادداشت‌ها در طول بازنویسی (گزینه
               notes.rewrite.<command> را ببینید)، تعیین می‌کند که در صورت
               داشتن یادداشت در کامیت مقصد چه اقدامی انجام شود. باید یکی از
               overwrite، concatenate، cat_sort_uniq یا ignore باشد. پیش‌فرض
               concatenate است.

               این تنظیم را می‌توان با متغیر محیطی GIT_NOTES_REWRITE_MODE لغو و
               بازنویسی کرد.

           notes.rewriteRef
               هنگام کپی کردن یادداشت‌ها در حین بازنویسی، مرجع (کاملاً واجد
               شرایط) را مشخص می‌کند که یادداشت‌های آن باید کپی شوند. می‌تواند یک
               الگوی عمومی (glob) باشد که در این صورت یادداشت‌ها در تمام مراجع
               منطبق کپی خواهند شد. همچنین می‌توانید این پیکربندی را چندین بار
               مشخص کنید.

               مقدار پیش‌فرض ندارد؛ برای فعال کردن بازنویسی یادداشت باید این
               متغیر را پیکربندی کنید. برای فعال‌سازی بازنویسی برای یادداشت‌های
               پیش‌فرض کامیت، آن را روی refs/notes/commits تنظیم کنید.

               می‌تواند با متغیر محیطی GIT_NOTES_REWRITE_REF لغو و بازنویسی
               شود. برای توضیح بیشتر در مورد قالب آن، notes.rewrite.<command>
               را در بالا ببینید.

           pack.window
               اندازه پنجره مورد استفاده توسط git-pack-objects(1) هنگامی که
               اندازه پنجره‌ای در خط فرمان داده نشده باشد. پیش‌فرض ۱۰ است.

           pack.depth
               حداکثر عمق دلتا مورد استفاده توسط git-pack-objects(1) هنگامی که
               حداکثر عمقی در خط فرمان داده نشده باشد. پیش‌فرض ۵۰ است. حداکثر
               مقدار ۴۰۹۵ می‌باشد.

           pack.windowMemory
               حداکثر مقدار حافظه‌ای که توسط هر ریسه (thread) در git-pack-
               objects(1) برای حافظه پنجره بسته مصرف می‌شود، در صورتی که هیچ
               محدودیتی در خط فرمان داده نشده باشد. مقدار می‌تواند با پسوندهای
               "k"، "m" یا "g" همراه باشد. هنگامی که پیکربندی نشود (یا صریحاً
               روی 0 تنظیم شود)، هیچ محدودیتی وجود نخواهد داشت.

           pack.compression
               یک عدد صحیح بین -1..9، که سطح فشرده‌سازی اشیاء را در یک فایل
               بسته (pack file) مشخص می‌کند. -1 پیش‌فرض zlib است. مقدار 0 به
               معنای عدم فشرده‌سازی است، و 1..9 موازنه‌های مختلف میان سرعت و
               اندازه هستند که 9 کندترین آن‌هاست. اگر تنظیم نشود، به صورت
               پیش‌فرض core.compression در نظر گرفته می‌شود. اگر آن هم تنظیم
               نشده باشد، مقدار پیش‌فرض -1 (پیش‌فرض zlib) خواهد بود، که «یک سازش
               پیش‌فرض میان سرعت و فشرده‌سازی است (در حال حاضر معادل سطح 6)».

               توجه داشته باشید که تغییر سطح فشرده‌سازی به‌طور خودکار تمام اشیاء
               موجود را مجدداً فشرده نمی‌کند. می‌توانید با دادن گزینه -F به git-
               repack(1) فشرده‌سازی مجدد را اجبار کنید.

           pack.allowPackReuse
               هنگامی که روی true یا "single" تنظیم شده باشد، و بیت‌مپ‌های
               دسترسی‌پذیری فعال باشند، pack-objects تلاش خواهد کرد بخش‌هایی از
               فایل بسته دارای بیت‌مپ را عیناً ارسال کند. هنگامی که روی "multi"
               تنظیم شده باشد، و یک بیت‌مپ دسترسی‌پذیری چندبسته‌ای در دسترس باشد،
               pack-objects تلاش خواهد کرد بخش‌هایی از تمام بسته‌ها را در MIDX
               ارسال کند.

               اگر فقط یک بیت‌مپ بسته تکی در دسترس باشد، و pack.allowPackReuse
               روی "multi" تنظیم شده باشد، تنها بخش‌هایی از همان فایل بسته
               دارای بیت‌مپ مجدداً استفاده می‌شود. این کار می‌تواند مصرف حافظه و
               پردازنده را برای پاسخ به واکشی‌ها کاهش دهد، اما ممکن است منجر به
               ارسال بسته‌ای کمی بزرگ‌تر شود. مقدار پیش‌فرض true است.

           pack.island
               یک عبارت باقاعده گسترش‌یافته (extended regular expression) برای
               پیکربندی مجموعه‌ای از جزیره‌های دلتا (delta islands). برای جزئیات
               به بخش "DELTA ISLANDS" در git-pack-objects(1) مراجعه کنید.

           pack.islandCore
               نام جزیره‌ای را مشخص می‌کند که اشیاء آن باید در ابتدا بسته‌بندی
               شوند. این کار نوعی شبه‌بسته (pseudo-pack) در ابتدای یک بسته
               ایجاد می‌کند، به‌طوری‌که اشیاء متعلق به جزیره مشخص‌شده با سرعت
               بیشتری در هر بسته‌ای که قرار است برای کاربری که آن اشیاء را
               درخواست کرده ارسال شود، کپی شوند. در عمل این بدان معناست که
               جزیره مشخص‌شده احتمالاً باید با آنچه معمولاً در مخزن کلون می‌شود
               مطابقت داشته باشد. همچنین به "DELTA ISLANDS" در git-pack-
               objects(1).  مراجعه کنید.

           pack.deltaCacheSize
               حداکثر حافظه بر حسب بایت که برای کش کردن دلتاها در git-pack-
               objects(1) قبل از نوشتن آن‌ها در یک بسته استفاده می‌شود. این کش
               برای افزایش سرعت مرحله نوشتن اشیاء استفاده می‌شود تا پس از یافتن
               بهترین تطابق برای تمام اشیاء، نیازی به محاسبه مجدد نتیجه نهایی
               دلتا نباشد. البته بسته‌بندی مجدد مخازن بزرگ در دستگاه‌هایی با
               حافظه محدود ممکن است از این امر به شدت متأثر شود، به‌ویژه اگر
               این کش سیستم را به فضای مبادله (swapping) بکشاند. مقدار 0 به
               معنای عدم وجود محدودیت است. کوچک‌ترین اندازه یعنی 1 بایت می‌تواند
               برای غیرفعال کردن مجازی این کش استفاده شود. مقدار پیش‌فرض 256
               MiB است.

           pack.deltaCacheLimit
               حداکثر اندازه یک دلتا که در git-pack-objects(1).  کش می‌شود. این
               کش برای افزایش سرعت مرحله نوشتن شیء استفاده می‌شود تا پس از
               یافتن بهترین تطابق برای همه اشیاء، نیازی به محاسبه مجدد نتیجه
               دلتای نهایی نباشد. مقدار پیش‌فرض 1000 است. حداکثر مقدار 65535
               می‌باشد.

           pack.threads
               تعداد ریسمان‌هایی (threads) را مشخص می‌کند که هنگام جستجو برای
               بهترین تطابق‌های دلتا ایجاد می‌شوند. این نیازمند آن است که git-
               pack-objects(1) با پشتیبانی از pthreads کامپایل شده باشد، در
               غیر این صورت این گزینه با نمایش یک هشدار نادیده گرفته می‌شود.
               این کار برای کاهش زمان بسته‌بندی در ماشین‌های چندپردازنده‌ای در
               نظر گرفته شده است. با این حال، مقدار حافظه مورد نیاز برای پنجره
               جستجوی دلتا در تعداد ریسمان‌ها ضرب می‌شود. تعیین مقدار 0 باعث
               می‌شود Git تعداد پردازنده‌ها را به‌طور خودکار تشخیص داده و تعداد
               ریسمان‌ها را متناسب با آن تنظیم کند.

           pack.indexVersion
               نسخه پیش‌فرض ایندکس بسته را مشخص می‌کند. مقادیر معتبر عبارتند از
               1 برای ایندکس بسته قدیمی که توسط نسخه‌های Git قبل از 1.5.2
               استفاده می‌شد، و 2 برای ایندکس بسته جدید با قابلیت پشتیبانی از
               بسته‌های بزرگ‌تر از 4 گیگابایت و همچنین محافظت مناسب در برابر
               بسته‌بندی مجدد بسته‌های خراب. نسخه 2 پیش‌فرض است. توجه داشته باشید
               که هر زمان بسته مربوطه بزرگ‌تر از 2 گیگابایت باشد، نسخه 2 اجباری
               شده و این گزینه پیکربندی نادیده گرفته می‌شود.

               اگر نسخه قدیمی Git را دارید که فایل *.idx نسخه 2 را درک نمی‌کند،
               کلون کردن یا واکشی از طریق یک پروتکل غیربومی (مانند "http") که
               هر دو فایل *.pack و فایل مربوطه *.idx را از طرف دیگر کپی می‌کند،
               ممکن است مخزنی به شما بدهد که با نسخه قدیمی‌تر Git شما قابل
               دسترسی نباشد. اما اگر فایل *.pack کوچک‌تر از 2 گیگابایت باشد،
               می‌توانید از git-index-pack(1) روی فایل *.pack برای تولید مجدد
               فایل *.idx استفاده کنید.

           pack.packSizeLimit
               حداکثر اندازه یک بسته. این تنظیم فقط روی بسته‌بندی در یک فایل
               هنگام بسته‌بندی مجدد تأثیر می‌گذارد، یعنی پروتکل git:// تحت تأثیر
               قرار نمی‌گیرد. این گزینه می‌تواند با گزینه --max-pack-size از
               دستور git-repack(1) بازنویسی شود. رسیدن به این محدودیت منجر به
               ایجاد چندین فایل بسته می‌شود.

               توجه داشته باشید که این گزینه به ندرت مفید است و ممکن است منجر
               به افزایش اندازه کل روی دیسک (زیرا Git دلتاها را میان بسته‌ها
               ذخیره نمی‌کند) و کارایی ضعیف‌تر در زمان اجرا شود (جستجوی اشیاء در
               چندین بسته کندتر از یک بسته است، و بهینه‌سازی‌هایی مانند بیت‌مپ‌های
               دسترسی‌پذیری نمی‌توانند با چند بسته سازگار شوند).

               اگر نیاز دارید Git را با فایل‌های بسته کوچک‌تر اجرا کنید (مثلاً به
               این دلیل که سیستم فایل شما از فایل‌های بزرگ پشتیبانی نمی‌کند)،
               این گزینه ممکن است کمک کند. اما اگر هدف شما انتقال فایل بسته از
               طریق رسانه‌ای است که از اندازه‌های محدود پشتیبانی می‌کند (مثلاً
               رسانه‌های جداشدنی که نمی‌توانند کل مخزن را ذخیره کنند)، احتمالاً
               بهتر است یک فایل بسته بزرگ تکی ایجاد کرده و آن را با استفاده از
               یک ابزار عمومی آرشیو چندبخشی (مانند split در یونیکس) تقسیم
               کنید.

               حداقل اندازه مجاز به 1 MiB محدود شده است. پیش‌فرض نامحدود است.
               پسوندهای رایج واحد k، m، یا g پشتیبانی می‌شوند.

           pack.useBitmaps
               هنگامی که روی true تنظیم شود، git هنگام بسته‌بندی در stdout
               (مانند زمان سمت سرور در یک واکشی) از بیت‌مپ‌های بسته (در صورت
               موجود بودن) استفاده خواهد کرد. مقدار پیش‌فرض true است. به‌طور کلی
               نباید نیازی به خاموش کردن این گزینه داشته باشید، مگر اینکه در
               حال اشکال‌زدایی بیت‌مپ‌های بسته باشید.

           pack.useBitmapBoundaryTraversal
               هنگامی که روی true تنظیم شود، Git از یک الگوریتم آزمایشی برای
               محاسبه پرس‌وجوهای دسترسی‌پذیری با بیت‌مپ‌ها استفاده خواهد کرد. به
               جای ساخت بیت‌مپ‌های کامل برای تمام سرشاخه‌های منفی‌شده (negated
               tips) و سپس اعمال عملگر OR بین آن‌ها، سرشاخه‌های منفی‌شده با
               بیت‌مپ‌های موجود را افزایشی در نظر می‌گیرد (یعنی اگر وجود داشته
               باشند، آن‌ها را در نتیجه OR می‌کند و در غیر این صورت از آن‌ها
               صرف‌نظر می‌کند)، و در عوض یک بیت‌مپ در مرز می‌سازد.

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

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

           pack.useSparse
               هنگامی که روی true تنظیم شود، git به طور پیش‌فرض هنگام حضور
               گزینه --sparse از گزینه --sparse در git pack-objects استفاده
               خواهد کرد. این الگوریتم تنها درخت‌هایی را پیمایش می‌کند که در
               مسیرهای معرفی‌کننده اشیاء جدید ظاهر می‌شوند. این کار می‌تواند
               هنگام محاسبه یک بسته برای ارسال تغییری کوچک، مزایای عملکردی
               چشمگیری داشته باشد. با این حال، اگر کامیت‌های شامل‌شده دارای
               انواع خاصی از تغییر نام‌های مستقیم باشند، ممکن است اشیاء اضافی
               به فایل بسته افزوده شوند. پیش‌فرض true است.

           pack.usePathWalk
               گزینه --path-walk را به صورت پیش‌فرض برای فرآیندهای git
               pack-objects فعال می‌کند. برای جزئیات کامل به git-pack-
               objects(1) مراجعه کنید.

           pack.preferBitmapTips
               یک سلسله‌مراتب مرجع (ref hierarchy) را مشخص می‌کند (مانند
               "refs/heads/")؛ می‌تواند چند بار برای مشخص کردن بیش از یک
               سلسله‌مراتب داده شود. هنگام انتخاب اینکه کدام کامیت‌ها بیت‌مپ
               دریافت کنند، کامیتی که در سرشاخه (tip) مرجعی قرار دارد که در هر
               یک از سلسله‌مراتب‌های پیکربندی‌شده گنجانده شده است، در اولویت قرار
               می‌گیرد.

               توجه داشته باشید که تنظیم این پیکربندی روی refs/foo/ به این
               معنی نیست که کامیت‌های موجود در سرشاخه‌های refs/foo/bar و
               refs/foo/baz لزوماً انتخاب خواهند شد. دلیل این امر آن است که
               کامیت‌ها برای بیت‌مپ‌ها از میان مجموعه‌ای از پنجره‌های با طول متغیر
               انتخاب می‌شوند.

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

           pack.writeBitmaps (منسوخ‌شده)
               این یک مترادف منسوخ‌شده برای repack.writeBitmaps است.

           pack.writeBitmapHashCache
               هنگامی که روی true تنظیم شود، git بخشی تحت عنوان "hash cache"
               را در ایندکس بیت‌مپ (در صورت نوشته شدن) شامل خواهد کرد. این کش
               می‌تواند برای تغذیه قواعد مکاشفه‌ای دلتا در git استفاده شود، که
               بالقوه منجر به دلتاهای بهتری میان اشیاء دارای بیت‌مپ و فاقد
               بیت‌مپ می‌شود (برای مثال، هنگام پاسخ‌گویی به یک واکشی میان یک بسته
               قدیمی‌تر دارای بیت‌مپ و اشیائی که پس از آخرین gc پوش شده‌اند). عیب
               آن این است که 4 بایت به ازای هر شیء از فضای دیسک را مصرف می‌کند.
               مقدار پیش‌فرض true است.

               هنگام نوشتن یک بیت‌مپ دسترسی‌پذیری چندبسته‌ای، هیچ namehash جدیدی
               محاسبه نمی‌شود؛ در عوض، هر namehash ذخیره‌شده در یک بیت‌مپ موجود
               هنگام نوشتن یک بیت‌مپ جدید به مکان مناسب خود جابه‌جا (permuted)
               می‌شود.

           pack.writeBitmapLookupTable
               هنگامی که روی true تنظیم شود، Git بخشی تحت عنوان "lookup table"
               (جدول جستجو) را در ایندکس بیت‌مپ (در صورت نوشته شدن) می‌گنجاند.
               این جدول برای به تعویق انداختن بارگذاری بیت‌مپ‌های منفرد تا جای
               ممکن استفاده می‌شود. این کار می‌تواند در مخازنی که ایندکس‌های
               بیت‌مپ نسبتاً بزرگی دارند سودمند باشد. مقدار پیش‌فرض false است.

           pack.readReverseIndex
               هنگامی که روی true تنظیم شود، git هر فایل .rev موجود را می‌خواند
               (ببینید: gitformat-pack(5)). هنگامی که روی false باشد، ایندکس
               معکوس از ابتدا تولید شده و در حافظه ذخیره می‌شود. مقدار پیش‌فرض
               true است.

           pack.writeReverseIndex
               هنگامی که روی true تنظیم شود، git برای هر فایل بسته جدیدی که
               می‌نویسد، یک فایل .rev متناظر می‌نویسد (ببینید: gitformat-
               pack(5))، در همه جا به جز در git-fast-import(1) و در سازوکار
               ثبت فله‌ای (bulk checkin). مقدار پیش‌فرض true است.

           pager.<cmd>
               اگر مقدار یک بولی باشد، صفحه‌بندی خروجی یک زیردستور خاص Git را
               هنگام نوشتن در tty روشن یا خاموش می‌کند. در غیر این صورت،
               صفحه‌بندی را برای آن زیردستور با استفاده از صفحه‌بندی‌کننده‌ای
               (pager) که مقدار pager.<cmd> مشخص کرده فعال می‌کند. اگر
               --paginate یا --no-pager در خط فرمان مشخص شود، بر این گزینه
               اولویت دارد. برای غیرفعال کردن صفحه‌بندی برای همه دستورات،
               core.pager یا GIT_PAGER را روی cat تنظیم کنید.

           pretty.<name>
               نام مستعار برای یک رشته قالب --pretty=، همان‌طور که در git-
               log(1) مشخص شده است. هر نام مستعاری که در اینجا تعریف شود
               می‌تواند درست مانند قالب‌های تزیینی (pretty formats) توکار
               استفاده شود. برای مثال، اجرای git config pretty.changelog
               "format:* %H %s" باعث می‌شود که فراخوانی git log
               --pretty=changelog معادل اجرای git log "--pretty=format:* %H
               %s" باشد. توجه داشته باشید که نام مستعار هم‌نام با یک قالب
               توکار، بدون هیچ پیامی نادیده گرفته خواهد شد.

           promisor.quiet
               اگر روی "true" تنظیم شود، هنگام واکشی اشیاء اضافی برای یک کلون
               جزئی (partial clone)، گزینه --quiet فرض می‌شود.

           promisor.advertise
               اگر روی "true" تنظیم شود، یک سرور از قابلیت "promisor-remote"
               (ببینید: gitprotocol-v2(5)) برای اعلان ریموت‌های promisor که
               استفاده می‌کند (در صورت وجود) استفاده خواهد کرد. مقدار پیش‌فرض
               "false" است، به این معنی که قابلیت "promisor-remote" اعلان
               نمی‌شود.

           promisor.sendFields
               فهرستی از نام‌های فیلدهای اضافی مرتبط با ریموت که با کاما یا
               فاصله از هم جدا شده‌اند. سرور هنگام اعلان ریموت‌های promisor خود
               با استفاده از قابلیت "promisor-remote" (ببینید: gitprotocol-
               v2(5))، این نام‌های فیلد و مقادیر مرتبط با آن‌ها را از پیکربندی
               خود ارسال می‌کند. در حال حاضر، تنها نام‌های فیلد
               "partialCloneFilter" و "token" پشتیبانی می‌شوند.

           partialCloneFilter
               شامل فیلتر کلون جزئی است که برای ریموت استفاده می‌شود.

           token
               شامل یک توکن احراز هویت برای ریموت است.

               هنگامی که یک نام فیلد بخشی از این فهرست باشد و متغیر پیکربندی
               متناظر "remote.foo.<field-name>" در سرور روی مقداری غیرخالی
               تنظیم شده باشد، آنگاه نام و مقدار فیلد هنگام اعلان ریموت
               promisor با نام "foo" ارسال می‌شوند.

               این فهرست هیچ اثری ندارد مگر اینکه متغیر پیکربندی
               "promisor.advertise" روی "true" تنظیم شده باشد، و فیلدهای
               "name" و "url" همیشه فارغ از این تنظیم اعلان می‌شوند.

           promisor.acceptFromServer
               اگر روی "all" تنظیم شود، کلاینت تمام ریموت‌های promisor را که
               ممکن است سرور با استفاده از قابلیت "promisor-remote" اعلان کند
               می‌پذیرد. اگر روی "knownName" تنظیم شود، کلاینت ریموت‌های
               promisor را که از قبل روی کلاینت پیکربندی شده‌اند و نامی یکسان
               با موارد اعلان‌شده دارند می‌پذیرد. این حالت چندان امن نیست، اما
               می‌تواند در یک ساختار شرکتی که به سرورها و کلاینت‌ها برای تغییر
               ندادن نام و URLها اعتماد وجود دارد استفاده شود. اگر روی
               "knownUrl" تنظیم شود، کلاینت ریموت‌های promisor را می‌پذیرد که هم
               نام و هم URL یکسانی در کلاینت با نام و URL اعلان‌شده توسط سرور
               داشته باشند. این حالت از "all" یا "knownName" امن‌تر است،
               بنابراین در صورت امکان باید به جای آن گزینه‌ها استفاده شود.
               مقدار پیش‌فرض "none" است، به این معنی که هیچ ریموت promisor
               اعلان‌شده توسط سرور پذیرفته نخواهد شد. با پذیرش یک ریموت
               promisor، کلاینت موافقت می‌کند که سرور ممکن است اشیائی را که
               می‌توان آن‌ها را به‌صورت تنبل (lazily) از این ریموت promisor واکشی
               کرد، از پاسخ‌های خود به درخواست‌های "fetch" و "clone" از سوی
               کلاینت حذف کند. مقایسه‌های نام و URL به حروف بزرگ و کوچک حساس
               هستند. ببینید: gitprotocol-v2(5).

           promisor.checkFields
               فهرستی از نام‌های فیلدهای اضافی مرتبط با ریموت که با کاما یا
               فاصله از هم جدا شده‌اند. کلاینت پیش از پذیرش یک ریموت promisor
               بررسی می‌کند که آیا مقادیر این فیلدها که توسط یک سرور ارسال
               شده‌اند با مقادیر این فیلدها در پیکربندی خود مطابقت دارند یا
               خیر. در حال حاضر، "partialCloneFilter" و "token" تنها نام‌های
               فیلد پشتیبانی‌شده هستند.

               اگر یکی از این نام‌های فیلد (مثلاً "token") برای یک ریموت
               promisor اعلان‌شده (مثلاً "foo") در حال بررسی باشد، سه شرط باید
               برقرار باشد تا بررسی این فیلد خاص پذیرفته شود:

                1. پیکربندی محلی متناظر (مثلاً remote.foo.token) باید تنظیم شده
                   باشد.

                2. سرور باید فیلد "token" را برای ریموت "foo" اعلان کند.

                3. مقدار پیکربندی محلی remote.foo.token باید دقیقاً با مقدار
                   اعلان‌شده توسط سرور برای فیلد "token" مطابقت داشته باشد.

               اگر هر یک از این شرایط برای هر نام فیلد فهرست‌شده در
               promisor.checkFields برقرار نباشد، ریموت اعلان‌شده "foo" رد
               می‌شود.

               برای فیلد "partialCloneFilter"، این به کلاینت اجازه می‌دهد تا
               اطمینان حاصل کند که فیلتر سرور با آنچه کلاینت به صورت محلی
               انتظار دارد مطابقت دارد، و از ناسازگاری‌ها در رفتار فیلتر کردن
               جلوگیری شود. برای فیلد "token"، می‌توان از این برای تأیید اینکه
               اطلاعات احراز هویت با مقادیر مورد انتظار مطابقت دارند استفاده
               کرد.

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

               فیلدهای "name" و "url" همیشه بر اساس سیاست
               promisor.acceptFromServer و مستقل از این تنظیم بررسی می‌شوند.

               نام‌ها و مقادیر فیلدها باید از طریق قابلیت "promisor-remote"
               توسط سرور با استفاده از متغیر پیکربندی promisor.sendFields
               ارسال شوند. این فیلدها تنها در صورتی بررسی می‌شوند که متغیر
               پیکربندی promisor.acceptFromServer روی "None" تنظیم نشده باشد.
               در صورت تنظیم روی "None"، این متغیر پیکربندی هیچ اثری ندارد.
               ببینید: gitprotocol-v2(5).

           promisor.storeFields
               فهرستی از نام‌های فیلدهای اضافی مرتبط با ریموت که با کاما یا
               فاصله از هم جدا شده‌اند. اگر کلاینت یک ریموت اعلان‌شده را بپذیرد،
               مقادیر مرتبط با این نام‌های فیلد برگرفته از اعلان ریموت را در
               پیکربندی خود ذخیره کرده و سپس پیکربندی ریموت خود را مجدداً
               بارگذاری می‌کند. در حال حاضر، "partialCloneFilter" و "token"
               تنها نام‌های فیلد پشتیبانی‌شده هستند.

               برای مثال، اگر سرور "partialCloneFilter=blob:limit=20k" را برای
               ریموت "foo" اعلان کند و آن ریموت پذیرفته شود، آنگاه
               "blob:limit=20k" برای متغیر پیکربندی
               "remote.foo.partialCloneFilter" ذخیره خواهد شد.

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

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

               توجه داشته باشید که به دلایل امنیتی، اگر ریموت از قبل در سمت
               کلاینت پیکربندی نشده باشد، هیچ چیزی برای آن ریموت ذخیره نخواهد
               شد. در هر صورت، هیچ ریموت جدیدی ایجاد نخواهد شد و هیچ URLی
               ذخیره نخواهد شد.

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

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

           protocol.allow
               در صورت تنظیم، یک سیاست پیش‌فرض تعریف‌شده توسط کاربر برای تمام
               پروتکل‌هایی که صراحتاً سیاستی ندارند (protocol.<name>.allow)
               فراهم می‌کند. به‌طور پیش‌فرض در صورت تنظیم نشدن، پروتکل‌های
               شناخته‌شده به عنوان امن (http، https، git، ssh) دارای سیاست
               پیش‌فرض always، پروتکل‌های شناخته‌شده به عنوان خطرناک (ext) دارای
               سیاست پیش‌فرض never، و سایر پروتکل‌ها (از جمله file) دارای سیاست
               پیش‌فرض user هستند. سیاست‌های پشتیبانی‌شده:

               •   always - پروتکل همیشه قابل استفاده است.

               •   never - پروتکل هرگز قابل استفاده نیست.

               •   user - پروتکل تنها زمانی قابل استفاده است که
                   GIT_PROTOCOL_FROM_USER یا تنظیم نشده باشد یا مقدار 1 داشته
                   باشد. این سیاست باید زمانی استفاده شود که می‌خواهید پروتکل
                   مستقیماً توسط کاربر قابل استفاده باشد اما نمی‌خواهید توسط
                   دستوراتی که دستورات clone/fetch/push را بدون ورودی کاربر
                   اجرا می‌کنند (مانند مقداردهی اولیه بازگشتی زیرماژول‌ها)
                   استفاده شود.

           protocol.<name>.allow
               سیاستی را برای استفاده توسط پروتکل <name> با دستورات
               clone/fetch/push تنظیم می‌کند. برای سیاست‌های موجود، به
               protocol.allow در بالا مراجعه کنید.

               نام‌های پروتکل‌هایی که در حال حاضر توسط git استفاده می‌شوند
               عبارتند از:

               •   file: هر مسیر مبتنی بر فایل محلی (شامل نشانی‌های file:// یا
                   مسیرهای محلی)

               •   git: پروتکل ناشناس git روی یک اتصال مستقیم TCP (یا پروکسی،
                   در صورت پیکربندی)

               •   ssh: پروتکل git روی ssh (شامل ساختار host:path، ssh:// و
                   غیره).

               •   http: پروتکل git روی http، هم "smart http" و هم "dumb
                   http". توجه داشته باشید که این شامل https نمی‌شود؛ اگر
                   می‌خواهید هر دو را پیکربندی کنید، باید این کار را جداگانه
                   انجام دهید.

               •   هر کمک‌کننده خارجی با پروتکل خود نام‌گذاری می‌شود (برای مثال،
                   از hg برای مجاز کردن کمک‌کننده git-remote-hg استفاده کنید)

           protocol.version
               در صورت تنظیم، کلاینت‌ها تلاش خواهند کرد با استفاده از نسخه
               مشخص‌شده پروتکل با سرور ارتباط برقرار کنند. اگر سرور از آن
               پشتیبانی نکند، ارتباط به نسخه 0 تنزل می‌یابد. در صورت تنظیم
               نشدن، پیش‌فرض 2 است. نسخه‌های پشتیبانی‌شده:

               •   0 - پروتکل مخابره‌ای (wire protocol) اصلی.

               •   1 - پروتکل مخابره‌ای اصلی با اضافه شدن یک رشته نسخه در پاسخ
                   اولیه از سرور.

               •   2 - نسخه 2 پروتکل مخابره‌ای، ببینید: gitprotocol-v2(5).

           pull.ff
               به‌طور پیش‌فرض، Git هنگام ادغام کامیتی که از نوادگان کامیت فعلی
               است، کامیت ادغام اضافی ایجاد نمی‌کند. در عوض، سرشاخه شاخه فعلی
               به جلو رانده می‌شود (fast-forward). هنگامی که روی false تنظیم
               شود، این متغیر به Git می‌گوید که در چنین مواردی یک کامیت ادغام
               اضافی ایجاد کند (معادل دادن گزینه --no-ff از خط فرمان). هنگامی
               که روی only تنظیم شود، فقط چنین ادغام‌های رو به جلویی
               (fast-forward) مجاز هستند (معادل دادن گزینه --ff-only از خط
               فرمان). این تنظیم در زمان اجرای pull، گزینه merge.ff را
               بازنویسی می‌کند.

           pull.rebase
               هنگامی که true باشد، هنگام اجرای "git pull"، شاخه‌ها به جای
               ادغام با شاخه پیش‌فرض از ریموت پیش‌فرض، بر روی شاخه واکشی‌شده
               ریبیس (rebase) می‌شوند. برای تنظیم این مورد برای هر شاخه به صورت
               جداگانه، به "branch.<name>.rebase" مراجعه کنید.

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

               هنگامی که مقدار interactive (یا فقط i) باشد، ریبیس در حالت
               تعاملی اجرا می‌شود.

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

           pull.octopus
               راهبرد ادغام پیش‌فرض برای استفاده هنگام پول کردن همزمان چند
               شاخه.

           pull.autoStash
               هنگامی که روی true تنظیم شود، پیش از شروع عملیات به‌طور خودکار
               یک مدخل موقت در اندوخته (stash) ایجاد می‌کند تا تغییرات محلی را
               ثبت کند، و پس از اتمام عملیات آن‌ها را بازیابی می‌کند. زمانی که
               "git pull" شما ریبیس انجام می‌دهد (به جای ادغام)، این کار
               می‌تواند بسیار مفید باشد؛ زیرا بر خلاف پول مبتنی بر ادغام که
               تغییرات محلی بدون تداخل با ادغام را تحمل می‌کند، پول مبتنی بر
               ریبیس از کار با هرگونه تغییر محلی خودداری می‌کند.

               اگر pull.autostash تنظیم شده باشد (چه روی true و چه false)،
               گزینه‌های merge.autostash و rebase.autostash نادیده گرفته
               می‌شوند. اگر pull.autostash اصلاً تنظیم نشده باشد، بسته به مقدار
               pull.rebase، به جای آن از merge.autostash یا rebase.autostash
               استفاده می‌شود. می‌تواند توسط گزینه خط فرمان --[no-]autostash
               بازنویسی شود.

           pull.twohead
               راهبرد ادغام پیش‌فرض برای استفاده هنگام پول کردن یک شاخه منفرد.

           push.autoSetupRemote
               اگر روی true تنظیم شود، هنگام پوش پیش‌فرض در شرایطی که هیچ
               ردیابی بالادستی (upstream tracking) برای شاخه فعلی وجود ندارد،
               گزینه --set-upstream را فرض می‌کند؛ این گزینه با مقادیر simple،
               upstream و current از تنظیم push.default اثر می‌گذارد. این تنظیم
               زمانی مفید است که بخواهید شاخه‌های جدید به‌طور پیش‌فرض به ریموت
               پیش‌فرض پوش شوند (مانند رفتار push.default=current) و همچنین
               بخواهید ردیابی بالادست تنظیم گردد. جریان‌های کاری که بیشترین
               بهره را از این گزینه می‌برند، جریان‌های کاری متمرکز simple هستند
               که در آن‌ها انتظار می‌رود تمام شاخه‌ها نام یکسانی در ریموت داشته
               باشند.

           push.default
               عملیاتی را تعریف می‌کند که git push در صورت مشخص نشدن هیچ مشخصه
               مرجعی (refspec) (چه از خط فرمان، چه پیکربندی یا جای دیگر) باید
               انجام دهد. مقادیر مختلف برای جریان‌های کاری خاصی مناسب هستند؛
               برای مثال، در یک جریان کاری کاملاً متمرکز (یعنی منبع واکشی با
               مقصد پوش یکسان است)، احتمالاً upstream همان چیزی است که
               می‌خواهید. مقادیر ممکن عبارتند از:

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

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

               upstream
                   شاخه فعلی را به شاخه‌ای که تغییراتش معمولاً در شاخه فعلی
                   ادغام می‌شوند (که @{upstream} نامیده می‌شود) برمی‌گرداند و پوش
                   می‌کند. این حالت تنها در صورتی منطقی است که به همان مخزنی
                   پوش می‌کنید که معمولاً از آن پول می‌کنید (یعنی جریان کاری
                   متمرکز).

               tracking
                   این یک مترادف منسوخ‌شده برای upstream است.

               simple
                   شاخه فعلی را با همان نام در ریموت پوش می‌کند.

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

                   این حالت از نسخه Git 2.0 پیش‌فرض است، و امن‌ترین گزینه مناسب
                   برای مبتدیان است.

               matching
                   تمام شاخه‌هایی را که نام یکسانی در هر دو طرف دارند پوش
                   می‌کند. این باعث می‌شود مخزنی که به آن پوش می‌کنید، مجموعه
                   شاخه‌هایی را که پوش می‌شوند به خاطر بسپارد (برای مثال اگر
                   همیشه maint و master را به آنجا پوش کنید و هیچ شاخه دیگری
                   را پوش نکنید، مخزنی که به آن پوش می‌کنید دارای این دو شاخه
                   خواهد بود و شاخه‌های محلی maint و master شما به آنجا پوش
                   خواهند شد).

                   برای استفاده مؤثر از این حالت، باید مطمئن شوید که تمام
                   شاخه‌هایی که می‌خواهید پوش کنید، قبل از اجرای git push آماده
                   پوش شدن هستند؛ زیرا کل هدف این حالت این است که به شما امکان
                   دهد تمام شاخه‌ها را یک‌باره پوش کنید. اگر معمولاً کار روی تنها
                   یک شاخه را تمام کرده و نتیجه را پوش می‌کنید در حالی که سایر
                   شاخه‌ها ناتمام هستند، این حالت مناسب شما نیست. همچنین این
                   حالت برای پوش کردن به یک مخزن متمرکز اشتراکی مناسب نیست،
                   زیرا ممکن است افراد دیگر شاخه‌های جدیدی در آنجا اضافه کنند،
                   یا سرشاخه شاخه‌های موجود را خارج از کنترل شما به‌روزرسانی
                   کنند.

                   این حالت قبلاً پیش‌فرض بود، اما از Git 2.0 به بعد این‌گونه
                   نیست (simple پیش‌فرض جدید است).

           push.followTags
               اگر روی true تنظیم شود، گزینه --follow-tags را به صورت پیش‌فرض
               فعال می‌کند. می‌توانید این پیکربندی را در زمان پوش با مشخص کردن
               --no-follow-tags بازنویسی کنید.

           push.gpgSign
               می‌تواند روی یک مقدار بولی، یا رشته if-asked تنظیم شود. مقدار
               true باعث می‌شود تمام پوش‌ها با GPG امضا شوند، گویی که --signed
               به git-push(1) داده شده است. رشته if-asked باعث می‌شود پوش‌ها در
               صورتی که سرور از آن پشتیبانی کند امضا شوند، گویی که
               --signed=if-asked به git push داده شده است. مقدار false می‌تواند
               مقداری از یک فایل پیکربندی با اولویت پایین‌تر را بازنویسی کند.
               یک فلگ صریح خط فرمان همیشه این گزینه پیکربندی را بازنویسی
               می‌کند.

           push.pushOption
               هنگامی که هیچ آرگومان --push-option=<option> از خط فرمان داده
               نشود، git push طوری عمل می‌کند که گویی هر <option> از این متغیر
               به صورت --push-option=<option> داده شده است.

               این یک متغیر چندمقداری است، و می‌توان از یک مقدار خالی در یک
               فایل پیکربندی با اولویت بالاتر (مانند .git/config در یک مخزن)
               برای پاک کردن مقادیر به ارث رسیده از فایل‌های پیکربندی با اولویت
               پایین‌تر (مانند $HOME/.gitconfig) استفاده کرد.

                   مثال:

                   /etc/gitconfig
                     push.pushoption = a
                     push.pushoption = b

                   ~/.gitconfig
                     push.pushoption = c

                   repo/.git/config
                     push.pushoption =
                     push.pushoption = b

                   این تنها منجر به b خواهد شد (a و c پاک می‌شوند).


           push.recurseSubmodules
               می‌تواند check، on-demand، only، یا no باشد، با همان رفتاری که
               push --recurse-submodules دارد. در صورت تنظیم نشدن، به‌طور
               پیش‌فرض no استفاده می‌شود، مگر اینکه submodule.recurse تنظیم شده
               باشد (که در این صورت، مقدار true به معنی on-demand است).

           push.useForceIfIncludes
               اگر روی true تنظیم شود، معادل مشخص کردن --force-if-includes به
               عنوان یک گزینه برای git-push(1) در خط فرمان است. افزودن
               --no-force-if-includes در زمان پوش، این تنظیم پیکربندی را
               بازنویسی می‌کند.

           push.negotiate
               اگر روی true تنظیم شود، تلاش می‌کند اندازه فایل بسته ارسالی را
               از طریق دورهایی از مذاکره کاهش دهد که در آن کلاینت و سرور سعی
               می‌کنند کامیت‌های مشترک را پیدا کنند. اگر false باشد، Git برای
               یافتن کامیت‌های مشترک صرفاً به اعلان مرجع‌های سرور متکی خواهد بود.

           push.useBitmaps
               اگر روی false تنظیم شود، استفاده از بیت‌مپ‌ها را برای git push
               غیرفعال می‌کند حتی اگر pack.useBitmaps روی true باشد، بدون آنکه
               مانع استفاده سایر عملیات‌های git از بیت‌مپ‌ها شود. پیش‌فرض true
               است.

           rebase.backend
               بک‌اند (پایانه پشتی) پیش‌فرض برای استفاده در ریبیس. گزینه‌های ممکن
               عبارتند از apply یا merge. در آینده، اگر بک‌اند merge تمام
               قابلیت‌های باقی‌مانده بک‌اند apply را به دست آورد، این تنظیم ممکن
               است بدون استفاده شود.

           rebase.stat
               آیا آمار تغییرات (diffstat) آنچه از آخرین ریبیس در بالادست
               تغییر کرده نشان داده شود یا خیر. به‌طور پیش‌فرض false است.

           rebase.autoSquash
               اگر روی true تنظیم شود، گزینه --autosquash از git-rebase(1) را
               به‌طور پیش‌فرض برای حالت تعاملی فعال می‌کند. این گزینه می‌تواند با
               گزینه --no-autosquash بازنویسی شود.

           rebase.autoStash
               هنگامی که روی true تنظیم شود، پیش از شروع عملیات به‌طور خودکار
               یک مدخل موقت در اندوخته (stash) ایجاد کرده و پس از پایان عملیات
               آن را اعمال می‌کند. این بدان معناست که می‌توانید ریبیس را روی یک
               درخت کاری دارای تغییرات ثبت‌نشده (dirty worktree) اجرا کنید. با
               این حال با احتیاط استفاده کنید: اعمال نهایی اندوخته پس از یک
               ریبیس موفق ممکن است به تعارض‌های غیرجزئی منجر شود. این گزینه
               می‌تواند توسط گزینه‌های --no-autostash و --autostash از git-
               rebase(1) بازنویسی شود. پیش‌فرض false است.

           rebase.updateRefs
               اگر روی true تنظیم شود، گزینه --update-refs را به‌طور پیش‌فرض
               فعال می‌کند.

           rebase.missingCommitsCheck
               اگر روی "warn" تنظیم شود، git rebase -i در صورت حذف شدن برخی از
               کامیت‌ها (مثلاً یک خط حذف شده باشد) یک هشدار چاپ می‌کند، اما ریبیس
               همچنان ادامه خواهد یافت. اگر روی "error" تنظیم شود، هشدار قبلی
               را چاپ کرده و ریبیس را متوقف می‌کند؛ سپس می‌توان از git rebase
               --edit-todo برای تصحیح خطا استفاده کرد. اگر روی "ignore" تنظیم
               شود، هیچ بررسی‌ای انجام نمی‌شود. برای کنار گذاشتن یک کامیت بدون
               هشدار یا خطا، از دستور drop در فهرست کارهای انجام‌شدنی (todo
               list) استفاده کنید. مقدار پیش‌فرض "ignore" است.

           rebase.instructionFormat
               یک رشته قالب، همان‌طور که در git-log(1) مشخص شده است، برای
               استفاده در فهرست کارهای انجام‌شدنی (todo list) در طول یک ریبیس
               تعاملی. هش کامیت به‌طور خودکار در ابتدای این قالب قرار خواهد
               گرفت.

           rebase.abbreviateCommands
               اگر روی true تنظیم شود، git rebase از نام‌های اختصاری دستورات در
               فهرست کارهای انجام‌شدنی استفاده خواهد کرد که نتیجه‌ای شبیه به این
               خواهد داشت:

                           p deadbee The oneline of the commit
                           p fa1afe1 The oneline of the next commit
                           ...

               به جای:

                           pick deadbee The oneline of the commit
                           pick fa1afe1 The oneline of the next commit
                           ...

               پیش‌فرض false است.

           rebase.rescheduleFailedExec
               دستورات exec شکست‌خورده را به‌طور خودکار دوباره زمان‌بندی می‌کند.
               این فقط در حالت تعاملی (یا زمانی که گزینه --exec ارائه شده
               باشد) معنا دارد. این معادل مشخص کردن گزینه
               --reschedule-failed-exec است.

           rebase.forkPoint
               اگر روی false تنظیم شود، گزینه --no-fork-point را به‌طور پیش‌فرض
               تنظیم می‌کند.

           rebase.rebaseMerges
               آیا و چگونه گزینه --rebase-merges به صورت پیش‌فرض تنظیم شود.
               می‌تواند rebase-cousins، no-rebase-cousins، یا یک مقدار بولی
               باشد. تنظیم روی true یا روی no-rebase-cousins معادل
               --rebase-merges=no-rebase-cousins است، تنظیم روی rebase-cousins
               معادل --rebase-merges=rebase-cousins است، و تنظیم روی false
               معادل --no-rebase-merges می‌باشد. ارسال --rebase-merges در خط
               فرمان، با یا بدون آرگومان، هرگونه پیکربندی rebase.rebaseMerges
               را بازنویسی می‌کند.

           rebase.maxLabelLength
               هنگام تولید نام‌های برچسب (label) از موضوعات کامیت، نام‌ها را به
               این طول کوتاه می‌کند. به‌طور پیش‌فرض، نام‌ها به کمی کمتر از
               NAME_MAX کوتاه می‌شوند (تا اجازه داده شود برای مثال فایل‌های
               .lock برای مرجع‌های مجزای متناظر نوشته شوند).

           receive.advertiseAtomic
               به‌طور پیش‌فرض، git-receive-pack قابلیت پوش اتمیک (atomic push)
               را به کلاینت‌های خود اعلان خواهد کرد. اگر نمی‌خواهید این قابلیت
               اعلان شود، این متغیر را روی false تنظیم کنید.

           receive.advertisePushOptions
               هنگامی که روی true تنظیم شود، git-receive-pack قابلیت گزینه‌های
               پوش (push options) را به کلاینت‌های خود اعلان می‌کند. به‌طور
               پیش‌فرض false است.

           receive.autogc
               به‌طور پیش‌فرض، git-receive-pack پس از دریافت داده‌ها از git-push
               و به‌روزرسانی مرجع‌ها، دستور "git maintenance run --auto" را اجرا
               می‌کند. می‌توانید با تنظیم این متغیر روی false، آن را متوقف کنید.

           receive.certNonceSeed
               با تنظیم این متغیر روی یک رشته، git receive-pack یک git push
               --signed را می‌پذیرد و آن را با استفاده از یک "nonce" محافظت‌شده
               توسط HMAC با استفاده از این رشته به عنوان یک کلید مخفی تأیید
               اعتبار می‌کند.

           receive.certNonceSlop
               هنگامی که یک git push --signed یک گواهی پوش همراه با یک "nonce"
               ارسال می‌کند که توسط یک receive-pack ارائه‌دهنده همان مخزن در این
               تعداد ثانیه صادر شده است، "nonce" یافت‌شده در گواهی را به
               GIT_PUSH_CERT_NONCE برای قلاب‌ها (hooks) صادر کند (به جای آنچه
               receive-pack از سمت ارسال‌کننده خواسته بود بگنجاند). این کار
               ممکن است نوشتن بررسی‌ها در قلاب‌های pre-receive و post-receive را
               کمی آسان‌تر کند. به جای بررسی متغیر محیطی
               GIT_PUSH_CERT_NONCE_SLOP که ثبت می‌کند nonce تا چند ثانیه کهنه
               است تا تصمیم بگیرند آیا می‌خواهند گواهی را بپذیرند یا خیر، آن‌ها
               تنها می‌توانند بررسی کنند که آیا GIT_PUSH_CERT_NONCE_STATUS روی
               OK است یا خیر.

           receive.fsckObjects
               اگر روی true تنظیم شود، git-receive-pack تمام اشیاء دریافتی را
               بررسی خواهد کرد. برای آنچه بررسی می‌شود، به transfer.fsckObjects
               مراجعه کنید. مقدار پیش‌فرض false است. در صورت تنظیم نشدن، مقدار
               transfer.fsckObjects به جای آن استفاده می‌شود.

           receive.fsck.<msg-id>
               مانند fsck.<msg-id> عمل می‌کند، اما توسط git-receive-pack(1) به
               جای git-fsck(1) استفاده می‌شود. برای جزئیات به مستندات
               fsck.<msg-id> مراجعه کنید.

           receive.fsck.skipList
               مانند fsck.skipList، اما توسط git-receive-pack(1) به جای git-
               fsck(1) استفاده می‌شود. برای جزئیات به مستندات fsck.skipList
               مراجعه کنید.

           receive.keepAlive
               پس از دریافت بسته از کلاینت، receive-pack ممکن است در حین
               پردازش بسته هیچ خروجی‌ای تولید نکند (اگر --quiet مشخص شده باشد)،
               که باعث می‌شود برخی شبکه‌ها اتصال TCP را قطع کنند. با تنظیم این
               گزینه، اگر receive-pack در این مرحله برای مدت receive.keepAlive
               ثانیه هیچ داده‌ای مخابره نکند، یک بسته کوتاه زنده نگه‌داری
               (keepalive) ارسال می‌کند. مقدار پیش‌فرض 5 ثانیه است؛ برای غیرفعال
               کردن کامل زنده نگه‌داری‌ها آن را روی 0 قرار دهید.

           receive.unpackLimit
               اگر تعداد اشیاء دریافتی در یک پوش کمتر از این محدودیت باشد،
               اشیاء در قالب فایل‌های اشیاء مجزا (loose objects) بازگشایی
               می‌شوند. با این حال اگر تعداد اشیاء دریافتی مساوی یا بیشتر از
               این حد باشد، بسته دریافتی پس از افزودن پایه‌های دلتای مفقود، به
               صورت یک بسته ذخیره می‌شود. ذخیره بسته حاصل از یک پوش می‌تواند
               عملیات پوش را سریع‌تر تکمیل کند، به ویژه در سیستم‌های فایل کند.
               در صورت تنظیم نشدن، مقدار transfer.unpackLimit به جای آن
               استفاده می‌شود.

           receive.maxInputSize
               اگر اندازه جریان بسته ورودی بزرگ‌تر از این حد باشد،
               git-receive-pack به جای پذیرش فایل بسته، با خطا متوقف می‌شود.
               اگر تنظیم نشود یا روی 0 تنظیم شود، اندازه نامحدود خواهد بود.

           receive.denyDeletes
               اگر روی true تنظیم شود، git-receive-pack به‌روزرسانی مرجعی را که
               منجر به حذف آن مرجع می‌شود رد خواهد کرد. از این گزینه برای
               جلوگیری از حذف مرجع از طریق یک پوش استفاده کنید.

           receive.denyDeleteCurrent
               اگر روی true تنظیم شود، git-receive-pack به‌روزرسانی مرجعی را که
               شاخه در حال حاضر وارسی‌شده (checked out) یک مخزن غیرخام
               (non-bare) را حذف می‌کند، رد خواهد کرد.

           receive.denyCurrentBranch
               اگر روی true یا "refuse" تنظیم شود، git-receive-pack به‌روزرسانی
               مرجع به شاخه در حال حاضر وارسی‌شده یک مخزن غیرخام را رد خواهد
               کرد. چنین پوشی بالقوه خطرناک است زیرا باعث عدم همگام‌سازی HEAD
               با ایندکس و درخت کاری می‌شود. اگر روی "warn" تنظیم شود، هشداری
               در مورد چنین پوشی را در stderr چاپ می‌کند اما اجازه می‌دهد پوش
               ادامه یابد. اگر روی false یا "ignore" تنظیم شود، چنین پوش‌هایی
               را بدون هیچ پیامی مجاز می‌داند. مقدار پیش‌فرض "refuse" است.

               گزینه دیگر "updateInstead" است که در صورت پوش به شاخه فعلی،
               درخت کاری را به‌روزرسانی می‌کند. این گزینه برای همگام‌سازی
               دایرکتوری‌های کاری در مواردی در نظر گرفته شده است که یک طرف از
               طریق ssh تعاملی به راحتی در دسترس نیست (مثلاً یک وب‌سایت زنده، از
               این رو الزامی است که دایرکتوری کاری تمیز باشد). این حالت همچنین
               هنگام توسعه در داخل یک ماشین مجازی برای آزمایش و رفع اشکال کد
               در سیستم‌های عامل مختلف به کار می‌آید.

               به‌طور پیش‌فرض، اگر درخت کاری یا ایندکس تفاوتی با HEAD داشته
               باشند، "updateInstead" پوش را رد خواهد کرد، اما می‌توان از قلاب
               push-to-checkout برای سفارشی‌سازی این رفتار استفاده کرد. ببینید:
               githooks(5).

           receive.denyNonFastForwards
               اگر روی true تنظیم شود، git-receive-pack به‌روزرسانی مرجعی را که
               رو به جلو (fast-forward) نیست رد خواهد کرد. از این گزینه برای
               جلوگیری از چنین به‌روزرسانی‌ای از طریق پوش، حتی اگر آن پوش اجباری
               باشد (forced push)، استفاده کنید. این متغیر پیکربندی هنگام
               مقداردهی اولیه یک مخزن اشتراکی تنظیم می‌شود.

           receive.hideRefs
               این متغیر مشابه transfer.hideRefs است، اما تنها برای
               receive-pack اعمال می‌شود (و بنابراین بر پوش‌ها تأثیر می‌گذارد، نه
               واکشی‌ها). تلاش برای به‌روزرسانی یا حذف یک مرجع پنهان توسط git
               push رد می‌شود.

           receive.procReceiveRefs
               این یک متغیر چندمقداری است که پیشوندهای مرجع را برای تطابق با
               دستورات در receive-pack تعریف می‌کند. دستورات منطبق با این
               پیشوندها توسط یک قلاب خارجی به نام "proc-receive" اجرا خواهند
               شد، به جای تابع داخلی execute_commands.  اگر این متغیر تعریف
               نشده باشد، قلاب "proc-receive" هرگز استفاده نخواهد شد، و تمام
               دستورات توسط تابع داخلی execute_commands اجرا خواهند شد.

               برای مثال، اگر این متغیر روی "refs/for" تنظیم شود، پوش کردن به
               مرجعی مانند "refs/for/master" باعث ایجاد یا به‌روزرسانی مرجعی به
               نام "refs/for/master" نخواهد شد، اما ممکن است با اجرای قلاب
               "proc-receive" مستقیماً یک درخواست پول (pull request) ایجاد یا
               به‌روزرسانی کند.

               می‌توان اصلاح‌کننده‌های اختیاری را در ابتدای مقدار برای فیلتر کردن
               دستورات برای اقدامات خاص ارائه داد: ایجاد (a)، تغییر (m)، حذف
               (d). علامت ! می‌تواند در اصلاح‌کننده‌ها برای نفی مدخل پیشوند مرجع
               گنجانده شود. برای مثال:

                   git config --system --add receive.procReceiveRefs ad:refs/heads
                   git config --system --add receive.procReceiveRefs !:refs/heads

           receive.updateServerInfo
               اگر روی true تنظیم شود، git-receive-pack پس از دریافت داده‌ها از
               git-push و به‌روزرسانی مرجع‌ها، git-update-server-info را اجرا
               می‌کند.

           receive.shallowUpdate
               اگر روی true تنظیم شود، .git/shallow می‌تواند زمانی که مرجع‌های
               جدید به ریشه‌های کم‌عمق جدیدی نیاز داشته باشند به‌روزرسانی شود. در
               غیر این صورت آن مرجع‌ها رد می‌شوند.

           reftable.blockSize
               اندازه بر حسب بایت مورد استفاده توسط بک‌اند reftable هنگام نوشتن
               بلوک‌ها. اندازه بلوک توسط نویسنده تعیین می‌شود و نیازی نیست توانی
               از 2 باشد. اندازه بلوک باید بزرگ‌تر از طولانی‌ترین نام مرجع یا
               مدخل گزارش استفاده‌شده در مخزن باشد، زیرا مرجع‌ها نمی‌توانند در
               میان بلوک‌ها امتداد یابند.

               توان‌هایی از دو که با سیستم حافظه مجازی یا سیستم فایل سازگار
               هستند (مانند 4kB یا 8kB) توصیه می‌شوند. اندازه‌های بزرگ‌تر (64kB)
               می‌توانند فشرده‌سازی بهتری را به همراه داشته باشند، همراه با
               احتمال افزایش هزینه اعمال‌شده بر خوانندگان در حین دسترسی.

               بزرگ‌ترین اندازه بلوک 16777215 بایت (15.99 MiB) است. مقدار
               پیش‌فرض 4096 بایت (4kB) است. مقدار 0 از مقدار پیش‌فرض استفاده
               خواهد کرد.

           reftable.restartInterval
               فاصله‌ای که در آن نقاط راه‌اندازی مجدد (restart points) ایجاد
               می‌شوند. بک‌اند reftable نقاط راه‌اندازی مجدد را هنگام ایجاد فایل
               تعیین می‌کند. عدد 16 ممکن است برای اندازه‌های بلوک کوچک‌تر (4k یا
               8k) و عدد 64 برای اندازه‌های بلوک بزرگ‌تر (64k) مناسب‌تر باشد.

               نقاط راه‌اندازی مجدد متوالی‌تر فشرده‌سازی پیشوند را کاهش داده و
               فضای مصرف‌شده توسط جدول restart را افزایش می‌دهد، که هر دو اندازه
               فایل را افزایش می‌دهند.

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

               حداکثر 65535 نقطه راه‌اندازی مجدد در هر بلوک پشتیبانی می‌شود.

               مقدار پیش‌فرض، ایجاد نقاط راه‌اندازی مجدد در هر 16 رکورد است.
               مقدار 0 از مقدار پیش‌فرض استفاده خواهد کرد.

           reftable.indexObjects
               آیا بک‌اند reftable باید بلوک‌های اشیاء را بنویسد یا خیر. بلوک‌های
               اشیاء یک نگاشت معکوس از شناسه شیء (object ID) به مرجع‌هایی هستند
               که به آن‌ها اشاره می‌کنند.

               مقدار پیش‌فرض true است.

           reftable.geometricFactor
               هر زمان که بک‌اند reftable جدول جدیدی را به پشته اضافه می‌کند،
               فشرده‌سازی خودکار (auto compaction) را انجام می‌دهد تا اطمینان
               حاصل شود که تنها تعداد انگشت‌شماری جدول وجود دارد. بک‌اند این کار
               را با حصول اطمینان از اینکه جدول‌ها با توجه به اندازه‌های مربوط
               به هر جدول یک دنباله هندسی تشکیل می‌دهند، انجام می‌دهد.

               به‌طور پیش‌فرض، دنباله هندسی از ضریب 2 استفاده می‌کند، به این معنی
               که برای هر جدول، جدول بزرگ‌تر بعدی باید حداقل دو برابر بزرگ‌تر
               باشد. حداکثر ضریب 256 پشتیبانی می‌شود.

           reftable.lockTimeout
               هر زمان که بک‌اند reftable یک جدول جدید به پشته اضافه می‌کند، پیش
               از به‌روزرسانی آن باید فایل مرکزی "tables.list" را قفل کند. این
               پیکربندی کنترل می‌کند که فرآیند در صورتی که فرآیند دیگری از قبل
               قفل را در اختیار گرفته باشد، چه مدت برای به دست آوردن قفل منتظر
               بماند. مقدار 0 به معنای عدم تلاش مجدد است؛ مقدار -1 به معنای
               تلاش نامحدود است. مقدار پیش‌فرض 100 است (یعنی تلاش مجدد برای 100
               میلی‌ثانیه).

           remote.pushDefault
               ریموت پیش‌فرض برای ارسال (push). این متغیر branch.<name>.remote
               را برای تمام شاخه‌ها بازنویسی می‌کند، و برای شاخه‌های خاص توسط
               branch.<name>.pushRemote بازنویسی می‌شود.

           remote.<name>.url
               نشانی URL یک مخزن ریموت. به git-fetch(1) یا git-push(1) مراجعه
               کنید. یک ریموت پیکربندی‌شده می‌تواند چندین URL داشته باشد؛ در این
               حالت اولین نشانی برای واکشی (fetch) و همه آن‌ها برای ارسال
               (push) استفاده می‌شوند (با فرض اینکه هیچ remote.<name>.pushurl
               تعریف نشده باشد). تنظیم این کلید روی رشته خالی، فهرست نشانی‌ها
               را پاک می‌کند و به شما اجازه می‌دهد پیکربندی قبلی را بازنویسی
               کنید.

           remote.<name>.pushurl
               نشانی URL ارسال (push) یک مخزن ریموت. به git-push(1) مراجعه
               کنید. اگر گزینه pushurl در یک ریموت پیکربندی‌شده وجود داشته
               باشد، به جای remote.<name>.url برای ارسال استفاده می‌شود. یک
               ریموت پیکربندی‌شده می‌تواند چندین URL ارسال داشته باشد؛ در این
               حالت ارسال به همه آن‌ها انجام می‌شود. تنظیم این کلید روی رشته
               خالی، فهرست نشانی‌ها را پاک می‌کند و به شما اجازه می‌دهد پیکربندی
               قبلی را بازنویسی کنید.

           remote.<name>.proxy
               برای ریموت‌هایی که به curl نیاز دارند (http، https و ftp)، نشانی
               پروکسی مورد استفاده برای آن ریموت. برای غیرفعال کردن پروکسی
               برای آن ریموت، آن را روی رشته خالی تنظیم کنید.

           remote.<name>.proxyAuthMethod
               برای ریموت‌هایی که به curl نیاز دارند (http، https و ftp)، روش
               مورد استفاده برای احراز هویت در برابر پروکسی در حال استفاده (که
               احتمالاً در remote.<name>.proxy تنظیم شده است). به
               http.proxyAuthMethod مراجعه کنید.

           remote.<name>.fetch
               مجموعه پیش‌فرض "refspec" برای git-fetch(1).  به git-fetch(1)
               مراجعه کنید.

           remote.<name>.push
               مجموعه پیش‌فرض "refspec" برای git-push(1).  به git-push(1)
               مراجعه کنید.

           remote.<name>.mirror
               اگر true باشد، ارسال (push) به این ریموت به‌طور خودکار به‌گونه‌ای
               عمل می‌کند که گویی گزینه --mirror در خط فرمان داده شده است.

           remote.<name>.skipDefaultUpdate
               مترادفی منسوخ‌شده برای remote.<name>.skipFetchAll (اگر هر دو در
               فایل‌های پیکربندی با مقادیر متفاوتی تنظیم شده باشند، مقدار آخرین
               رخداد استفاده خواهد شد).

           remote.<name>.skipFetchAll
               اگر true باشد، هنگام به‌روزرسانی با استفاده از git-fetch(1)،
               زیردستور update از git-remote(1) از این ریموت صرف‌نظر می‌شود، و
               توسط وظیفه پیش‌واکشی (prefetch) در git maintenance نادیده گرفته
               خواهد شد.

           remote.<name>.receivepack
               برنامه پیش‌فرض برای اجرا در سمت ریموت هنگام ارسال (push). گزینه
               --receive-pack در git-push(1) را ببینید.

           remote.<name>.uploadpack
               برنامه پیش‌فرض برای اجرا در سمت ریموت هنگام واکشی (fetch). گزینه
               --upload-pack در git-fetch-pack(1) را ببینید.

           remote.<name>.tagOpt
               تنظیم این مقدار روی --no-tags دنبال کردن خودکار برچسب‌ها را
               هنگام واکشی از ریموت <name> غیرفعال می‌کند. تنظیم آن روی --tags
               تمام برچسب‌ها را از ریموت <name> واکشی خواهد کرد، حتی اگر از نوک
               شاخه‌های ریموت قابل دسترسی نباشند. ارسال مستقیم این فلگ‌ها به
               git-fetch(1) می‌تواند این تنظیم را بازنویسی کند. گزینه‌های --tags
               و --no-tags در git-fetch(1) را ببینید.

           remote.<name>.vcs
               تنظیم این متغیر روی مقدار <vcs> باعث می‌شود Git با استفاده از
               برنامه کمکی git-remote-<vcs> با ریموت تعامل کند.

           remote.<name>.prune
               هنگامی که روی true تنظیم شود، واکشی از این ریموت به‌طور پیش‌فرض
               تمام مراجع ردیابی ریموت را که دیگر روی ریموت وجود ندارند نیز
               حذف می‌کند (گویی گزینه --prune در خط فرمان داده شده است).
               تنظیمات fetch.prune را در صورت وجود، بازنویسی می‌کند.

           remote.<name>.pruneTags
               هنگامی که روی true تنظیم شود، واکشی از این ریموت به‌طور پیش‌فرض
               تمام برچسب‌های محلی را که دیگر روی ریموت وجود ندارند نیز حذف
               می‌کند، در صورتی که هرس کردن (pruning) به‌طور کلی از طریق
               remote.<name>.prune، fetch.prune یا --prune فعال شده باشد.
               تنظیمات fetch.pruneTags را در صورت وجود، بازنویسی می‌کند.

               همچنین به remote.<name>.prune و بخش PRUNING در git-fetch(1)
               مراجعه کنید.

           remote.<name>.promisor
               هنگامی که روی true تنظیم شود، از این ریموت برای واکشی اشیاء
               promisor استفاده خواهد شد.

           remote.<name>.partialclonefilter
               فیلتری که هنگام واکشی از این ریموت promisor اعمال خواهد شد.
               تغییر دادن یا پاک کردن این مقدار فقط روی واکشی‌ها برای کامیت‌های
               جدید تأثیر می‌گذارد. برای واکشی اشیاء مرتبط با کامیت‌هایی که
               هم‌اکنون در پایگاه‌داده محلی اشیاء وجود دارند، از گزینه --refetch
               در git-fetch(1) استفاده کنید.

           remote.<name>.serverOption
               مجموعه پیش‌فرض گزینه‌های سرور که هنگام واکشی از این ریموت استفاده
               می‌شوند. این گزینه‌های سرور می‌توانند توسط آرگومان‌های خط فرمان
               --server-option= بازنویسی شوند.

               این یک متغیر چندمقداری است، و می‌توان از یک مقدار خالی در فایل
               پیکربندی با اولویت بالاتر (مثلاً .git/config در یک مخزن) برای
               پاک کردن مقادیر به ارث برده شده از فایل‌های پیکربندی با اولویت
               پایین‌تر (مثلاً $HOME/.gitconfig) استفاده کرد.

           remote.<name>.negotiationRestrict
               هنگام مذاکره با این ریموت در زمان git fetch، کامیت‌های اعلام‌شده
               به عنوان خطوط "have" را تنها به مواردی محدود می‌کند که از مراجع
               منطبق با الگوهای ارائه‌شده قابل دسترسی باشند. این گزینه پیکربندی
               چندمقداری مانند --negotiation-restrict در خط فرمان رفتار می‌کند.

               هر مقدار یا یک نام دقیق مرجع است (مثلاً refs/heads/release) یا
               یک الگوی گلوب (glob) (مثلاً refs/heads/release/*).  نحو الگو
               همانند --negotiation-restrict است.

               این مقادیر پیکربندی به عنوان پیش‌فرض‌ها برای گزینه خط فرمان
               --negotiation-restrict استفاده می‌شوند. اگر
               --negotiation-restrict (یا مترادف آن --negotiation-tip) در خط
               فرمان مشخص شده باشد، از مقادیر پیکربندی استفاده نمی‌شود.

               این مقادیر همچنین بر مذاکره در زمان git push تأثیر می‌گذارند در
               صورتی که push.negotiate فعال باشد.

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

           remote.<name>.negotiationInclude
               هنگام مذاکره با این ریموت در زمان git fetch، کلاینت فهرستی از
               کامیت‌هایی را که به صورت محلی وجود دارند اعلام می‌کند. در مخازنی
               با مراجع زیاد، این فهرست "haves" ممکن است کوتاه (truncate) شود.
               بسته به ساختار داده‌ها، نادیده گرفتن برخی مراجع ممکن است پرهزینه
               باشد. این گزینه پیکربندی چندمقداری، مراجع، هش‌های کامیت، یا
               الگوهای گلوب مرجعی را مشخص می‌کند که نوک آن‌ها باید همیشه در طول
               مذاکره واکشی با این ریموت به عنوان کامیت‌های "have" ارسال شود.

               هر مقدار یا یک نام دقیق مرجع (مثلاً refs/heads/release)، یک هش
               کامیت، یا یک الگوی گلوب (مثلاً refs/heads/release/*) است. نحو
               الگو همانند --negotiation-include است.

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

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

               این مقادیر همچنین بر مذاکره در زمان git push تأثیر می‌گذارند در
               صورتی که push.negotiate فعال باشد.

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

           remote.<name>.followRemoteHEAD
               نحوه برخورد git-fetch(1) با به‌روزرسانی‌های remotes/<name>/HEAD
               هنگام واکشی با استفاده از refspecهای پیکربندی‌شده یک ریموت.
               مقدار پیش‌فرض "create" است که در صورتی که remotes/<name>/HEAD
               روی ریموت وجود داشته باشد اما محلی نباشد، آن را ایجاد می‌کند؛
               این عمل به مرجع محلی از قبل موجود دست نمی‌زند. تنظیم آن روی
               "warn" در صورتی که ریموت مقداری متفاوت از مقدار محلی داشته باشد
               پیامی چاپ می‌کند؛ در صورتی که هیچ مرجع محلی وجود نداشته باشد،
               مانند "create" رفتار می‌کند. حالتی از "warn" مقدار
               "warn-if-not-$branch" است که مانند "warn" رفتار می‌کند، اما اگر
               HEAD روی ریموت برابر با $branch باشد، پیامی نمایش نمی‌دهد. تنظیم
               آن روی "always" مرجع remotes/<name>/HEAD را بی‌صدا به مقدار
               موجود روی ریموت به‌روزرسانی می‌کند. در نهایت، تنظیم آن روی
               "never" هرگز مرجع محلی را تغییر نداده یا ایجاد نمی‌کند.

           remotes.<group>
               فهرست ریموت‌هایی که توسط "git remote update <group>" واکشی
               می‌شوند. به git-remote(1) مراجعه کنید.

           repack.useDeltaBaseOffset
               به‌طور پیش‌فرض، git-repack(1) بسته‌هایی ایجاد می‌کند که از
               delta-base offset استفاده می‌کنند. اگر نیاز دارید مخزن خود را با
               گیت قدیمی‌تر از نسخه 1.4.4 به اشتراک بگذارید، چه به صورت مستقیم
               یا از طریق یک پروتکل غیرهوشمند مانند http، باید این گزینه را
               روی "false" تنظیم کرده و مجدداً بسته‌بندی کنید. دسترسی از نسخه‌های
               قدیمی گیت روی پروتکل بومی تحت تأثیر این گزینه قرار نمی‌گیرد.

           repack.packKeptObjects
               اگر روی true تنظیم شود، باعث می‌شود git repack به‌گونه‌ای عمل کند
               که گویی --pack-kept-objects ارسال شده است. برای جزئیات به git-
               repack(1) مراجعه کنید. در حالت عادی پیش‌فرض false است، اما اگر
               یک نمایه بیت‌مپ در حال نوشته شدن باشد (چه از طریق
               --write-bitmap-index یا repack.writeBitmaps)، پیش‌فرض true خواهد
               بود.

           repack.useDeltaIslands
               اگر روی true تنظیم شود، باعث می‌شود git repack به‌گونه‌ای عمل کند
               که گویی --delta-islands ارسال شده است. مقدار پیش‌فرض false است.

           repack.writeBitmaps
               هنگامی که true باشد، گیت هنگام بسته‌بندی تمام اشیاء روی دیسک
               (مثلاً زمانی که git repack -a اجرا می‌شود)، یک نمایه بیت‌مپ
               می‌نویسد. این نمایه می‌تواند مرحله "شمارش اشیاء" در بسته‌های بعدی
               ایجادشده برای cloneها و fetchها را سرعت بخشد، به بهای مقداری
               فضای دیسک و زمان اضافی صرف‌شده در بسته‌بندی مجدد اولیه. اگر چندین
               packfile ایجاد شوند، این گزینه هیچ اثری ندارد. در مخازن bare
               پیش‌فرض true و در غیر این صورت false است.

           repack.updateServerInfo
               اگر روی false تنظیم شود، git-repack(1) دستور git-update-server-
               info(1) را اجرا نخواهد کرد. مقدار پیش‌فرض true است. در صورت true
               بودن، می‌تواند توسط گزینه -n در git-repack(1) بازنویسی شود.

           repack.cruftWindow, repack.cruftWindowMemory, repack.cruftDepth,
           repack.cruftThreads
               پارامترهای مورد استفاده توسط git-pack-objects(1) هنگام تولید یک
               بسته زائدات (cruft pack) در صورتی که پارامترهای مربوطه در خط
               فرمان داده نشده باشند. برای مقادیر پیش‌فرض و معانی آن‌ها، به
               متغیرهای پیکربندی با نام مشابه pack.* مراجعه کنید.

           repack.midxMustContainCruft
               هنگامی که روی true تنظیم شود، git-repack(1) هنگامی که با
               --write-midx فراخوانی می‌شود، بسته‌(های) cruft را در صورت وجود
               بدون قید و شرط در نمایه چندبسته‌ای (MIDX) می‌گنجاند. هنگامی که
               false باشد، بسته‌های cruft تنها در صورت لزوم در MIDX گنجانده
               می‌شوند (مثلاً به این دلیل که ممکن است برای تشکیل یک بستار
               دسترسی‌پذیری با بیت‌مپ‌های MIDX مورد نیاز باشند). مقدار پیش‌فرض
               true است.

           repack.midxSplitFactor
               ضریب مورد استفاده در شرط ادغام هندسی هنگام فشرده‌سازی لایه‌های
               افزایشی MIDX در حین اجرای git repack زمانی که با گزینه
               --write-midx=incremental فراخوانی می‌شود.

               لایه‌های مجاور زمانی ادغام می‌شوند که تعداد اشیاء انباشته‌شده لایه
               جدیدتر از 1/<N> تعداد اشیاء لایه عمیق‌تر بعدی فراتر رود. باید
               حداقل 2 باشد. مقدار پیش‌فرض 2 است.

           repack.midxNewLayerThreshold
               حداقل تعداد بسته‌ها در لایه رأس MIDX پیش از آنکه آن بسته‌ها به
               عنوان نامزد برای بسته‌بندی مجدد هندسی در طول git repack
               --write-midx=incremental در نظر گرفته شوند.

               هنگامی که لایه رأس بسته‌های کمتری از این آستانه داشته باشد، آن
               بسته‌ها به‌طور کامل از بسته‌بندی مجدد هندسی کنار گذاشته شده و
               بنابراین دست‌نخورده باقی می‌مانند. باید حداقل 1 باشد. مقدار
               پیش‌فرض 8 است.

           rerere.autoUpdate
               هنگامی که روی true تنظیم شود، git-rerere پس از حل تمیز تعارض‌ها
               با استفاده از راه‌حل‌های از پیش ثبت‌شده، ایندکس را با محتویات حاصل
               به‌روزرسانی می‌کند. مقدار پیش‌فرض false است.

           rerere.enabled
               فعال‌سازی ثبت تعارض‌های حل‌شده، تا در صورت مواجهه مجدد با قطعات
               تعارض (conflict hunks) یکسان، بتوان آن‌ها را به‌طور خودکار حل
               کرد. به‌طور پیش‌فرض، git-rerere(1) در صورتی که پوشه rr-cache در
               زیر $GIT_DIR وجود داشته باشد فعال است، مثلاً اگر قبلاً از
               "rerere" در مخزن استفاده شده باشد.

           revert.reference
               تنظیم این متغیر روی true باعث می‌شود git revert به‌گونه‌ای رفتار
               کند که گویی گزینه --reference داده شده است.

           safe.bareRepository
               مشخص می‌کند که گیت با کدام مخازن bare کار خواهد کرد. مقادیری که
               در حال حاضر پشتیبانی می‌شوند عبارتند از:

               •   all: گیت با تمام مخازن bare کار می‌کند. این مقدار در Git 2.x
                   پیش‌فرض است.

               •   explicit: گیت فقط با مخازن bare کار می‌کند که از طریق گزینه
                   سطح بالای خط فرمان --git-dir یا متغیر محیطی GIT_DIR مشخص
                   شده‌اند (به git(1) مراجعه کنید). این مقدار در Git 3.0 پیش‌فرض
                   خواهد بود.

               اگر در گردش کار خود از مخازن bare استفاده نمی‌کنید، ممکن است
               مفید باشد که safe.bareRepository را در پیکربندی سراسری (global)
               خود روی explicit تنظیم کنید. این کار شما را در برابر حملاتی که
               شامل کلون کردن مخزنی حاوی یک مخزن bare و اجرای یک دستور Git در
               آن پوشه است، محافظت می‌کند.

               اگر به‌طور منظم از مخازن bare استفاده می‌کنید و می‌خواهید رفتار
               فعلی را پس از ارتقا به Git 3.0 حفظ کنید، safe.bareRepository را
               در پیکربندی سراسری یا سیستمی خود روی all تنظیم کنید.

               این تنظیم پیکربندی فقط در پیکربندی محافظت‌شده رعایت می‌شود (به
               بخش موسوم به “SCOPES” مراجعه کنید). این امر مانع از دستکاری این
               مقدار توسط مخازن غیرقابل اعتماد می‌شود.

           safe.directory
               این مدخل‌های پیکربندی، پوشه‌های تحت ردیابی گیت را مشخص می‌کنند که
               حتی در صورت تعلق به شخصی غیر از کاربر فعلی، امن در نظر گرفته
               می‌شوند. به‌طور پیش‌فرض، گیت حتی از تجزیه (parse) پیکربندی گیت
               مخزنی که متعلق به شخص دیگری است امتناع می‌کند، چه رسد به اجرای
               قلاب‌های (hooks) آن، و این تنظیم پیکربندی به کاربران اجازه می‌دهد
               استثناها را مشخص کنند، مثلاً برای مخازنی که عمداً به اشتراک
               گذاشته شده‌اند (گزینه --shared در git-init(1) را ببینید).

               این یک تنظیم چندمقداری است، یعنی می‌توانید بیش از یک پوشه را از
               طریق git config --add اضافه کنید. برای بازنشانی فهرست پوشه‌های
               امن (مثلاً برای بازنویسی هر پوشه‌ای از این دست که در پیکربندی
               سیستم مشخص شده است)، یک مدخل safe.directory با مقدار خالی اضافه
               کنید.

               این تنظیم پیکربندی فقط در پیکربندی محافظت‌شده رعایت می‌شود (به
               بخش موسوم به “SCOPES” مراجعه کنید). این امر مانع از دستکاری این
               مقدار توسط مخازن غیرقابل اعتماد می‌شود.

               مقدار این تنظیم درون‌یابی (interpolate) می‌شود، یعنی ~/<path> به
               یک مسیر نسبی نسبت به پوشه خانگی (home) گسترش می‌یابد و
               %(prefix)/<path> به یک مسیر نسبی نسبت به پیشوند (زمان اجرا) گیت
               گسترش می‌یابد.

               برای انصراف کامل از این بررسی امنیتی، safe.directory را روی
               رشته * تنظیم کنید. این کار اجازه می‌دهد با تمام مخازن به‌گونه‌ای
               رفتار شود که گویی پوشه آن‌ها در فهرست safe.directory آمده است.
               اگر safe.directory=* در پیکربندی سیستم تنظیم شده باشد و بخواهید
               این محافظت را مجدداً فعال کنید، فهرست خود را با یک مقدار خالی
               پیش از برشمردن مخازنی که امن می‌دانید مقداردهی اولیه کنید. ارائه
               یک پوشه که /* به انتهای آن افزوده شده است، اجازه دسترسی به تمام
               مخازن زیر آن پوشه مشخص‌شده را می‌دهد.

               همان‌طور که توضیح داده شد، گیت به‌طور پیش‌فرض تنها به شما اجازه
               می‌دهد به مخازنی دسترسی داشته باشید که متعلق به خودتان هستند،
               یعنی کاربری که گیت را اجرا می‌کند. با این حال، هنگامی که گیت به
               عنوان root در یک پلتفرم غیر ویندوزی که sudo را ارائه می‌دهد اجرا
               می‌شود، متغیر محیطی SUDO_UID را که sudo ایجاد می‌کند بررسی کرده و
               علاوه بر شناسه root، دسترسی به uid ثبت‌شده به عنوان مقدار آن را
               نیز مجاز می‌داند. این امر برای تسهیل انجام توالی معمول "make &&
               sudo make install" در طول نصب است. یک فرآیند گیت که تحت sudo
               اجرا می‌شود، در قالب root کار می‌کند اما دستور sudo متغیر محیطی
               را صادر (export) می‌کند تا ثبت کند کاربر اصلی چه شناسه‌ای داشته
               است. اگر این مورد نظر شما نیست و می‌خواهید گیت در عوض فقط به
               مخازنی که متعلق به root هستند اعتماد کند، می‌توانید متغیر
               SUDO_UID را پیش از فراخوانی گیت از محیط root حذف کنید.

           sendemail.identity
               یک هویت (identity) پیکربندی. هنگامی که ارائه شود، باعث می‌شود
               مقادیر موجود در زیربخش sendemail.<identity> بر مقادیر موجود در
               بخش sendemail اولویت پیدا کنند. هویت پیش‌فرض مقدار
               sendemail.identity است.

           sendemail.smtpEncryption
               برای توضیحات به git-send-email(1) مراجعه کنید. توجه داشته باشید
               که این تنظیم مشمول سازوکار identity نیست.

           sendemail.smtpSSLCertPath
               مسیر ca-certificates (یا یک پوشه یا یک فایل تکی). برای غیرفعال
               کردن اعتبارسنجی گواهی، آن را روی یک رشته خالی تنظیم کنید.

           sendemail.smtpSSLClientCert
               مسیر فایل گواهی کلاینت که در صورت درخواست سرور ارائه می‌شود. این
               گزینه زمانی که سرور برای اعتبارسنجی گواهی‌های کلاینت پیکربندی
               شده باشد الزامی است. اگر کلید خصوصی مربوطه در فایل گنجانده نشده
               باشد، باید با استفاده از sendemail.smtpSSLClientKey یا گزینه
               --smtp-ssl-client-key فراهم شود.

           sendemail.smtpSSLClientKey
               مسیر فایل کلید خصوصی کلاینت که با گواهی کلاینت مطابقت دارد.
               برای اجتناب از پیکربندی نادرست، این پیکربندی باید همراه با
               sendemail.smtpSSLClientCert یا گزینه --smtp-ssl-client-cert
               استفاده شود. اگر کلید کلاینت در گواهی کلاینت گنجانده شده باشد،
               انتخاب کلید خصوصی به فرمت گواهی بستگی دارد. برای جزئیات بیشتر
               به https://metacpan.org/pod/IO::Socket::SSL مراجعه کنید.

           sendemail.<identity>.*
               نسخه‌های مختص هویت از پارامترهای sendemail.* که در زیر آمده‌اند،
               که در صورت انتخاب این هویت چه از طریق خط فرمان یا
               sendemail.identity، بر آن‌ها اولویت دارند.

           sendemail.multiEdit
               اگر true باشد (پیش‌فرض)، یک نمونه ویرایشگر تکی برای ویرایش
               فایل‌هایی که باید ویرایش کنید اجرا خواهد شد (وصله‌ها زمانی که
               --annotate استفاده شود، و خلاصه زمانی که --compose استفاده
               شود). اگر false باشد، فایل‌ها یکی پس از دیگری ویرایش می‌شوند و هر
               بار یک ویرایشگر جدید اجرا می‌شود.

           sendemail.confirm
               پیش‌فرض برای تأیید گرفتن پیش از ارسال را تنظیم می‌کند. باید یکی
               از موارد always، never، cc، compose یا auto باشد. برای مفهوم
               این مقادیر، به --confirm در مستندات git-send-email(1) مراجعه
               کنید.

           sendemail.mailmap
               اگر true باشد، باعث می‌شود git-send-email(1) فرض را بر --mailmap
               بگذارد، در غیر این صورت --no-mailmap فرض می‌شود. به‌طور پیش‌فرض
               False است.

           sendemail.mailmap.file
               مکان یک فایل افزایشی mailmap مختص git-send-email(1).  ابتدا
               mailmap پیش‌فرض و mailmap.file بارگذاری می‌شوند. بنابراین،
               مدخل‌های موجود در این فایل بر مدخل‌های مکان‌های پیش‌فرض mailmap
               اولویت دارند. به gitmailmap(5) مراجعه کنید.

           sendemail.mailmap.blob
               مشابه sendemail.mailmap.file، اما مقدار را به عنوان یک مرجع به
               یک blob در مخزن در نظر می‌گیرد. مدخل‌های موجود در
               sendemail.mailmap.file بر مدخل‌های اینجا اولویت دارند. به
               gitmailmap(5) مراجعه کنید.

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

           sendemail.aliasFileType
               قالب فایل(های) مشخص‌شده در sendemail.aliasesFile. باید یکی از
               موارد mutt، mailrc، pine، elm، gnus یا sendmail باشد.

               شکل فایل نام مستعار در هر قالب را می‌توان در مستندات برنامه
               ایمیلی با همان نام یافت. تفاوت‌ها و محدودیت‌ها نسبت به قالب‌های
               استاندارد در زیر شرح داده شده‌اند:

               sendmail

                   •   نام‌های مستعار نقل‌قول‌شده و نشانی‌های نقل‌قول‌شده پشتیبانی
                       نمی‌شوند: خطوط حاوی نماد " نادیده گرفته می‌شوند.

                   •   تغییر مسیر به یک فایل (/path/name) یا لوله (|command)
                       پشتیبانی نمی‌شود.

                   •   شامل کردن فایل (:include: /path/name) پشتیبانی نمی‌شود.

                   •   برای هرگونه ساختار صریحاً پشتیبانی‌نشده و هر خط دیگری که
                       توسط تجزیه‌کننده شناخته نشود، هشدارهایی در خروجی خطای
                       استاندارد چاپ می‌شوند.

           sendemail.annotate, sendemail.bcc, sendemail.cc, sendemail.ccCmd,
           sendemail.chainReplyTo, sendemail.envelopeSender, sendemail.from,
           sendemail.headerCmd, sendemail.signedOffByCc, sendemail.smtpPass,
           sendemail.suppressCc, sendemail.suppressFrom, sendemail.to,
           sendemail.toCmd, sendemail.smtpDomain, sendemail.smtpServer,
           sendemail.smtpServerPort, sendemail.smtpServerOption,
           sendemail.smtpUser, sendemail.imapSentFolder,
           sendemail.useImapOnly, sendemail.thread,
           sendemail.transferEncoding, sendemail.validate, sendemail.xmailer
               این متغیرهای پیکربندی همگی مقداری پیش‌فرض برای گزینه‌های خط فرمان
               git-send-email(1) ارائه می‌دهند. برای جزئیات به مستندات آن
               مراجعه کنید.

           sendemail.outlookidfix
               اگر true باشد، باعث می‌شود git-send-email(1) گزینه
               --outlook-id-fix را فرض کند، و اگر false باشد فرض را بر
               --no-outlook-id-fix می‌گذارد. در صورت مشخص نشدن، به همان شیوه‌ای
               عمل می‌کند که گویی --outlook-id-fix مشخص نشده است.

           sendemail.signedOffCc (منسوخ‌شده)
               نام مستعار منسوخ‌شده برای sendemail.signedOffByCc.

           sendemail.smtpBatchSize
               تعداد پیام‌هایی که در هر اتصال ارسال می‌شوند، که پس از آن ورود
               مجدد رخ خواهد داد. اگر مقدار 0 یا تعریف‌نشده باشد، تمام پیام‌ها
               در یک اتصال ارسال می‌شوند. همچنین گزینه --batch-size در git-
               send-email(1) را ببینید.

           sendemail.smtpReloginDelay
               تعداد ثانیه‌های انتظار پیش از اتصال مجدد به سرور smtp. همچنین
               گزینه --relogin-delay در git-send-email(1) را ببینید.

           sendemail.forbidSendmailVariables
               برای اجتناب از خطاهای رایج پیکربندی نادرست، git-send-email(1)
               در صورت وجود هرگونه گزینه پیکربندی برای sendmail همراه با یک
               هشدار متوقف خواهد شد. این متغیر را برای دور زدن این بررسی تنظیم
               کنید.

           sequence.editor
               ویرایشگر متنی مورد استفاده توسط git rebase -i برای ویرایش فایل
               دستورالعمل بازپایه‌ریزی. این مقدار قرار است هنگام استفاده توسط
               پوسته (shell) تفسیر شود. می‌تواند توسط متغیر محیطی
               GIT_SEQUENCE_EDITOR بازنویسی شود. در صورت پیکربندی نشدن،
               ویرایشگر پیش‌فرض پیام کامیت به جای آن استفاده می‌شود.

           showBranch.default
               مجموعه پیش‌فرض شاخه‌ها برای git-show-branch(1).  به git-show-
               branch(1) مراجعه کنید.

           sideband.allowControlCharacters
               به‌طور پیش‌فرض، نویسه‌های کنترلی که از طریق sideband تحویل داده
               می‌شوند، به استثنای توالی‌های رنگی ANSI ماسک (پوشانده) می‌شوند.
               این کار از ارسال توالی‌های فرار بالقوه ناخواسته ANSI به ترمینال
               جلوگیری می‌کند. از این تنظیم پیکربندی برای بازنویسی این رفتار
               استفاده کنید (مقدار می‌تواند فهرستی جداشده با کاما از
               کلیدواژه‌های زیر باشد):

               color
                   توالی‌های رنگی ANSI، خطوط جدید (line feeds) و تب‌های افقی
                   مجاز باشند، اما سایر نویسه‌های کنترلی ماسک شوند. این مقدار
                   پیش‌فرض است.

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

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

               false
                   تمام نویسه‌های کنترلی غیر از خطوط جدید و تب‌های افقی ماسک
                   شوند.

               true
                   ارسال تمام نویسه‌های کنترلی به ترمینال مجاز باشد.

           sideband.<url>.*
               اعمال گزینه sideband.* به صورت انتخابی روی نشانی‌های اینترنتی
               (URLs) خاص. همان منطق تطبیق URL مانند تنظیمات http.<url>.*
               اعمال می‌شود.

           sparse.expectFilesOutsideOfPatterns
               معمولاً در دریافت‌های پراکنده (sparse checkouts)، فایل‌هایی که با
               هیچ الگوی پراکندگی مطابقت ندارند با یک بیت SKIP_WORKTREE در
               ایندکس علامت‌گذاری شده و در درخت کاری وجود ندارند. بر این اساس،
               گیت معمولاً بررسی می‌کند که آیا فایل‌های دارای بیت SKIP_WORKTREE
               بر خلاف انتظار در درخت کاری وجود دارند یا خیر. اگر گیت موردی
               پیدا کند، آن مسیرها را با پاک کردن بیت‌های مربوطه SKIP_WORKTREE
               به عنوان موجود علامت‌گذاری می‌کند. این گزینه می‌تواند استفاده شود
               تا به گیت اعلام کند چنین فایل‌های موجود با وجود رد شدن
               (present-despite-skipped) مورد انتظار هستند و بررسی برای آن‌ها
               متوقف شود.

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

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

               صرف‌نظر از این تنظیم، گیت فایل‌های موجود با وجود رد شدن را بررسی
               نمی‌کند مگر اینکه sparse checkout فعال باشد، بنابراین این گزینه
               پیکربندی هیچ اثری ندارد مگر اینکه core.sparseCheckout برابر با
               true باشد.

           splitIndex.maxPercentChange
               هنگامی که قابلیت ایندکس تفکیک‌شده (split index) استفاده می‌شود،
               این متغیر درصد ورودی‌هایی را که ایندکس تفکیک‌شده می‌تواند در
               مقایسه با تعداد کل ورودی‌ها در هر دو ایندکس تفکیک‌شده و ایندکس
               مشترک (shared index) پیش از نوشته شدن یک ایندکس مشترک جدید
               داشته باشد، مشخص می‌کند. مقدار باید بین 0 و 100 باشد. اگر مقدار
               0 باشد، همیشه یک ایندکس مشترک جدید نوشته می‌شود؛ اگر 100 باشد،
               هرگز یک ایندکس مشترک جدید نوشته نمی‌شود. به‌طور پیش‌فرض، مقدار 20
               است، بنابراین اگر تعداد مدخل‌ها در ایندکس تفکیک‌شده بیش از 20
               درصد کل تعداد مدخل‌ها باشد، یک ایندکس مشترک جدید نوشته می‌شود. به
               git-update-index(1) مراجعه کنید.

           splitIndex.sharedIndexExpire
               هنگامی که قابلیت ایندکس تفکیک‌شده (split index) استفاده می‌شود،
               فایل‌های ایندکس مشترکی که از زمان مشخص‌شده توسط این متغیر تغییر
               نیافته‌اند، هنگام ایجاد یک فایل ایندکس مشترک جدید حذف خواهند شد.
               مقدار "now" تمام مدخل‌ها را بلافاصله منقضی می‌کند و "never" انقضا
               را به‌طور کامل متوقف می‌سازد. مقدار پیش‌فرض "2.weeks.ago" است.
               توجه داشته باشید که یک فایل ایندکس مشترک هر بار که یک فایل
               split-index جدید بر اساس آن ایجاد شده یا از آن خوانده شود (به
               منظور انقضا) تغییریافته در نظر گرفته می‌شود. به git-update-
               index(1) مراجعه کنید.

           ssh.variant
               به‌طور پیش‌فرض، گیت آرگومان‌های خط فرمان مورد استفاده را بر اساس
               نام پایه (basename) دستور SSH پیکربندی‌شده (پیکربندی‌شده با
               استفاده از متغیر محیطی GIT_SSH یا GIT_SSH_COMMAND یا تنظیم
               پیکربندی core.sshCommand) تعیین می‌کند. اگر نام پایه ناشناخته
               باشد، گیت با فراخوانی دستور SSH پیکربندی‌شده ابتدا با گزینه -G
               (چاپ پیکربندی) تلاش می‌کند پشتیبانی از گزینه‌های OpenSSH را تشخیص
               دهد و سپس از گزینه‌های OpenSSH (در صورت موفقیت‌آمیز بودن) یا بدون
               هیچ گزینه‌ای به جز میزبان و دستور ریموت (در صورت شکست) استفاده
               خواهد کرد.

               متغیر پیکربندی ssh.variant می‌تواند برای بازنویسی این تشخیص
               تنظیم شود. مقادیر معتبر عبارتند از: ssh (برای استفاده از
               گزینه‌های OpenSSH)، plink، putty، tortoiseplink، simple (بدون
               هیچ گزینه‌ای به جز میزبان و دستور ریموت). تشخیص خودکار پیش‌فرض را
               می‌توان صریحاً با استفاده از مقدار auto درخواست کرد. هر مقدار
               دیگری به عنوان ssh در نظر گرفته می‌شود. این تنظیم می‌تواند از
               طریق متغیر محیطی GIT_SSH_VARIANT نیز بازنویسی شود.

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

               •   ssh - [-p port] [-4] [-6] [-o option] [username@]host
                   command

               •   simple - [username@]host command

               •   plink یا putty - [-P port] [-4] [-6] [username@]host
                   command

               •   tortoiseplink - [-P port] [-4] [-6] -batch [username@]host
                   command

               به جز گونه simple، احتمال دارد که با افزوده شدن قابلیت‌های جدید
               به گیت، پارامترهای خط فرمان تغییر کنند.

           stash.index
               اگر این متغیر روی true تنظیم شود، git stash apply و git stash
               pop به‌گونه‌ای رفتار خواهند کرد که گویی --index داده شده است.
               مقدار پیش‌فرض false است. به توضیحات موجود در git-stash(1) مراجعه
               کنید.

               این امر همچنین بر فراخوانی‌های git-stash(1) از طریق --autostash
               از دستوراتی مانند git-merge(1)، git-rebase(1) و git-pull(1)
               تأثیر می‌گذارد.

           stash.showIncludeUntracked
               اگر این متغیر روی true تنظیم شود، دستور git stash show فایل‌های
               ردیابی‌نشده مربوط به یک مدخل ذخیره‌گاه (stash entry) را نشان
               خواهد داد. مقدار پیش‌فرض false است. به توضیحات دستور 'show' در
               git-stash(1) مراجعه کنید.

           stash.showPatch
               اگر این متغیر روی true تنظیم شود، دستور git stash show بدون هیچ
               گزینه‌ای مدخل ذخیره‌گاه را در قالب وصله نشان می‌دهد. مقدار پیش‌فرض
               false است. به توضیحات دستور 'show' در git-stash(1) مراجعه کنید.

           stash.showStat
               اگر این متغیر روی true تنظیم شود، دستور git stash show بدون هیچ
               گزینه‌ای یک diffstat از مدخل ذخیره‌گاه را نشان می‌دهد. مقدار
               پیش‌فرض true است. به توضیحات دستور 'show' در git-stash(1) مراجعه
               کنید.

           status.relativePaths
               به‌طور پیش‌فرض، git-status(1) مسیرها را نسبی به پوشه جاری نشان
               می‌دهد. تنظیم این متغیر روی false مسیرها را نسبی به ریشه مخزن
               نشان می‌دهد (این رفتار پیش‌فرض گیت پیش از نسخه 1.5.4 بود).

           status.short
               روی true تنظیم کنید تا --short به‌طور پیش‌فرض در git-status(1)
               فعال شود. گزینه --no-short بر این متغیر اولویت دارد.

           status.branch
               روی true تنظیم کنید تا --branch به‌طور پیش‌فرض در git-status(1)
               فعال شود. گزینه --no-branch بر این متغیر اولویت دارد.

           status.aheadBehind
               روی true تنظیم کنید تا --ahead-behind و روی false تنظیم کنید تا
               --no-ahead-behind به‌طور پیش‌فرض در git-status(1) برای قالب‌های
               وضعیت غیر پرسلین فعال شوند. مقدار پیش‌فرض true است.

           status.compareBranches
               فهرستی جداشده با فاصله از مشخص‌کننده‌های مقایسه شاخه برای استفاده
               در git-status(1).  در حال حاضر تنها @{upstream} و @{push}
               پشتیبانی می‌شوند. آن‌ها به صورت branch@{upstream} و branch@{push}
               برای شاخه جاری تفسیر می‌شوند.

               در صورت تنظیم نشدن، رفتار پیش‌فرض معادل @{upstream} است، که در
               برابر شاخه ردیابی بالادست (upstream) پیکربندی‌شده مقایسه می‌کند.

               مدخل‌ها به ترتیبی که در پیکربندی ظاهر می‌شوند نمایش داده می‌شوند.
               مدخل‌های تکراری که به همان مرجع حل‌وفصل می‌شوند پس از اولین رخداد
               حذف می‌شوند، بنابراین @{push} @{upstream} @{push} حداکثر دو
               مقایسه را نشان می‌دهد. زمانی که @{upstream} و @{push} به همان
               شاخه ردیابی ریموت منتهی شوند، تنها یک مقایسه نشان داده می‌شود.

               مثال:

                   [status]
                           compareBranches = @{upstream} @{push}

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

           status.displayCommentPrefix
               اگر روی true تنظیم شود، git-status(1) پیشوند یادداشت را پیش از
               هر خط خروجی درج می‌کند (شروع با core.commentChar، یعنی به‌طور
               پیش‌فرض #). این رفتار git-status(1) در Git 1.8.4 و نسخه‌های پیشین
               بود. مقدار پیش‌فرض false است.

           status.renameLimit
               تعداد فایل‌هایی که هنگام انجام تشخیص تغییر نام در git-status(1)
               و git-commit(1) در نظر گرفته می‌شوند. مقدار پیش‌فرض برابر با
               مقدار diff.renameLimit است.

           status.renames
               اینکه آیا و چگونه گیت تغییر نام‌ها را در git-status(1) و git-
               commit(1) تشخیص دهد. اگر روی "false" تنظیم شود، تشخیص تغییر نام
               غیرفعال می‌شود. اگر روی "true" تنظیم شود، تشخیص پایه تغییر نام
               فعال می‌گردد. اگر روی "copies" یا "copy" تنظیم شود، گیت کپی‌ها را
               نیز تشخیص خواهد داد. مقدار پیش‌فرض برابر با مقدار diff.renames
               است.

           status.showStash
               اگر روی true تنظیم شود، git-status(1) تعداد مدخل‌های ذخیره‌شده
               فعلی را نمایش می‌دهد. مقدار پیش‌فرض false است.

           status.showUntrackedFiles
               به‌طور پیش‌فرض، git-status(1) و git-commit(1) فایل‌هایی را که در
               حال حاضر توسط گیت ردیابی نمی‌شوند نشان می‌دهند. پوشه‌هایی که تنها
               حاوی فایل‌های ردیابی‌نشده هستند، تنها با نام پوشه نمایش داده
               می‌شوند. نمایش فایل‌های ردیابی‌نشده به این معنی است که گیت باید
               تابع lstat() را روی تمام فایل‌ها در کل مخزن فراخوانی کند، که
               ممکن است در برخی سیستم‌ها کند باشد. بنابراین، این متغیر نحوه
               نمایش فایل‌های ردیابی‌نشده توسط دستورات را کنترل می‌کند. مقادیر
               ممکن عبارتند از:

               •   no - هیچ فایل ردیابی‌نشده‌ای را نشان ندهد.

               •   normal - فایل‌ها و پوشه‌های ردیابی‌نشده را نشان دهد.

               •   all - همچنین فایل‌های تکی درون پوشه‌های ردیابی‌نشده را نشان
                   دهد.

               اگر این متغیر مشخص نشود، مقدار پیش‌فرض آن normal است. تمام
               نگارش‌های معمول برای مقدار بولی true به عنوان normal و false به
               عنوان no در نظر گرفته می‌شوند. این متغیر می‌تواند با گزینه
               -u|--untracked-files در git-status(1) و git-commit(1) بازنویسی
               شود.

           status.submoduleSummary
               مقدار پیش‌فرض false است. اگر این متغیر روی یک عدد غیر صفر یا
               true (معادل با -1 یا یک عدد نامحدود) تنظیم شود، خلاصه زیرماژول
               فعال شده و خلاصه‌ای از کامیت‌ها برای زیرماژول‌های تغییریافته نشان
               داده خواهد شد (گزینه --summary-limit در git-submodule(1) را
               ببینید). لطفاً توجه داشته باشید که خروجی خلاصه برای تمام
               زیرماژول‌ها زمانی که diff.ignoreSubmodules روی all تنظیم شده
               باشد متوقف می‌شود، یا تنها برای آن زیرماژول‌هایی که
               submodule.<name>.ignore=all باشند. تنها استثنای این قاعده این
               است که status و commit تغییرات مرحله‌بندی‌شده (staged) زیرماژول
               را نشان خواهند داد. برای مشاهده خلاصه برای زیرماژول‌های
               نادیده‌گرفته‌شده نیز می‌توانید از گزینه خط فرمان
               --ignore-submodules=dirty یا دستور git submodule summary
               استفاده کنید، که خروجی مشابهی را نشان می‌دهد اما به این تنظیمات
               توجهی نمی‌کند.

           submodule.<name>.url
               نشانی URL برای یک زیرماژول. این متغیر از طریق git submodule
               init از فایل .gitmodules در پیکربندی گیت کپی می‌شود. کاربر
               می‌تواند URL پیکربندی‌شده را پیش از دریافت زیرماژول از طریق git
               submodule update تغییر دهد. اگر نه submodule.<name>.active و نه
               submodule.active تنظیم نشده باشند، وجود این متغیر به عنوان یک
               راه‌حل جایگزین (fallback) استفاده می‌شود تا نشان دهد آیا زیرماژول
               مورد توجه دستورات گیت هست یا خیر. برای جزئیات به git-
               submodule(1) و gitmodules(5) مراجعه کنید.

           submodule.<name>.update
               روشی که زیرماژول توسط git submodule update به‌روزرسانی می‌شود، که
               تنها دستور تحت تأثیر است و سایر دستورات مانند git checkout
               --recurse-submodules تحت تأثیر قرار نمی‌گیرند. این متغیر به
               دلایل تاریخی وجود دارد، زمانی که git submodule تنها دستور برای
               تعامل با زیرماژول‌ها بود؛ تنظیماتی مانند submodule.active و
               pull.rebase خاص‌تر هستند. این مقدار توسط git submodule init از
               فایل gitmodules(5) پر می‌شود. توضیحات دستور update در git-
               submodule(1) را ببینید.

           submodule.<name>.branch
               نام شاخه راه دور برای یک زیرماژول، که توسط git submodule update
               -emote استفاده می‌شود. این گزینه را برای بازنویسی مقدار یافت‌شده
               در فایل .gitmodules تنظیم کنید. برای جزئیات به git-submodule(1)
               و gitmodules(5) مراجعه کنید.

           submodule.<name>.fetchRecurseSubmodules
               این گزینه می‌تواند برای کنترل دریافت بازگشتی این زیرماژول
               استفاده شود. با استفاده از گزینه خط فرمان
               --[no-]recurse-submodules در «git fetch» و «git pull» می‌توان آن
               را لغو و بازنویسی کرد. این تنظیم، مقداری را که در فایل
               gitmodules(5) قرار دارد بازنویسی می‌کند.

           submodule.<name>.ignore
               مشخص می‌کند تحت چه شرایطی «git status» و خانواده diff یک
               زیرماژول را تغییریافته نشان می‌دهند. وقتی روی «all» تنظیم شود،
               هرگز زیرماژول را تغییریافته در نظر نخواهد گرفت. با این حال
               می‌توان با استفاده از گزینه -rce آن را استیج کرد که در این صورت
               در خروجی status ظاهر خواهد شد. هنگامی که روی «dirty» تنظیم شود،
               تمام تغییرات درخت کاری زیرماژول را نادیده می‌گیرد و تنها
               تفاوت‌های میان HEAD زیرماژول و کامیت ثبت‌شده در پروژه والد را مد
               نظر قرار می‌دهد. مقدار «untracked» علاوه بر این اجازه می‌دهد
               زیرماژول‌هایی که فایل‌های ردیابی‌شدهٔ تغییریافته در درخت کاری خود
               دارند نشان داده شوند. وقتی روی «none» (پیش‌فرض) تنظیم شود،
               زیرماژول‌ها را حتی اگر فایل‌های ردیابی‌نشده در درخت کاری خود داشته
               باشند نیز تغییریافته نشان می‌دهد. این تنظیم هر تنظیمی را که در
               .gitmodules برای این زیرماژول انجام شده باشد بازنویسی می‌کند؛ هر
               دو تنظیم را می‌توان در خط فرمان با استفاده از گزینه
               «-ignore-submodules» بازنویسی کرد. دستورات git submodule تحت
               تأثیر این تنظیم قرار نمی‌گیرند.

           submodule.<name>.active
               مقدار بولی که مشخص می‌کند آیا زیرماژول مورد توجه دستورات گیت هست
               یا خیر. این گزینه پیکربندی بر گزینه پیکربندی submodule.active
               تقدم دارد. برای جزئیات به gitsubmodules(7) مراجعه کنید.

           submodule.<name>.gitdir
               این گزینه مسیر gitdir را برای زیرماژول <name> تنظیم می‌کند. این
               پیکربندی در صورتی رعایت می‌شود که extensions.submodulePathConfig
               فعال باشد، در غیر این صورت هیچ اثری ندارد. هنگام فعال بودن، این
               پیکربندی به تنها منبع حقیقت برای مسیرهای gitdir زیرماژول تبدیل
               می‌شود و در صورت مفقود بودن، گیت خطا صادر می‌کند. برای جزئیات به
               git-config(1) مراجعه کنید.

           submodule.active
               یک فیلد تکرارشونده شامل الگوی مسیر (pathspec) که برای تطبیق با
               مسیر یک زیرماژول استفاده می‌شود تا مشخص کند آیا زیرماژول مورد
               توجه دستورات گیت هست یا خیر. برای جزئیات به gitsubmodules(7)
               مراجعه کنید.

           submodule.recurse
               یک مقدار بولی که مشخص می‌کند آیا دستورات باید گزینه
               -ecurse-submodules را به صورت پیش‌فرض فعال کنند یا خیر. پیش‌فرض
               false است.

               هنگامی که روی true تنظیم شود، می‌توان آن را از طریق گزینه
               -0-recurse-submodules غیرفعال کرد. توجه داشته باشید که برخی از
               دستورات گیت که فاقد این گزینه هستند ممکن است برخی از دستورات
               فوق را که تحت تأثیر submodule.recurse هستند فراخوانی کنند؛ برای
               مثال git remote update دستور git fetch را فراخوانی می‌کند اما
               گزینه -0-recurse-submodules ندارد. برای این دستورات، یک راهکار
               موقت تغییر مقدار پیکربندی با استفاده از git -c
               submodule.recurse=0 است.

               فهرست زیر دستوراتی را نشان می‌دهد که -ecurse-submodules را
               می‌پذیرند و اینکه آیا توسط این تنظیم پشتیبانی می‌شوند یا خیر.

               •   دستورات checkout، fetch، grep، pull، push، read-tree،
                   reset، restore و switch همیشه پشتیبانی می‌شوند.

               •   دستورات clone و ls-files پشتیبانی نمی‌شوند.

               •   دستور branch تنها در صورتی پشتیبانی می‌شود که
                   submodule.propagateBranches فعال باشد.

           submodule.propagateBranches
               [آزمایشی] یک مقدار بولی که پشتیبانی از شاخه‌بندی را هنگام
               استفاده از -ecurse-submodules یا submodule.recurse=true فعال
               می‌کند. فعال کردن این گزینه به برخی دستورات اجازه می‌دهد تا
               -ecurse-submodules را بپذیرند، و برخی دستورات که از قبل
               -ecurse-submodules را می‌پذیرند اکنون شاخه‌ها را نیز در نظر
               خواهند گرفت. پیش‌فرض false است.

           submodule.fetchJobs
               مشخص می‌کند چه تعداد زیرماژول به طور هم‌زمان دریافت/کلون شوند. یک
               عدد صحیح مثبت اجازه می‌دهد تا آن تعداد زیرماژول به صورت موازی
               دریافت شوند. مقدار 0 یک پیش‌فرض معقول تعیین می‌کند. در صورت عدم
               تنظیم، به طور پیش‌فرض 1 است.

           submodule.alternateLocation
               مشخص می‌کند زیرماژول‌ها هنگام کلون شدن چگونه alternates (منابع
               جایگزین اشیاء) را به دست می‌آورند. مقادیر مجاز عبارتند از no و
               superproject. به طور پیش‌فرض no در نظر گرفته می‌شود، که هیچ
               ارجاعی اضافه نمی‌کند. هنگامی که مقدار روی superproject تنظیم
               شود، زیرماژولی که قرار است کلون شود مکان alternates خود را نسبت
               به alternate پروژه والد محاسبه می‌کند.

           submodule.alternateErrorStrategy
               مشخص می‌کند با خطاهای مربوط به alternates برای یک زیرماژول که از
               طریق submodule.alternateLocation محاسبه شده است چگونه برخورد
               شود. مقادیر مجاز عبارتند از ignore، info و die. مقدار پیش‌فرض
               die است. توجه داشته باشید که اگر روی ignore یا info تنظیم شود،
               و در alternate محاسبه‌شده خطایی رخ دهد، عملیات کلون طوری ادامه
               می‌یابد که گویی هیچ alternateای مشخص نشده است.

           tag.forceSignAnnotated
               یک مقدار بولی برای مشخص کردن اینکه آیا برچسب‌های حاشیه‌نویسی‌شده
               (annotated tags) ایجادشده باید دارای امضای GPG باشند یا خیر.
               اگر -nnotate در خط فرمان مشخص شده باشد، بر این گزینه تقدم دارد.

           tag.sort
               این متغیر ترتیب مرتب‌سازی برچسب‌ها را هنگام نمایش توسط git-tag(1)
               کنترل می‌کند. بدون ارائه گزینه -rt=<value>، مقدار این متغیر به
               عنوان پیش‌فرض استفاده خواهد شد.

           tag.gpgSign
               یک مقدار بولی برای مشخص کردن اینکه آیا همه برچسب‌ها باید با GPG
               امضا شوند یا خیر. استفاده از این گزینه هنگام اجرا در یک اسکریپت
               خودکار می‌تواند منجر به امضا شدن تعداد زیادی برچسب شود. بنابراین
               استفاده از یک agent مناسب است تا از تایپ چندباره عبارت عبور GPG
               خودداری شود. توجه داشته باشید که این گزینه بر رفتار امضای برچسب
               که توسط گزینه‌های -u <keyid> یا - فعال شده است تأثیری ندارد.

           tar.umask
               این متغیر می‌تواند برای محدود کردن بیت‌های مجوز ورودی‌های آرشیو
               tar استفاده شود. مقدار پیش‌فرض 0002 است که بیت نوشتن همگانی
               (world write bit) را خاموش می‌کند. مقدار ویژه «user» نشان می‌دهد
               که umask کاربر آرشیوکننده در عوض استفاده خواهد شد. به umask(2)
               و git-archive(1) مراجعه کنید.

           تنظیمات پیکربندی Trace2 فقط از فایل‌های پیکربندی سیستم و سراسری
           (global) خوانده می‌شوند؛ فایل‌های پیکربندی محلی مخزن و درخت کاری
           (worktree) و آرگومان‌های خط فرمان -c نادیده گرفته می‌شوند.

           trace2.normalTarget
               این متغیر مقصد هدف عادی (normal target) را کنترل می‌کند. ممکن
               است توسط متغیر محیطی GIT_TRACE2 بازنویسی شود. جدول زیر مقادیر
               ممکن را نشان می‌دهد.

           trace2.perfTarget
               این متغیر مقصد هدف کارایی (performance target) را کنترل می‌کند.
               ممکن است توسط متغیر محیطی GIT_TRACE2_PERF بازنویسی شود. جدول
               زیر مقادیر ممکن را نشان می‌دهد.

           trace2.eventTarget
               این متغیر مقصد هدف رویداد (event target) را کنترل می‌کند. ممکن
               است توسط متغیر محیطی GIT_TRACE2_EVENT بازنویسی شود. جدول زیر
               مقادیر ممکن را نشان می‌دهد.

               •   0 یا false - هدف را غیرفعال می‌کند.

               •   1 یا true - در STDERR می‌نویسد.

               •   [2-9] - در توصیف‌گر فایل (file descriptor) که از قبل باز شده
                   می‌نویسد.

               •   <absolute-pathname> - در حالت الحاق (append mode) درون فایل
                   می‌نویسد. اگر هدف از قبل موجود باشد و یک دایرکتوری باشد،
                   ردگیری‌ها در فایل‌هایی (یک فایل برای هر فرایند) زیر دایرکتوری
                   داده‌شده نوشته می‌شوند.

               •   af_unix:[<socket-type>:]<absolute-pathname> - در یک Unix
                   Domain Socket می‌نویسد (روی پلتفرم‌هایی که از آن پشتیبانی
                   می‌کنند). نوع سوکت می‌تواند stream یا dgram باشد؛ در صورت
                   حذف، گیت هر دو را امتحان خواهد کرد.

           trace2.normalBrief
               بولی. هنگامی که true باشد، فیلدهای time، filename و line از
               خروجی عادی حذف می‌شوند. ممکن است توسط متغیر محیطی
               GIT_TRACE2_BRIEF بازنویسی شود. پیش‌فرض false است.

           trace2.perfBrief
               بولی. هنگامی که true باشد، فیلدهای time، filename و line از
               خروجی PERF حذف می‌شوند. ممکن است توسط متغیر محیطی
               GIT_TRACE2_PERF_BRIEF بازنویسی شود. پیش‌فرض false است.

           trace2.eventBrief
               بولی. هنگامی که true باشد، فیلدهای time، filename و line از
               خروجی رویداد (event) حذف می‌شوند. ممکن است توسط متغیر محیطی
               GIT_TRACE2_EVENT_BRIEF بازنویسی شود. پیش‌فرض false است.

           trace2.eventNesting
               عدد صحیح. عمق مورد نظر ناحیه‌های تودرتو را در خروجی رویداد مشخص
               می‌کند. ناحیه‌های عمیق‌تر از این مقدار حذف خواهند شد. ممکن است
               توسط متغیر محیطی GIT_TRACE2_EVENT_NESTING بازنویسی شود. پیش‌فرض
               2 است.

           trace2.configParams
               فهرستی جداشده با کاما از الگوهای تنظیمات پیکربندی «مهم» که باید
               در خروجی trace2 ثبت شوند. برای مثال، core.*,remote.*.url باعث
               می‌شود خروجی trace2 حاوی رویدادهایی باشد که هر ریموت پیکربندی‌شده
               را فهرست می‌کند. ممکن است توسط متغیر محیطی
               GIT_TRACE2_CONFIG_PARAMS بازنویسی شود. به طور پیش‌فرض تنظیم نشده
               است.

           trace2.envVars
               فهرستی جداشده با کاما از متغیرهای محیطی «مهم» که باید در خروجی
               trace2 ثبت شوند. برای مثال، GIT_HTTP_USER_AGENT,GIT_CONFIG باعث
               می‌شود خروجی trace2 حاوی رویدادهایی باشد که بازنویسی‌های عامل
               کاربر HTTP و مکان فایل پیکربندی گیت را فهرست می‌کند (به فرض
               اینکه تنظیمی صورت گرفته باشد). ممکن است توسط متغیر محیطی
               GIT_TRACE2_ENV_VARS بازنویسی شود. به طور پیش‌فرض تنظیم نشده است.

           trace2.destinationDebug
               بولی. هنگامی که true باشد، گیت در صورتی که مقصد هدف ردگیری
               نتواند برای نوشتن باز شود پیام‌های خطا را چاپ خواهد کرد. به طور
               پیش‌فرض، این خطاها نادیده گرفته می‌شوند و ردگیری بدون سر و صدا
               غیرفعال می‌شود. ممکن است توسط متغیر محیطی GIT_TRACE2_DST_DEBUG
               بازنویسی شود.

           trace2.maxFiles
               عدد صحیح. هنگام نوشتن فایل‌های ردگیری در یک دایرکتوری هدف، اگر
               انجام این کار از این تعداد فایل فراتر رود، ردگیری‌های بیشتری
               ننویسید. در عوض، یک فایل نشانگر (sentinel file) بنویسید که از
               ادامه ردگیری در این دایرکتوری جلوگیری کند. پیش‌فرض 0 است که این
               بررسی را غیرفعال می‌کند.

           trailer.separators
               این گزینه مشخص می‌کند چه نویسه‌هایی به عنوان جداکننده پی‌نوشت
               (trailer separator) شناخته شوند. به طور پیش‌فرض تنها : به عنوان
               جداکننده پی‌نوشت شناخته می‌شود، با این استثنا که = برای سازگاری
               با سایر دستورات گیت همیشه در خط فرمان پذیرفته می‌شود.

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

               برای مثال، اگر مقدار این گزینه %=$ باشد، آنگاه تنها خطوطی که از
               قالب <key><sep><value> استفاده می‌کنند که در آن <sep> شامل %، =
               یا $ و سپس فاصله باشد، به عنوان پی‌نوشت در نظر گرفته خواهند شد.
               و % جداکننده پیش‌فرض مورد استفاده خواهد بود، بنابراین به طور
               پیش‌فرض پی‌نوشت‌ها به این صورت ظاهر می‌شوند: <key>% <value> (یک
               علامت درصد و یک فاصله بین کلید و مقدار قرار خواهد گرفت).

           trailer.where
               این گزینه مشخص می‌کند پی‌نوشت جدید در کجا اضافه خواهد شد.

               این مقدار می‌تواند end (که پیش‌فرض است)، start، after یا before
               باشد.

               اگر end باشد، هر پی‌نوشت جدید در انتهای پی‌نوشت‌های موجود ظاهر
               می‌شود.

               اگر start باشد، هر پی‌نوشت جدید به جای انتها در ابتدای پی‌نوشت‌های
               موجود ظاهر خواهد شد.

               اگر after باشد، هر پی‌نوشت جدید دقیقاً پس از آخرین پی‌نوشت با همان
               <key> ظاهر می‌شود.

               اگر before باشد، هر پی‌نوشت جدید دقیقاً قبل از اولین پی‌نوشت با
               همان <key> ظاهر می‌شود.

           trailer.ifexists
               این گزینه امکان انتخاب عملی را فراهم می‌کند که در صورت وجود
               حداقل یک پی‌نوشت با همان <key> در ورودی انجام خواهد شد.

               مقادیر معتبر برای این گزینه عبارتند از: addIfDifferentNeighbor
               (این مقدار پیش‌فرض است)، addIfDifferent، add، replace یا
               doNothing.

               با addIfDifferentNeighbor، یک پی‌نوشت جدید تنها در صورتی اضافه
               می‌شود که هیچ پی‌نوشتی با همان جفت (<key>, <value>) در خط بالاتر
               یا پایین‌تر از مکانی که پی‌نوشت جدید اضافه می‌شود نباشد.

               با addIfDifferent، یک پی‌نوشت جدید تنها در صورتی اضافه خواهد شد
               که هیچ پی‌نوشتی با همان جفت (<key>, <value>) از قبل در ورودی
               وجود نداشته باشد.

               با add، یک پی‌نوشت جدید اضافه خواهد شد، حتی اگر پی‌نوشت‌هایی با
               همان جفت (<key>, <value>) از قبل در ورودی وجود داشته باشند.

               با replace، پی‌نوشت موجود با همان <key> حذف شده و پی‌نوشت جدید
               اضافه خواهد شد. پی‌نوشت حذف‌شده نزدیک‌ترین پی‌نوشت (با همان <key>)
               به مکانی خواهد بود که پی‌نوشت جدید اضافه می‌شود.

               با doNothing، هیچ کاری انجام نخواهد شد؛ یعنی اگر پی‌نوشتی با
               همان <key> در ورودی وجود داشته باشد هیچ پی‌نوشت جدیدی اضافه
               نمی‌شود.

           trailer.ifmissing
               این گزینه امکان انتخاب عملی را فراهم می‌کند که در صورت عدم وجود
               هرگونه پی‌نوشت با همان <key> در ورودی انجام خواهد شد.

               مقادیر معتبر برای این گزینه عبارتند از: add (پیش‌فرض) و
               doNothing.

               با add، یک پی‌نوشت جدید اضافه خواهد شد.

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

           trailer.<key-alias>.key
               یک <key-alias> را برای <key> تعریف می‌کند. مقدار <key-alias>
               باید یک پیشوند (بدون حساسیت به بزرگی و کوچکی حروف) از <key>
               باشد. برای مثال، در git config trailer.ack.key «Acked-by»،
               مقدار Acked-by همان <key> است و ack همان <key-alias> می‌باشد.
               این پیکربندی امکان فراخوانی کوتاه‌تر -railer «ack:...» را در خط
               فرمان با استفاده از <key-alias> «ack» به جای عبارت طولانی‌تر
               -railer «Acked-by:...» فراهم می‌کند.

               در انتهای <key>، یک جداکننده و سپس چند نویسه فاصله می‌تواند قرار
               گیرد. به طور پیش‌فرض تنها جداکننده معتبر : است، اما می‌توان با
               استفاده از متغیر پیکربندی trailer.separators آن را تغییر داد.

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

           trailer.<key-alias>.where
               این گزینه همان مقادیر متغیر پیکربندی trailer.where را می‌پذیرد و
               آنچه را که توسط آن گزینه برای پی‌نوشت‌های دارای <key-alias>
               مشخص‌شده تعیین شده است بازنویسی می‌کند.

           trailer.<key-alias>.ifexists
               این گزینه همان مقادیر متغیر پیکربندی trailer.ifexists را
               می‌پذیرد و آنچه را که توسط آن گزینه برای پی‌نوشت‌های دارای
               <key-alias> مشخص‌شده تعیین شده است بازنویسی می‌کند.

           trailer.<key-alias>.ifmissing
               این گزینه همان مقادیر متغیر پیکربندی trailer.ifmissing را
               می‌پذیرد و آنچه را که توسط آن گزینه برای پی‌نوشت‌های دارای
               <key-alias> مشخص‌شده تعیین شده است بازنویسی می‌کند.

           trailer.<key-alias>.command
               منسوخ شده به نفع trailer.<key-alias>.cmd.  این گزینه به همان
               شیوه trailer.<key-alias>.cmd رفتار می‌کند، با این استثنا که هیچ
               چیز را به عنوان آرگومان به دستور مشخص‌شده ارسال نمی‌کند. در عوض
               اولین وقوع زیررشته $ARG با <value> که قرار بود به عنوان آرگومان
               ارسال شود جایگزین می‌شود.

               توجه داشته باشید که $ARG در دستور کاربر فقط یک بار جایگزین
               می‌شود و روش اولیه جایگزینی $ARG امن نیست.

               هنگامی که هر دو گزینه trailer.<key-alias>.cmd و
               trailer.<key-alias>.command برای یک <key-alias> داده شوند،
               trailer.<key-alias>.cmd استفاده می‌شود و
               trailer.<key-alias>.command نادیده گرفته خواهد شد.

           trailer.<key-alias>.cmd
               این گزینه می‌تواند برای تعیین یک دستور پوسته استفاده شود که یک
               بار برای افزودن خودکار یک پی‌نوشت با <key-alias> مشخص‌شده
               فراخوانی می‌شود، و سپس هر بار که یک آرگومان -railer
               <key-alias>=<value> برای اصلاح <value> پی‌نوشتی که این گزینه
               تولید می‌کند مشخص شود، فراخوانی خواهد شد.

               هنگامی که دستور مشخص‌شده برای اولین بار جهت افزودن یک پی‌نوشت با
               <key-alias> مشخص‌شده فراخوانی می‌شود، رفتار به گونه‌ای است که گویی
               یک آرگومان ویژه -railer <key-alias>=<value> در ابتدای git-
               interpret-trailers(1) اضافه شده باشد، که در آن <value> خروجی
               استاندارد دستور پس از حذف فاصله‌های خالی ابتدا و انتها در نظر
               گرفته می‌شود.

               اگر برخی آرگومان‌های -railer <key-alias>=<value> نیز در خط فرمان
               ارسال شوند، دستور مجدداً برای هر یک از این آرگومان‌ها با همان
               <key-alias> یک بار فراخوانی می‌شود. و بخش <value> این آرگومان‌ها،
               در صورت وجود، به عنوان اولین آرگومان به دستور ارسال خواهد شد.
               به این ترتیب دستور می‌تواند یک <value> تولید کند که از <value>
               ارسال‌شده در آرگومان -railer <key-alias>=<value> محاسبه شده است.

           transfer.credentialsInUrl
               یک نشانی URL پیکربندی‌شده می‌تواند شامل اعتبارنامه‌های متنی ساده
               (plaintext credentials) به شکل
               <protocol>://<user>:<password>@<domain>/<path> باشد. ممکن است
               بخواهید درباره استفاده از چنین پیکربندی هشدار دهید یا آن را
               ممنوع کنید (به نفع استفاده از git-credential(1)).  این گزینه در
               git-clone(1)، git-fetch(1)، git-push(1) و هرگونه استفاده مستقیم
               دیگر از URL پیکربندی‌شده اعمال خواهد شد.

               توجه داشته باشید که این ویژگی در حال حاضر محدود به تشخیص
               اعتبارنامه‌ها در پیکربندی remote.<name>.url است؛ و اعتبارنامه‌ها
               را در پیکربندی remote.<name>.pushurl تشخیص نخواهد داد.

               شاید بخواهید این ویژگی را برای جلوگیری از افشای سهوی
               اعتبارنامه‌ها فعال کنید، برای مثال به این دلایل:

               •   سیستم‌عامل یا سیستمی که گیت را روی آن اجرا می‌کنید ممکن است
                   راهی برای پیکربندی دسترسی‌های فایل پیکربندی که نام کاربری
                   و/یا گذرواژه در آن ذخیره شده است ارائه ندهد یا به شما اجازه
                   این کار را ندهد.

               •   حتی اگر این کار را انجام دهد، ذخیره چنین داده‌هایی به صورت
                   ساکن («at rest») ممکن است شما را از روش‌های دیگر در معرض خطر
                   قرار دهد، برای مثال یک فرآیند پشتیبان‌گیری ممکن است داده‌ها
                   را به سیستم دیگری کپی کند.

               •   برنامه‌های گیت نشانی URL کامل را به عنوان آرگومان در خط
                   فرمان به یکدیگر ارسال می‌کنند، به این معنی که اعتبارنامه‌ها
                   در سیستم‌هایی که به سایر کاربران غیرممتاز اجازه می‌دهند فهرست
                   کامل فرآیندهای دیگران را ببینند، افشا خواهد شد. در لینوکس
                   تنظیم «hidepid» که در procfs(5) مستند شده است امکان
                   پیکربندی این رفتار را فراهم می‌کند.

                   اگر چنین نگرانی‌هایی در مورد شما صدق نمی‌کند، احتمالاً نیازی
                   نیست نگران افشای اعتبارنامه‌ها به دلیل ذخیره داده‌های حساس در
                   فایل‌های پیکربندی گیت باشید. اگر می‌خواهید از این ویژگی
                   استفاده کنید، transfer.credentialsInUrl را روی یکی از این
                   مقادیر تنظیم کنید:

               •   allow (پیش‌فرض): گیت بدون هشدار به فعالیت خود ادامه می‌دهد.

               •   warn: گیت هنگام تجزیه یک URL با اعتبارنامه متنی ساده، یک
                   پیام هشدار در stderr می‌نویسد.

               •   die: گیت هنگام تجزیه یک URL با اعتبارنامه متنی ساده، یک
                   پیام شکست در stderr می‌نویسد.

           transfer.fsckObjects
               هنگامی که fetch.fsckObjects یا receive.fsckObjects تنظیم نشده
               باشند، مقدار این متغیر در عوض استفاده می‌شود. پیش‌فرض false است.

               هنگام تنظیم، عملیات fetch یا receive در صورت وجود شیء معیوب یا
               پیوند به یک شیء ناموجود متوقف می‌شود. علاوه بر این، مسائل مختلف
               دیگری نیز بررسی می‌شوند، از جمله مشکلات موروثی (به fsck.<msg-id>
               مراجعه کنید)، و مسائل امنیتی احتمالی مانند وجود دایرکتوری .GIT
               یا یک فایل مخرب .gitmodules (برای جزئیات به یادداشت‌های انتشار
               نسخه‌های v2.2.1 و v2.17.1 مراجعه کنید). سایر بررسی‌های سلامت و
               امنیت ممکن است در انتشارهای آینده اضافه شوند.

               در سمت دریافت‌کننده، ناموفق بودن fsckObjects باعث غیرقابل‌دسترس
               شدن آن اشیاء می‌شود، بخش «QUARANTINE ENVIRONMENT» را در git-
               receive-pack(1) ببینید. در سمت fetch، اشیاء معیوب در عوض به
               صورت بدون ارجاع در مخزن باقی می‌مانند.

               با توجه به ماهیت غیرقرنطینه‌ای پیاده‌سازی fetch.fsckObjects،
               نمی‌توان مانند receive.fsckObjects اطمینان داشت که مخزن اشیاء
               (object store) را تمیز باقی می‌گذارد.

               از آنجا که اشیاء هنگام باز شدن بسته‌ها در مخزن اشیاء نوشته
               می‌شوند، مواردی وجود دارد که در آن اشیاء مخرب حتی با وجود شکست
               «fetch» وارد سیستم می‌شوند، و سپس یک «fetch» بعدی موفق می‌شود
               زیرا فقط اشیاء جدید ورودی بررسی می‌شوند، نه آن‌هایی که قبلاً در
               مخزن اشیاء نوشته شده‌اند. نباید به این تفاوت در رفتار اتکا کرد.
               در آینده، ممکن است چنین اشیائی برای «fetch» نیز قرنطینه شوند.

               در حال حاضر، افراد بسیار محتاط در صورتی که محافظتی مشابه «push»
               بخواهند باید راهی برای شبیه‌سازی محیط قرنطینه بیابند. به عنوان
               مثال، در مورد یک آینه (mirror) داخلی، آینه‌سازی را در دو مرحله
               انجام دهید: یکی برای دریافت اشیاء غیرقابل‌اعتماد، و سپس یک
               «push» دوم (که از قرنطینه استفاده خواهد کرد) به یک مخزن داخلی
               دیگر، و از کلاینت‌های داخلی بخواهید از این مخزن push‌شده استفاده
               کنند؛ یا دریافت‌های داخلی را متوقف کنید و تنها زمانی به آن‌ها
               اجازه دهید که یک «fsck» کامل اجرا شده باشد (و در این فاصله هیچ
               fetch جدیدی رخ نداده باشد).

           transfer.hideRefs
               رشته(هایی) که receive-pack و upload-pack برای تصمیم‌گیری در مورد
               اینکه چه مراجعی (refs) از اعلان‌های اولیه آن‌ها حذف شوند استفاده
               می‌کنند. برای مشخص کردن چندین رشته پیشوندی از بیش از یک تعریف
               استفاده کنید. مرجعی که زیر سلسله‌مراتب‌های فهرست‌شده در مقدار این
               متغیر باشد مستثنی شده و هنگام پاسخ دادن به git push یا git
               fetch مخفی می‌شود. برای نسخه‌های ویژه‌برنامه این پیکربندی به
               receive.hideRefs و uploadpack.hideRefs مراجعه کنید.

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

               اگر یک فضای نام (namespace) در حال استفاده باشد، پیشوند فضای
               نام قبل از تطبیق با الگوهای transfer.hiderefs از هر مرجع حذف
               می‌شود. به منظور تطبیق مراجع قبل از حذف پیشوند، یک ^ در ابتدای
               نام مرجع اضافه کنید. اگر ! و ^ را ترکیب می‌کنید، ابتدا باید !
               مشخص شود.

               برای مثال، اگر refs/heads/master در transfer.hideRefs مشخص شده
               باشد و فضای نام فعلی foo باشد، آنگاه
               refs/namespaces/foo/refs/heads/master از اعلان‌ها حذف می‌شود. اگر
               uploadpack.allowRefInWant تنظیم شده باشد، upload-pack در دستور
               fetch تحت پروتکل نسخه ۲ با want-ref refs/heads/master طوری
               برخورد می‌کند که گویی refs/namespaces/foo/refs/heads/master وجود
               نداشته است. از طرف دیگر، receive-pack همچنان شناسه شیئی را که
               مرجع به آن اشاره می‌کند بدون ذکر نام آن اعلان می‌کند (یک خط
               اصطلاحاً «.have»).

               حتی اگر مراجع را مخفی کنید، کلاینت ممکن است همچنان بتواند اشیاء
               هدف را از طریق تکنیک‌های شرح داده شده در بخش «SECURITY» صفحه
               راهنمای gitnamespaces(7) برباید؛ بهتر است داده‌های خصوصی در یک
               مخزن جداگانه نگهداری شوند.

           transfer.unpackLimit
               هنگامی که fetch.unpackLimit یا receive.unpackLimit تنظیم نشده
               باشند، مقدار این متغیر در عوض استفاده می‌شود. مقدار پیش‌فرض 100
               است.

           transfer.advertiseSID
               بولی. هنگامی که true باشد، فرایندهای کلاینت و سرور شناسه‌های
               یکتای نشست (session IDs) خود را به همتای راه دور خود اعلان
               می‌کنند. پیش‌فرض false است.

           transfer.bundleURI
               هنگامی که true باشد، دستورات محلی git clone اطلاعات بسته
               (bundle) را از سرور راه دور (در صورت اعلان) درخواست کرده و قبل
               از ادامه شبیه‌سازی از طریق پروتکل گیت، بسته‌ها را بارگیری می‌کنند.
               پیش‌فرض false است.

           transfer.advertiseObjectInfo
               هنگامی که true باشد، قابلیت object-info توسط سرورها اعلان
               می‌شود. پیش‌فرض false است.

           uploadarchive.allowUnreachable
               اگر true باشد، به کلاینت‌ها اجازه می‌دهد از git archive -emote
               برای درخواست هر درختی، چه از نوک مراجع قابل دسترس باشد و چه
               نباشد، استفاده کنند. برای جزئیات بیشتر به توضیحات بخش
               «SECURITY» در git-upload-archive(1) مراجعه کنید. پیش‌فرض false
               است.

           uploadpack.hideRefs
               این متغیر مشابه transfer.hideRefs است، اما تنها بر upload-pack
               اعمال می‌شود (و بنابراین تنها بر fetchها تأثیر می‌گذارد، نه
               pushها). تلاش برای fetch کردن یک مرجع مخفی توسط git fetch شکست
               خواهد خورد. همچنین به uploadpack.allowTipSHA1InWant مراجعه
               کنید.

           uploadpack.allowTipSHA1InWant
               هنگامی که uploadpack.hideRefs فعال است، به upload-pack اجازه
               می‌دهد تا درخواست fetch که شیئی در نوک یک مرجع مخفی را می‌خواهد
               بپذیرد (به طور پیش‌فرض، چنین درخواستی رد می‌شود). همچنین به
               uploadpack.hideRefs مراجعه کنید. حتی اگر این مقدار false باشد،
               یک کلاینت ممکن است بتواند از طریق تکنیک‌های شرح داده شده در بخش
               «SECURITY» صفحه راهنمای gitnamespaces(7) اشیاء را برباید؛ بهتر
               است داده‌های خصوصی در یک مخزن جداگانه نگهداری شوند.

           uploadpack.allowReachableSHA1InWant
               به upload-pack اجازه می‌دهد تا درخواست fetch که شیئی قابل دسترس
               از هر نوک مرجعی را می‌خواهد بپذیرد. با این حال، توجه داشته باشید
               که محاسبه دسترسی‌پذیری شیء از نظر محاسباتی سنگین است. پیش‌فرض
               false است. حتی اگر این مقدار false باشد، یک کلاینت ممکن است
               بتواند از طریق تکنیک‌های شرح داده شده در بخش «SECURITY» صفحه
               راهنمای gitnamespaces(7) اشیاء را برباید؛ بهتر است داده‌های
               خصوصی در یک مخزن جداگانه نگهداری شوند.

           uploadpack.allowAnySHA1InWant
               به upload-pack اجازه می‌دهد تا درخواست fetch برای هر شیئی را
               بپذیرد. این گزینه مستلزم uploadpack.allowTipSHA1InWant و
               uploadpack.allowReachableSHA1InWant است. اگر روی true تنظیم شود
               هر دوی آن‌ها را فعال می‌کند، و اگر روی false تنظیم شود هر دوی
               آن‌ها را غیرفعال می‌کند. به طور پیش‌فرض تنظیم نشده است.

           uploadpack.keepAlive
               هنگامی که upload-pack دستور pack-objects را آغاز کرده باشد،
               ممکن است یک دوره سکوت در زمانی که pack-objects بسته را آماده
               می‌کند وجود داشته باشد. در حالت عادی اطلاعات پیشرفت را خروجی
               می‌دهد، اما اگر از گزینه -quiet برای fetch استفاده شده باشد،
               pack-objects تا زمان شروع ارسال داده‌های بسته مطلقاً چیزی خروجی
               نخواهد داد. برخی کلاینت‌ها و شبکه‌ها ممکن است سرور را متوقف‌شده
               (hung) تلقی کرده و ارتباط را قطع کنند. تنظیم این گزینه به
               upload-pack دستور می‌دهد هر uploadpack.keepAlive ثانیه یک بسته
               خالی زنده نگه‌داشتن (keepalive packet) ارسال کند. تنظیم این
               گزینه روی 0 بسته‌های keepalive را به طور کامل غیرفعال می‌کند.
               پیش‌فرض 5 ثانیه است.

           uploadpack.packObjectsHook
               اگر این گزینه تنظیم شده باشد، هنگامی که upload-pack بخواهد git
               pack-objects را برای ایجاد یک فایل بسته (packfile) برای کلاینت
               اجرا کند، در عوض این دستور پوسته را اجرا خواهد کرد. دستور
               pack-objects و آرگومان‌هایی که می‌بایست اجرا می‌شدند (شامل git
               pack-objects در ابتدا) به انتهای دستور پوسته ضمیمه می‌شوند.
               ورودی استاندارد (stdin) و خروجی استاندارد (stdout) قلاب به
               گونه‌ای مدیریت می‌شوند که گویی خود pack-objects اجرا شده است؛
               یعنی upload-pack ورودی در نظر گرفته‌شده برای pack-objects را به
               قلاب می‌دهد و انتظار یک فایل بسته کامل را در stdout دارد.

               توجه داشته باشید که این متغیر پیکربندی تنها زمانی رعایت می‌شود
               که در پیکربندی محافظت‌شده مشخص شده باشد (بخش موسوم به “SCOPES”
               را ببینید). این یک اقدام ایمنی در برابر دریافت از مخازن
               غیرقابل‌اعتماد است.

           uploadpack.allowFilter
               اگر این گزینه تنظیم شود، upload-pack از کلون جزئی (partial
               clone) و فیلتر کردن اشیاء در دریافت جزئی (partial fetch)
               پشتیبانی خواهد کرد.

           uploadpackfilter.allow
               یک مقدار پیش‌فرض برای فیلترهای شیء تعیین‌نشده ارائه می‌دهد (متغیر
               پیکربندی زیر را ببینید). اگر روی true تنظیم شود، همه فیلترهایی
               را که در آینده اضافه می‌شوند نیز فعال خواهد کرد. پیش‌فرض true
               است.

           uploadpackfilter.<filter>.allow
               صراحتاً فیلتر شیء متناظر با <filter> را مجاز یا ممنوع می‌کند، که
               در آن <filter> می‌تواند یکی از موارد زیر باشد: blob:none،
               blob:limit، object:type، tree، sparse:oid یا combine.  در صورت
               استفاده از فیلترهای ترکیبی، هم combine و هم تمام انواع فیلترهای
               تودرتو باید مجاز باشند. پیش‌فرض uploadpackfilter.allow است.

           uploadpackfilter.tree.maxDepth
               تنها زمانی -lter=tree:<n> را مجاز می‌داند که <n> بیشتر از مقدار
               uploadpackfilter.tree.maxDepth نباشد. در صورت تنظیم، این گزینه
               همچنین مستلزم uploadpackfilter.tree.allow=true است، مگر اینکه
               این متغیر پیکربندی از قبل تنظیم شده باشد. در صورت عدم تنظیم هیچ
               اثری ندارد.

           uploadpack.allowRefInWant
               اگر این گزینه تنظیم شود، upload-pack از قابلیت ref-in-want
               دستور fetch در پروتکل نسخه ۲ پشتیبانی خواهد کرد. این قابلیت به
               نفع سرورهای با موازنه‌بار (load-balanced) در نظر گرفته شده است
               که ممکن است به دلیل تأخیر در همانندسازی (replication delay)،
               دیدگاه یکسانی از اینکه مراجع آن‌ها به چه OIDهایی اشاره می‌کنند
               نداشته باشند.

           url.<base>.insteadOf
               هر نشانی URL که با این مقدار شروع شود بازنویسی می‌شود تا در عوض
               با <base> شروع شود. در مواردی که یک سایت تعداد زیادی مخزن را
               میزبانی می‌کند و آن‌ها را با چندین روش دسترسی ارائه می‌دهد، و برخی
               کاربران نیاز به استفاده از روش‌های دسترسی متفاوتی دارند، این
               قابلیت به افراد اجازه می‌دهد هر یک از URLهای معادل را مشخص کنند
               و گیت به طور خودکار URL را به بهترین جایگزین برای آن کاربر خاص
               بازنویسی کند، حتی برای مخزنی در آن سایت که قبلاً هرگز دیده نشده
               است. هنگامی که بیش از یک رشته insteadOf با یک URL مطابقت داشته
               باشد، طولانی‌ترین تطابق استفاده می‌شود.

               توجه داشته باشید که هرگونه محدودیت پروتکل بر URL بازنویسی‌شده
               اعمال خواهد شد. اگر بازنویسی، URL را برای استفاده از یک پروتکل
               سفارشی یا دستیار راه دور (remote helper) تغییر دهد، ممکن است
               لازم باشد پیکربندی protocol.*.allow را برای مجاز کردن درخواست
               تنظیم کنید. به ویژه، پروتکل‌هایی که انتظار دارید برای زیرماژول‌ها
               استفاده کنید باید به جای مقدار پیش‌فرض user روی always تنظیم
               شوند. توضیحات protocol.allow در بالا را ببینید.

           url.<base>.pushInsteadOf
               به هر نشانی URL که با این مقدار شروع شود داده‌ای push نخواهد شد؛
               در عوض، بازنویسی می‌شود تا با <base> شروع شود، و به URL حاصل
               push انجام می‌شود. در مواردی که یک سایت تعداد زیادی مخزن را با
               چندین روش دسترسی میزبانی می‌کند، که برخی از آن‌ها اجازه push را
               نمی‌دهند، این قابلیت به افراد اجازه می‌دهد یک URL فقط-دریافتی
               (pull-only) مشخص کنند و گیت به طور خودکار از یک URL مناسب برای
               push استفاده کند، حتی برای مخزنی در آن سایت که قبلاً هرگز دیده
               نشده است. هنگامی که بیش از یک رشته pushInsteadOf با یک URL
               مطابقت داشته باشد، طولانی‌ترین تطابق استفاده می‌شود. اگر یک ریموت
               دارای یک pushurl صریح باشد، گیت این تنظیم را برای آن ریموت
               نادیده خواهد گرفت.

           user.name, user.email, author.name, author.email, committer.name,
           committer.email
               متغیرهای user.name و user.email تعیین می‌کنند چه مقادیری در
               فیلدهای author (نویسنده) و committer (ثبت‌کننده) اشیاء کامیت
               قرار گیرند. اگر نیاز دارید که author یا committer متفاوت باشند،
               می‌توان متغیرهای author.name، author.email، committer.name یا
               committer.email را تنظیم کرد. همه این موارد را می‌توان با
               متغیرهای محیطی GIT_AUTHOR_NAME، GIT_AUTHOR_EMAIL،
               GIT_COMMITTER_NAME، GIT_COMMITTER_EMAIL و EMAIL بازنویسی کرد.

               توجه داشته باشید که اشکال name این متغیرها به طور معمول به نوعی
               نام شخصی اشاره دارند. برای اطلاعات بیشتر در مورد این تنظیمات به
               git-commit(1) و بخش متغیرهای محیطی در git(1) مراجعه کنید، و در
               صورتی که به دنبال اعتبارنامه‌های احراز هویت هستید، به گزینه
               credential.username نگاه کنید.

           user.useConfigOnly
               به گیت دستور می‌دهد از تلاش برای حدس زدن مقادیر پیش‌فرض برای
               user.email و user.name خودداری کند، و در عوض مقادیر را تنها از
               پیکربندی بازیابی کند. برای مثال، اگر چندین نشانی ایمیل دارید و
               مایلید برای هر مخزن از یک ایمیل متفاوت استفاده کنید، با تنظیم
               این گزینه پیکربندی روی true در پیکربندی سراسری همراه با یک نام،
               گیت قبل از ایجاد کامیت‌های جدید در یک مخزن تازه کلون‌شده از شما
               درخواست می‌کند ایمیلی را تنظیم کنید. پیش‌فرض false است.

           user.signingKey
               اگر git-tag(1) یا git-commit(1) هنگام ایجاد یک برچسب یا کامیت
               امضاشده کلیدی را که می‌خواهید به طور خودکار انتخاب نمی‌کند،
               می‌توانید انتخاب پیش‌فرض را با این متغیر بازنویسی کنید. این گزینه
               بدون تغییر به پارامتر -rmat روی ssh تنظیم شده باشد، این مقدار
               می‌تواند حاوی مسیر کلید خصوصی ssh شما یا کلید عمومی در هنگام
               استفاده از ssh-agent باشد. به عنوان جایگزین، می‌تواند مستقیماً
               حاوی یک کلید عمومی با پیشوند key:: باشد (مانند: «key::ssh-rsa
               XXXXXX identifier»). کلید خصوصی باید از طریق ssh-agent در دسترس
               باشد. اگر تنظیم نشده باشد، گیت gpg.ssh.defaultKeyCommand را
               فراخوانی می‌کند (مانند: «ssh-add -L») و تلاش می‌کند از اولین کلید
               موجود استفاده کند. برای سازگاری با گذشته، کلید خامی که با
               «-ssh» شروع شود، مانند «ssh-rsa XXXXXX identifier»، به صورت
               «key::ssh-rsa XXXXXX identifier» در نظر گرفته می‌شود، اما این
               قالب منسوخ شده است؛ در عوض از قالب key:: استفاده کنید.

           versionsort.prereleaseSuffix (deprecated)
               نام مستعار منسوخ‌شده برای versionsort.suffix.  در صورت تنظیم
               بودن versionsort.suffix نادیده گرفته می‌شود.

           versionsort.suffix
               حتی زمانی که مرتب‌سازی نسخه‌ای در git-tag(1) استفاده می‌شود، نام
               برچسب‌های دارای نسخه پایه یکسان اما پسوندهای متفاوت همچنان به
               صورت لغت‌نامه‌ای (lexicographically) مرتب می‌شوند، که برای مثال
               منجر به ظاهر شدن برچسب‌های پیش‌انتشار پس از انتشار اصلی می‌شود
               (مانند «1.0-rc1» بعد از «1.0»). این متغیر را می‌توان برای تعیین
               ترتیب مرتب‌سازی برچسب‌های دارای پسوندهای مختلف مشخص کرد.

               با تعیین یک پسوند منفرد در این متغیر، هر نام برچسب شامل آن
               پسوند قبل از انتشار اصلی مربوطه ظاهر خواهد شد. برای مثال، اگر
               این متغیر روی «-rc» تنظیم شود، تمام برچسب‌های «1.0-rcX» قبل از
               «1.0» ظاهر می‌شوند. در صورت تعیین چندباره، هر بار برای یک پسوند،
               ترتیب پسوندها در پیکربندی، ترتیب مرتب‌سازی نام برچسب‌های دارای آن
               پسوندها را تعیین خواهد کرد. برای مثال، اگر «-pre» قبل از «-rc»
               در پیکربندی ظاهر شود، تمام برچسب‌های «1.0-preX» قبل از هر برچسب
               «1.0-rcX» فهرست می‌شوند. جایگاه برچسب انتشار اصلی نسبت به
               برچسب‌های دارای پسوندهای گوناگون را می‌توان با تعیین پسوند خالی
               در میان آن پسوندهای دیگر تعیین کرد. برای مثال اگر پسوندهای
               «-rc»، «»، «-ck» و «-bfs» به همین ترتیب در پیکربندی ظاهر شوند،
               ابتدا همه برچسب‌های «v4.8-rcX» فهرست می‌شوند، پس از آن «v4.8»،
               سپس «v4.8-ckX» و در نهایت «v4.8-bfsX».

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

           web.browser
               یک مرورگر وب را مشخص می‌کند که ممکن است توسط برخی دستورات
               استفاده شود. در حال حاضر فقط git-instaweb(1) و git-help(1) ممکن
               است از آن استفاده کنند.

           worktree.guessRemote
               اگر هیچ شاخه‌ای مشخص نشده باشد و هیچ‌کدام از -b، -B یا -etach
               استفاده نشده باشند، git worktree add به طور پیش‌فرض یک شاخه جدید
               از HEAD ایجاد می‌کند. اگر worktree.guessRemote روی true تنظیم
               شده باشد، worktree add تلاش می‌کند یک شاخه ردیابی راه دور
               (remote-tracking branch) را پیدا کند که نام آن به طور یکتا با
               نام شاخه جدید مطابقت داشته باشد. اگر چنین شاخه‌ای وجود داشته
               باشد، checkout شده و به عنوان «upstream» برای شاخه جدید تنظیم
               می‌شود. اگر چنین تطابقی یافت نشود، به ایجاد یک شاخه جدید از HEAD
               فعلی بازمی‌گردد.

           worktree.useRelativePaths
               پیوند دادن درخت‌های کاری با استفاده از مسیرهای نسبی (هنگامی که
               «true») یا مسیرهای مطلق (هنگامی که «false»). این امر به ویژه
               برای ساختارهایی مفید است که در آن‌ها مخزن و درخت‌های کاری ممکن
               است بین مکان‌ها یا محیط‌های مختلف جابه‌جا شوند. پیش‌فرض «false»
               است.

               توجه داشته باشید که تنظیم worktree.useRelativePaths روی «true»
               به معنای فعال‌سازی پیکربندی extensions.relativeWorktrees است (به
               git-config(1) مراجعه کنید)، که در نتیجه آن را با نسخه‌های
               قدیمی‌تر گیت ناسازگار می‌سازد.

خطاها (BUGS)
       هنگام استفاده از نحو منسوخ‌شده [section.subsection]، اگر زیربخش
       (subsection) حداقل با یک نویسه بزرگ ارائه شده باشد، تغییر یک مقدار به
       جای تغییر دادن، منجر به افزودن یک کلید چندخطی خواهد شد. برای مثال وقتی
       پیکربندی به این صورت باشد

             [section.subsection]
               key = value1


       و اجرای git config section.Subsection.key value2 منجر خواهد شد به

             [section.subsection]
               key = value1
               key = value2


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

یادداشت‌ها (NOTES)
        1. سند طراحی bundle URI
           file:///usr/share/doc/git-doc/technical/bundle-uri.html

Git 2.55.0                        2026-06-29                     GIT-CONFIG(1)