'\" t .\" Title: gitattributes .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author] .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 2026-06-29 .\" Manual: Git Manual .\" Source: Git 2.55.0 .\" Language: Persian .\" .TH "GITATTRIBUTES" "5" "2026\-06\-29" "Git 2\&.55\&.0" "Git Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "نام (NAME)" gitattributes \- تعریف مشخصه‌ها برای هر مسیر .SH "خلاصه دستور (SYNOPSIS)" .sp $GIT_DIR/info/attributes, \&.gitattributes .SH "توضیحات (DESCRIPTION)" .sp یک فایل \fBgitattributes\fR یک فایل متنی ساده است که به نام مسیرها \fBمشخصه‌ها\fR (attributes) را اختصاص می‌دهد\&. .sp هر خط در فایل \fBgitattributes\fR به این صورت است: .sp .if n \{\ .RS 4 .\} .nf pattern attr1 attr2 \&.\&.\&. .fi .if n \{\ .RE .\} .sp یعنی یک الگو (pattern) که به دنبال آن فهرستی از مشخصه‌ها با فاصله (whitespace) جدا شده‌اند\&. فاصله‌های ابتدایی و انتهایی نادیده گرفته می‌شوند\&. خطوطی که با \fI#\fR آغاز می‌شوند نادیده گرفته می‌شوند\&. الگوهایی که با نقل‌قول دوتایی شروع می‌شوند، به سبک C نقل‌قول می‌شوند\&. هنگامی که الگو با مسیر مورد نظر مطابقت داشته باشد، مشخصه‌های فهرست‌شده در آن خط به آن مسیر اختصاص داده می‌شوند\&. .sp هر مشخصه می‌تواند برای یک مسیر داده‌شده در یکی از این حالت‌ها باشد: .PP تنظیم‌شده (Set) .RS 4 مسیر دارای مشخصه با مقدار ویژه "true" است؛ این حالت تنها با درج نام مشخصه در فهرست مشخصه‌ها تعیین می‌شود\&. .RE .PP تنظیم‌نشده (Unset) .RS 4 مسیر دارای مشخصه با مقدار ویژه "false" است؛ این حالت با درج نام مشخصه همراه با پیشوند خط تیره \fB\-\fR در فهرست مشخصه‌ها تعیین می‌شود\&. .RE .PP تنظیم‌شده به یک مقدار (Set to a value) .RS 4 مسیر دارای مشخصه با مقدار رشته‌ای مشخص‌شده است؛ این حالت با درج نام مشخصه و به دنبال آن علامت مساوی \fB=\fR و مقدار آن در فهرست مشخصه‌ها تعیین می‌شود\&. .RE .PP مشخص‌نشده (Unspecified) .RS 4 هیچ الگویی با مسیر مطابقت ندارد و چیزی بیان نمی‌کند که مسیر دارای مشخصه است یا خیر؛ در این حالت گفته می‌شود مشخصه برای مسیر Unspecified است\&. .RE .sp هنگامی که بیش از یک الگو با مسیر مطابقت داشته باشد، خطوط بعدی خطوط قبلی را بازنویسی (override) می‌کنند\&. این بازنویسی برای هر مشخصه به طور جداگانه انجام می‌شود\&. .sp قوانینی که الگوها بر اساس آن با مسیرها مطابقت می‌یابند همانند فایل‌های \fB\&.gitignore\fR است (به \fBgitignore\fR(5) مراجعه کنید)، با چند استثنا: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} الگوهای منفی ممنوع هستند\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} الگوهایی که با یک شاخه مطابقت دارند، به صورت بازگشتی با مسیرهای داخل آن شاخه مطابقت پیدا نمی‌کنند (بنابراین استفاده از ساختار اسلش انتهایی \fBpath/\fR در فایل مشخصه‌ها بی‌فایده است؛ در عوض از \fBpath/**\fR استفاده کنید)\&. .RE .sp هنگام تصمیم‌گیری در مورد اینکه چه مشخصه‌هایی به یک مسیر اختصاص یابد، Git فایل \fB$GIT_DIR/info/attributes\fR (که بالاترین اولویت را دارد)، فایل \fB\&.gitattributes\fR در همان شاخهٔ مسیر مورد نظر، و شاخه‌های والد آن را تا بالاترین سطح درخت کاری (هرچه شاخه حاوی \fB\&.gitattributes\fR از مسیر مورد نظر دورتر باشد، اولویت آن کمتر است) بررسی می‌کند\&. در نهایت فایل‌های سراسری (global) و سیستمی (system\-wide) در نظر گرفته می‌شوند (که کمترین اولویت را دارند)\&. .sp هنگامی که فایل \fB\&.gitattributes\fR در درخت کاری موجود نباشد، مسیر موجود در نمایه (index) به عنوان جایگزین استفاده می‌شود\&. در طول فرایند دریافت (checkout)، فایل \fB\&.gitattributes\fR در نمایه استفاده شده و سپس فایل موجود در درخت کاری به عنوان جایگزین استفاده می‌شود\&. .sp اگر مایلید تنها بر یک مخزن خاص اثر بگذارید (یعنی مشخصه‌ها را به فایل‌هایی اختصاص دهید که مختص جریان کاری یک کاربر برای آن مخزن هستند)، مشخصه‌ها باید در فایل \fB$GIT_DIR/info/attributes\fR قرار گیرند\&. مشخصه‌هایی که باید تحت کنترل نگارش قرار گرفته و به مخازن دیگر توزیع شوند (یعنی مشخصه‌هایی که برای همهٔ کاربران اهمیت دارند) باید در فایل‌های \fB\&.gitattributes\fR قرار گیرند\&. مشخصه‌هایی که باید بر تمام مخازن یک کاربر اثر بگذارند باید در فایلی که با گزینهٔ پیکربندی \fBcore\&.attributesFile\fR مشخص شده است قرار گیرند (به \fBgit-config\fR(1) مراجعه کنید)\&. مقدار پیش‌فرض آن $XDG_CONFIG_HOME/git/attributes است\&. اگر $XDG_CONFIG_HOME تنظیم نشده باشد یا خالی باشد، $HOME/\&.config/git/attributes استفاده می‌شود\&. مشخصه‌ها برای تمام کاربران روی یک سیستم باید در فایل \fB$\fR(\fBprefix\fR)\fB/etc/gitattributes\fR قرار گیرند\&. .sp گاهی اوقات ممکن است نیاز داشته باشید مقدار یک مشخصه را برای یک مسیر به حالت \fBUnspecified\fR بازنویسی کنید\&. این کار با درج نام مشخصه همراه با علامت تعجب پیشوند ! انجام می‌شود\&. .SH "مشخصه‌های رزروشدهٔ BUILTIN_* (RESERVED BUILTIN_* ATTRIBUTES)" .sp فضای نام builtin_* برای مقادیر مشخصه‌های توکار رزرو شده است\&. هرگونه مشخصهٔ تعریف‌شده توسط کاربر تحت این فضای نام نادیده گرفته شده و هشداری را ایجاد می‌کند\&. .SS "\fBbuiltin_objectmode\fR" .sp این مشخصه برای پالایش فایل‌ها بر اساس حالت بیت‌های فایل (40000, 120000, 160000, 100755, 100644) استفاده می‌شود؛ مانند \fI:(attr:builtin_objectmode=160000)\fR\&. شما همچنین می‌توانید این مقادیر را با \fBgit\fR \fBcheck\-attr\fR \fBbuiltin_objectmode\fR \fB\-\-\fR \fI\fR بررسی کنید\&. اگر شیء در نمایه نباشد، \fBgit\fR \fBcheck\-attr\fR \fB\-\-cached\fR مقدار unspecified را برمی‌گرداند\&. .SH "اثرات (EFFECTS)" .sp برخی از عملیات‌های Git را می‌توان با اختصاص مشخصه‌های خاص به یک مسیر تحت تأثیر قرار داد\&. در حال حاضر، عملیات‌های زیر به مشخصه‌ها حساس هستند\&. .SS "دریافت و ثبت (Checking\-out and checking\-in)" .sp این مشخصه‌ها تعیین می‌کنند که محتویات ذخیره‌شده در مخزن چگونه هنگام اجرای دستورهایی نظیر \fIgit switch\fR، \fIgit checkout\fR و \fIgit merge\fR در فایل‌های درخت کاری کپی شوند\&. آن‌ها همچنین تعیین می‌کنند که Git چگونه محتویاتی را که در درخت کاری آماده می‌کنید پس از \fIgit add\fR و \fIgit commit\fR در مخزن ذخیره کند\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBtext\fR .RS 4 .sp این مشخصه مسیر را به عنوان یک فایل متنی نشانه‌گذاری می‌کند که تبدیل پایان خط (end\-of\-line) را فعال می‌سازد: هنگامی که یک فایل منطبق به نمایه اضافه می‌شود، پایان خطوط فایل در نمایه به LF تبدیل و استانداردسازی می‌شود\&. برعکس، هنگامی که فایل از نمایه به شاخهٔ کاری کپی می‌شود، پایان خطوط آن ممکن است بسته به مشخصهٔ \fBeol\fR، پیکربندی Git و بستر سیستم، از LF به CRLF تبدیل شود (توضیحات \fBeol\fR را در زیر ببینید)\&. .PP تنظیم‌شده (Set) .RS 4 تنظیم مشخصهٔ \fBtext\fR روی یک مسیر، تبدیل پایان خط را در هنگام ثبت و دریافت همان‌طور که در بالا شرح داده شد فعال می‌کند\&. پایان خطوط هر بار که فایل ثبت می‌شود به LF در نمایه یکپارچه‌سازی می‌شود، حتی اگر فایل قبلاً با پایان خطوط CRLF به Git اضافه شده باشد\&. .RE .PP تنظیم‌نشده (Unset) .RS 4 لغو تنظیم مشخصهٔ \fBtext\fR روی یک مسیر به Git می‌گوید که هنگام ثبت یا دریافت هیچ تلاشی برای تبدیل پایان خط انجام ندهد\&. .RE .PP تنظیم‌شده به مقدار رشته‌ای "auto" .RS 4 هنگامی که \fBtext\fR روی "auto" تنظیم شود، Git خود تصمیم می‌گیرد که فایل متنی است یا باینری\&. اگر متنی باشد و فایل قبلاً با پایان‌های CRLF در Git نبوده باشد، پایان خطوط هنگام ثبت و دریافت تبدیل می‌شوند\&. در غیر این صورت، هیچ تبدیلی در ثبت یا دریافت انجام نمی‌گیرد\&. .RE .PP مشخص‌نشده (Unspecified) .RS 4 اگر مشخصهٔ \fBtext\fR مشخص نشده باشد، Git از متغیر پیکربندی \fBcore\&.autocrlf\fR برای تعیین اینکه آیا فایل باید تبدیل شود یا خیر استفاده می‌کند\&. .RE .sp هر مقدار دیگری باعث می‌شود Git طوری رفتار کند که گویی \fBtext\fR مشخص‌نشده رها شده است\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBeol\fR .RS 4 .sp این مشخصه مسیری را نشانه‌گذاری می‌کند تا هنگام دریافت در درخت کاری از سبک پایان خط خاصی استفاده کند\&. این مشخصه تنها زمانی مؤثر است که \fBtext\fR یا \fBtext=auto\fR تنظیم شده باشد، اما تعیین \fBeol\fR در صورتی که \fBtext\fR مشخص نشده باشد، به طور خودکار \fBtext\fR را تنظیم می‌کند\&. .PP تنظیم‌شده به مقدار رشته‌ای "crlf" .RS 4 این تنظیم باعث می‌شود هنگام دریافت فایل، پایان خطوط آن در شاخهٔ کاری به CRLF تبدیل شود\&. .RE .PP تنظیم‌شده به مقدار رشته‌ای "lf" .RS 4 این تنظیم هنگام دریافت فایل در شاخهٔ کاری از همان پایان خطوط موجود در نمایه استفاده می‌کند\&. .RE .PP مشخص‌نشده (Unspecified) .RS 4 اگر مشخصهٔ \fBeol\fR برای یک فایل مشخص نشده باشد، پایان خطوط آن در شاخهٔ کاری توسط متغیرهای پیکربندی \fBcore\&.autocrlf\fR یا \fBcore\&.eol\fR تعیین می‌شود (تعاریف این گزینه‌ها را در \fBgit-config\fR(1) ببینید)\&. اگر \fBtext\fR تنظیم شده باشد اما هیچ‌کدام از این متغیرها تنظیم نشده باشند، مقدار پیش‌فرض روی ویندوز \fBeol=crlf\fR و در تمام بسترهای دیگر \fBeol=lf\fR است\&. .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBسازگاری رو به عقب با مشخصه crlf\fR .RS 4 .sp برای سازگاری رو به عقب، مشخصهٔ \fBcrlf\fR به صورت زیر تفسیر می‌شود: .sp .if n \{\ .RS 4 .\} .nf crlf text \-crlf \-text crlf=input eol=lf .fi .if n \{\ .RE .\} .sp .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBتبدیل پایان خط (End-of-line conversion)\fR .RS 4 .sp در حالی که Git به طور معمول محتوای فایل را دست‌نخورده باقی می‌گذارد، می‌توان آن را طوری پیکربندی کرد که پایان خطوط را در مخزن به LF تبدیل کرده و به صورت اختیاری هنگام دریافت فایل‌ها آن‌ها را به CRLF تبدیل نماید\&. .sp اگر صرفاً می‌خواهید بدون در نظر گرفتن مخزنی که روی آن کار می‌کنید پایان خطوط CRLF در شاخهٔ کاری خود داشته باشید، می‌توانید متغیر پیکربندی "core\&.autocrlf" را بدون استفاده از هیچ مشخصه‌ای تنظیم کنید\&. .sp .if n \{\ .RS 4 .\} .nf [core] autocrlf = true .fi .if n \{\ .RE .\} .sp .sp این کار یکپارچه‌سازی فایل‌های متنی را اجبار نمی‌کند، اما تضمین می‌کند فایل‌های متنی جدیدی که به مخزن وارد می‌کنید هنگام اضافه‌شدن، پایان خطوط آن‌ها به LF تبدیل شده و فایل‌هایی که از قبل در مخزن یکپارچه شده‌اند به همان صورت باقی بمانند\&. .sp اگر می‌خواهید مطمئن شوید فایل‌های متنی واردشده توسط هر مشارکت‌کننده‌ای یکپارچه‌سازی می‌شوند، می‌توانید مشخصهٔ \fBtext\fR را برای \fIهمهٔ\fR فایل‌ها روی "auto" تنظیم کنید\&. .sp .if n \{\ .RS 4 .\} .nf * text=auto .fi .if n \{\ .RE .\} .sp .sp مشخصه‌ها امکان کنترل دقیق نحوهٔ تبدیل پایان خطوط را فراهم می‌کنند\&. در اینجا مثالی آمده است که باعث می‌شود Git فایل‌های \&.txt، \&.vcproj و \&.sh را یکپارچه کند، مطمئن شود فایل‌های \&.vcproj دارای CRLF و فایل‌های \&.sh دارای LF در شاخهٔ کاری باشند، و از یکپارچه‌سازی فایل‌های \&.jpg صرف‌نظر از محتوای آن‌ها جلوگیری کند\&. .sp .if n \{\ .RS 4 .\} .nf * text=auto *\&.txt text *\&.vcproj text eol=crlf *\&.sh text eol=lf *\&.jpg \-text .fi .if n \{\ .RE .\} .sp .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBنکته\fR .ps -1 .br .sp هنگامی که تبدیل \fBtext=auto\fR در یک پروژهٔ چندبستری با استفاده از push و pull به یک مخزن مرکزی فعال می‌شود، فایل‌های متنی حاوی CRLF باید یکپارچه‌سازی شوند\&. .sp .5v .RE .sp از یک شاخهٔ کاری تمیز: .sp .if n \{\ .RS 4 .\} .nf $ echo "* text=auto" >\&.gitattributes $ git add \-\-renormalize \&. $ git status # فایل‌هایی را که استانداردسازی خواهند شد نمایش می‌دهد $ git commit \-m "Introduce end\-of\-line normalization" .fi .if n \{\ .RE .\} .sp .sp اگر فایلی که نباید استانداردسازی شود در \fIgit status\fR ظاهر شد، قبل از اجرای \fIgit add \-u\fR مشخصهٔ \fBtext\fR آن را لغو کنید\&. .sp .if n \{\ .RS 4 .\} .nf manual\&.pdf \-text .fi .if n \{\ .RE .\} .sp .sp برعکس، برای فایل‌های متنی که Git آن‌ها را تشخیص نداده است می‌توان یکپارچه‌سازی را به صورت دستی فعال کرد\&. .sp .if n \{\ .RS 4 .\} .nf weirdchars\&.txt text .fi .if n \{\ .RE .\} .sp .sp اگر \fBcore\&.safecrlf\fR روی "true" یا "warn" تنظیم شده باشد، Git بررسی می‌کند که آیا تبدیل با تنظیمات فعلی \fBcore\&.autocrlf\fR برگشت‌پذیر است یا خیر\&. برای "true"، تبدیل‌های برگشت‌ناپذیر را رد می‌کند؛ برای "warn"، فقط هشدار می‌دهد اما تبدیل را می‌پذیرد\&. این ویژگی ایمنی برای جلوگیری از اعمال چنین تبدیلی روی فایل‌های درخت کاری فعال می‌شود، با این حال چند استثنا وجود دارد: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} دستور \fIgit add\fR خود فایل‌ها را در درخت کاری تغییر نمی‌دهد، اما دریافت بعدی تغییر می‌دهد، بنابراین ایمنی فعال می‌شود؛ .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} دستور \fIgit apply\fR برای به‌روزرسانی یک فایل متنی با یک وصله فایل‌ها را تغییر می‌دهد، اما عملیات مربوط به فایل‌های متنی است و تبدیل CRLF برای رفع ناهمگونی‌های پایان خط است، بنابراین ایمنی فعال نمی‌شود؛ .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} دستور \fIgit diff\fR خود فایل‌ها را در درخت کاری تغییر نمی‌دهد، اما اغلب برای بررسی تغییراتی که قصد دارید در \fIgit add\fR بعدی اضافه کنید اجرا می‌شود؛ برای تشخیص زودهنگام مشکلات، ایمنی فعال می‌شود\&. .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBworking-tree-encoding\fR .RS 4 .sp ابزار Git فایل‌های کدگذاری‌شده در ASCII یا یکی از ابرمجموعه‌های آن (مانند UTF\-8، ISO\-8859\-1 و \&...) را به عنوان فایل متنی می‌شناسد\&. فایل‌های کدگذاری‌شده در برخی کدگذاری‌های دیگر (مانند UTF\-16) به عنوان باینری تفسیر می‌شوند و در نتیجه ابزارهای پردازش متن توکار Git (مانند \fIgit diff\fR) و اکثر رابط‌های وب Git به طور پیش‌فرض محتوای این فایل‌ها را نمایش نمی‌دهند\&. .sp در این موارد می‌توانید با استفاده از مشخصهٔ \fBworking\-tree\-encoding\fR کدگذاری یک فایل در شاخهٔ کاری را به Git اطلاع دهید\&. اگر فایلی با این مشخصه به Git اضافه شود، Git محتوا را از کدگذاری مشخص‌شده به UTF\-8 بازکدگذاری (re\-encode) می‌کند\&. در نهایت، محتوای کدگذاری‌شده در UTF\-8 را در ساختار داده‌های داخلی خود (به نام "index") ذخیره می‌کند\&. هنگام دریافت (checkout)، محتوا مجدداً به کدگذاری مشخص‌شده تبدیل می‌شود\&. .sp لطفاً توجه داشته باشید که استفاده از مشخصهٔ \fBworking\-tree\-encoding\fR ممکن است چالش‌هایی به همراه داشته باشد: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} پیاده‌سازی‌های جایگزین Git (مانند JGit یا libgit2) و نگارش‌های قدیمی‌تر Git (تا مارس ۲۰۱۸) از مشخصهٔ \fBworking\-tree\-encoding\fR پشتیبانی نمی‌کنند\&. اگر تصمیم دارید از این مشخصه در مخزن خود استفاده کنید، اکیداً توصیه می‌شود مطمئن شوید تمام کلاینت‌هایی که با مخزن کار می‌کنند از آن پشتیبانی می‌نمایند\&. .sp به عنوان مثال، فایل‌های منابع Microsoft Visual Studio با پسوند (\fB*\&.rc\fR) یا اسکریپت‌های PowerShell با پسوند (\fB*\&.ps1\fR) گاهی به صورت UTF\-16 کدگذاری می‌شوند\&. اگر \fB*\&.ps1\fR را به عنوان UTF\-16 اعلان کنید و فایل \fBfoo\&.ps1\fR را با یک کلاینت پشتیبانی‌کننده از \fBworking\-tree\-encoding\fR اضافه کنید، \fBfoo\&.ps1\fR به صورت داخلی به شکل UTF\-8 ذخیره می‌شود\&. کلاینتی که از این مشخصه پشتیبانی نمی‌کند، فایل \fBfoo\&.ps1\fR را به عنوان یک فایل UTF\-8 دریافت می‌کند که معمولاً برای کاربران این فایل مشکل ایجاد خواهد کرد\&. .sp اگر کلاینتی که از این مشخصه پشتیبانی نمی‌کند فایل جدید \fBbar\&.ps1\fR را اضافه کند، فایل به همان صورت در مخزن ذخیره می‌شود (احتمالاً UTF\-16)\&. کلاینت با قابلیت پشتیبانی، محتوای داخلی را UTF\-8 فرض کرده و تلاش می‌کند آن را به UTF\-16 تبدیل کند که این عملیات با خطا مواجه خواهد شد\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} بازکدگذاری محتوا به کدگذاری‌های غیر UTF می‌تواند منجر به خطا شود زیرا ممکن است تبدیل در رفت و برگشت به UTF\-8 ایمن نباشد\&. اگر مشکوک هستید که کدگذاری شما ایمن نیست، آن را به \fBcore\&.checkRoundtripEncoding\fR اضافه کنید تا Git آن را بررسی کند (به \fBgit-config\fR(1) مراجعه کنید)\&. کدگذاری SHIFT\-JIS (مجموعه نویسه‌های ژاپنی) دارای مشکلات تبدیل رفت و برگشت با UTF\-8 است و به طور پیش‌فرض بررسی می‌شود\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} بازکدگذاری محتوا به منابع پردازشی نیاز دارد که ممکن است برخی از عملیات‌های Git را کند کند (مانند \fIgit checkout\fR یا \fIgit add\fR)\&. .RE .sp از مشخصهٔ \fBworking\-tree\-encoding\fR تنها در صورتی استفاده کنید که نمی‌توانید فایل را با کدگذاری UTF\-8 ذخیره کنید و می‌خواهید Git بتواند محتوا را به عنوان متن پردازش کند\&. .sp به عنوان مثال، اگر فایل‌های \fI*\&.ps1\fR شما به صورت UTF\-16 با نشانگر ترتیب بایت‌ها (BOM) هستند و می‌خواهید Git تبدیل خودکار پایان خط را بر اساس بستر سیستم شما انجام دهد، از مشخصه‌های زیر استفاده کنید: .sp .if n \{\ .RS 4 .\} .nf *\&.ps1 text working\-tree\-encoding=UTF\-16 .fi .if n \{\ .RE .\} .sp .sp اگر فایل‌های \fI*\&.ps1\fR به صورت UTF\-16 little endian بدون BOM هستند و می‌خواهید Git از پایان خطوط ویندوز در شاخهٔ کاری استفاده کند، از مشخصه‌های زیر استفاده کنید (در صورت نیاز به BOM از \fBUTF\-16LE\-BOM\fR به جای \fBUTF\-16LE\fR استفاده کنید)\&. لطفاً توجه داشته باشید برای جلوگیری از ابهام، تعریف صریح پایان خطوط با \fBeol\fR هنگام استفاده از \fBworking\-tree\-encoding\fR اکیداً توصیه می‌شود\&. .sp .if n \{\ .RS 4 .\} .nf *\&.ps1 text working\-tree\-encoding=UTF\-16LE eol=crlf .fi .if n \{\ .RE .\} .sp .sp می‌توانید فهرست تمام کدگذاری‌های موجود در بستر خود را با دستور زیر مشاهده کنید: .sp .if n \{\ .RS 4 .\} .nf iconv \-\-list .fi .if n \{\ .RE .\} .sp .sp اگر از کدگذاری یک فایل اطلاعی ندارید، می‌توانید با دستور \fBfile\fR آن را حدس بزنید: .sp .if n \{\ .RS 4 .\} .nf file foo\&.ps1 .fi .if n \{\ .RE .\} .sp .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBident\fR .RS 4 .sp هنگامی که مشخصهٔ \fBident\fR برای یک مسیر تنظیم شود، Git هنگام دریافت عبارت \fB$Id$\fR را در شیء blob با \fB$Id:\fR و به دنبال آن نام شیء blob با ۴۰ نویسهٔ هگزادسیمال و یک علامت دلار \fB$\fR جایگزین می‌کند\&. هر توالی بایتی که با \fB$Id:\fR شروع و با \fB$\fR در فایل درخت کاری پایان یابد، هنگام ثبت با \fB$Id$\fR جایگزین می‌شود\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBfilter\fR .RS 4 .sp مشخصهٔ \fBfilter\fR را می‌توان روی یک مقدار رشته‌ای تنظیم کرد که نام یک گردانندهٔ فیلتر (filter driver) مشخص‌شده در پیکربندی را تعیین می‌کند\&. .sp یک گردانندهٔ فیلتر شامل یک دستور \fBclean\fR و یک دستور \fBsmudge\fR است که هر کدام می‌توانند تعریف‌نشده باقی بمانند\&. هنگام دریافت، وقتی دستور \fBsmudge\fR مشخص شده باشد، شیء blob از ورودی استاندارد به آن داده می‌شود و خروجی استاندارد آن برای به‌روزرسانی فایل در درخت کاری استفاده می‌شود\&. به طور مشابه، دستور \fBclean\fR برای تبدیل محتویات فایل درخت کاری هنگام ثبت استفاده می‌شود\&. به طور پیش‌فرض این دستورها تنها یک blob را پردازش کرده و خاتمه می‌یابند\&. اگر یک فیلتر \fBprocess\fR با اجرای طولانی به جای فیلترهای \fBclean\fR و/یا \fBsmudge\fR استفاده شود، Git می‌تواند تمام blobها را با یک بار اجرای دستور فیلتر در تمام طول عمر یک دستور Git (مانند \fBgit\fR \fBadd\fR \fB\-\-all\fR) پردازش کند\&. اگر یک فیلتر فرایندی پیکربندی شده باشد، همیشه بر فیلترهای تک‌حبابی اولویت دارد\&. بخش زیر را برای توضیحات پروتکل ارتباط با فیلتر \fBprocess\fR ببینید\&. .sp یک کاربرد پالایش محتوا، تغییر شکل آن به صورتی است که برای بستر، سیستم فایل و کاربر راحت‌تر باشد\&. برای این حالت، عبارت کلیدی "راحت‌تر بودن" است و نه "تبدیل چیزی غیرقابل استفاده به قابل استفاده"\&. به عبارت دیگر، هدف این است که اگر فردی تعریف فیلتر را لغو کرد یا برنامهٔ فیلتر مناسب را نداشت، پروژه همچنان قابل استفاده باشد\&. .sp کاربرد دیگر پالایش محتوا، ذخیره محتوایی است که نمی‌تواند مستقیماً در مخزن استفاده شود (مانند یک UUID که به محتوای واقعی خارج از Git اشاره دارد، یا محتوای رمزگذاری‌شده) و تبدیل آن به یک فرم قابل استفاده هنگام دریافت (مانند دانلود محتوای خارجی یا رمزگشایی محتوا)\&. .sp این دو فیلتر رفتار متفاوتی دارند و به طور پیش‌فرض، فیلتر به عنوان حالت اول در نظر گرفته می‌شود\&. نبودن تعریف گرداننده در پیکربندی یا خروج با وضعیت غیر صفر خطا محسوب نمی‌شود و تنها باعث عبور بدون تغییر محتوا (no\-op passthru) می‌گردد\&. .sp شما می‌توانید با تنظیم متغیر پیکربندی filter\&.\&.required روی \fBtrue\fR اعلام کنید که فیلتر محتوایی را که به خودی خود غیرقابل استفاده است به محتوای قابل استفاده تبدیل می‌کند\&. .sp نکته: هر زمان که فیلتر clean تغییر کرد، مخزن باید بازیکپارچه‌سازی شود: $ git add \-\-renormalize \&. .sp به عنوان مثال، در \&.gitattributes مشخصهٔ \fBfilter\fR را برای مسیرها تعیین می‌کنید: .sp .if n \{\ .RS 4 .\} .nf *\&.c filter=indent .fi .if n \{\ .RE .\} .sp .sp سپس در فایل \&.git/config خود پیکربندی‌های "filter\&.indent\&.clean" و "filter\&.indent\&.smudge" را تعریف می‌کنید تا جفت‌دستوری را برای تغییر محتویات برنامه‌های C هنگام ثبت (اجرای "clean") و دریافت (عدم تغییر به دلیل استفاده از "cat") مشخص کنید\&. .sp .if n \{\ .RS 4 .\} .nf [filter "indent"] clean = indent smudge = cat .fi .if n \{\ .RE .\} .sp .sp برای بهترین نتیجه، \fBclean\fR در صورت دو بار اجرا نباید خروجی خود را تغییر دهد ("clean\(->clean" باید معادل "clean" باشد)، و دستورهای متعدد \fBsmudge\fR نباید خروجی \fBclean\fR را تغییر دهند ("smudge\(->smudge\(->clean" باید معادل "clean" باشد)\&. بخش ادغام را در زیر ببینید\&. .sp فیلتر "indent" در این زمینه خوش‌رفتار است: ورودی‌ای را که از قبل تورفتگی درست دارد تغییر نمی‌دهد\&. در این حالت، عدم وجود فیلتر smudge به این معنی است که فیلتر clean \fIباید\fR خروجی خود را بدون تغییر بپذیرد\&. .sp اگر فیلتر \fIباید\fR موفق شود تا محتویات ذخیره‌شده قابل استفاده باشند، می‌توانید در پیکربندی اعلام کنید که فیلتر \fBrequired\fR است: .sp .if n \{\ .RS 4 .\} .nf [filter "crypt"] clean = openssl enc \&.\&.\&. smudge = openssl enc \-d \&.\&.\&. required .fi .if n \{\ .RE .\} .sp .sp توالی "%f" در خط فرمان فیلتر با نام فایلی که فیلتر روی آن کار می‌کند جایگزین می‌شود\&. یک فیلتر ممکن است از این برای جایگزینی کلمات کلیدی استفاده کند\&. برای مثال: .sp .if n \{\ .RS 4 .\} .nf [filter "p4"] clean = git\-p4\-filter \-\-clean %f smudge = git\-p4\-filter \-\-smudge %f .fi .if n \{\ .RE .\} .sp .sp توجه داشته باشید که "%f" نام مسیری است که روی آن کار می‌شود\&. بسته به نگارشی که فیلتر می‌شود، ممکن است فایل مربوطه روی دیسک وجود نداشته باشد یا محتوای متفاوتی داشته باشد\&. بنابراین، دستورهای smudge و clean نباید به فایل روی دیسک دسترسی پیدا کنند، بلکه باید تنها به عنوان فیلتر روی محتوای ارائه‌شده از ورودی استاندارد عمل کنند\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBفرایند فیلتر با اجرای طولانی (Long Running Filter Process)\fR .RS 4 .sp اگر دستور فیلتر (یک مقدار رشته‌ای) از طریق \fBfilter\&.\fR\fI\fR\fB\&.process\fR تعریف شود، Git می‌تواند تمام blobها را با یک بار اجرای فیلتر برای کل طول عمر یک دستور Git پردازش کند\&. این کار با استفاده از پروتکل فرایند طولانی‌مدت انجام می‌شود (که در Documentation/technical/long\-running\-process\-protocol\&.adoc شرح داده شده است)\&. .sp هنگامی که Git با اولین فایلی که نیاز به clean یا smudge دارد مواجه می‌شود، فیلتر را شروع کرده و دست‌تکانی (handshake) را انجام می‌دهد\&. در این دست‌تکانی، پیام خوش‌آمدگویی ارسال‌شده توسط Git عبارت "git\-filter\-client" است، تنها نسخهٔ ۲ پشتیبانی می‌شود، و قابلیت‌های پشتیبانی‌شده "clean"، "smudge" و "delay" هستند\&. .sp سپس Git فهرستی از جفت‌های "key=value" را که با یک بستهٔ تخلیه (flush packet) پایان می‌یابد ارسال می‌کند\&. این فهرست دست‌کم شامل دستور فیلتر و نام مسیر فایل برای فیلتر کردن نسبت به ریشهٔ مخزن خواهد بود\&. بلافاصله پس از بستهٔ تخلیه، Git محتوا را که در صفر یا چند بستهٔ pkt\-line تقسیم شده و یک بستهٔ تخلیه در انتها ارسال می‌کند\&. فیلتر نباید قبل از دریافت محتوا و بستهٔ تخلیهٔ نهایی پاسخی ارسال کند\&. همچنین مقدار "value" در جفت "key=value" می‌تواند حاوی نویسهٔ "=" باشد در حالی که کلید هرگز شامل آن نخواهد بود\&. .sp .if n \{\ .RS 4 .\} .nf packet: git> command=smudge packet: git> pathname=path/testfile\&.dat packet: git> 0000 packet: git> CONTENT packet: git> 0000 .fi .if n \{\ .RE .\} .sp .sp انتظار می‌رود فیلتر با فهرستی از جفت‌های "key=value" که با یک بستهٔ تخلیه خاتمه می‌یابد پاسخ دهد\&. اگر فیلتر با مشکلی مواجه نشود، فهرست باید شامل وضعیت "status=success" باشد\&. بلافاصله پس از این بسته‌ها، انتظار می‌رود فیلتر محتوا را در صفر یا چند بستهٔ pkt\-line و یک بستهٔ تخلیه در انتها ارسال کند\&. در نهایت، فهرست دومی از جفت‌های "key=value" که با بستهٔ تخلیه پایان می‌یابد مورد انتظار است\&. فیلتر می‌تواند وضعیت را در فهرست دوم تغییر دهد یا وضعیت را با یک فهرست خالی دست‌نخورده باقی بگذارد (که در هر صورت باید با بستهٔ تخلیه پایان یابد)\&. .sp .if n \{\ .RS 4 .\} .nf packet: git< status=success packet: git< 0000 packet: git< SMUDGED_CONTENT packet: git< 0000 packet: git< 0000 # فهرست خالی، "status=success" بدون تغییر می‌ماند! .fi .if n \{\ .RE .\} .sp .sp اگر محتوای نتیجه خالی باشد، فیلتر باید با وضعیت "success" و یک بستهٔ تخلیه پاسخ دهد تا خالی بودن محتوا را اعلام کند\&. .sp .if n \{\ .RS 4 .\} .nf packet: git< status=success packet: git< 0000 packet: git< 0000 # محتوای خالی! packet: git< 0000 # فهرست خالی، وضعیت موفقیت دست‌نخورده می‌ماند! .fi .if n \{\ .RE .\} .sp .sp در صورتی که فیلتر نتواند یا نخواهد محتوا را پردازش کند، انتظار می‌رود با وضعیت "status=error" پاسخ دهد\&. .sp .if n \{\ .RS 4 .\} .nf packet: git< status=error packet: git< 0000 .fi .if n \{\ .RE .\} .sp .sp اگر فیلتر حین پردازش با خطایی مواجه شود، می‌تواند وضعیت "error" را پس از ارسال (جزئی یا کامل) محتوا ارسال کند\&. .sp .if n \{\ .RS 4 .\} .nf packet: git< status=success packet: git< 0000 packet: git< HALF_WRITTEN_ERRONEOUS_CONTENT packet: git< 0000 packet: git< status=error packet: git< 0000 .fi .if n \{\ .RE .\} .sp .sp در صورتی که فیلتر نتواند یا نخواهد محتوای فعلی و همچنین هرگونه محتوای آینده را در طول عمر فرایند Git پردازش کند، می‌تواند در هر نقطه‌ای از پروتکل با وضعیت "status=abort" پاسخ دهد\&. .sp .if n \{\ .RS 4 .\} .nf packet: git< status=abort packet: git< 0000 .fi .if n \{\ .RE .\} .sp .sp در صورت تنظیم وضعیت "error"/"abort"، ابزار Git فرایند فیلتر را متوقف یا راه‌اندازی مجدد نمی‌کند\&. با این حال، Git کد خروج خود را بر اساس پرچم \fBfilter\&.\fR\fI\fR\fB\&.required\fR تنظیم می‌کند\&. .sp اگر فیلتر در طول ارتباط متوقف شود یا از پروتکل پیروی نکند، Git فرایند فیلتر را متوقف کرده و آن را با فایل بعدی که باید پردازش شود مجدداً راه‌اندازی می‌کند\&. بسته به پرچم \fBfilter\&.\fR\fI\fR\fB\&.required\fR، گیت آن را به عنوان خطا تفسیر خواهد کرد\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBتأخیر (Delay)\fR .RS 4 .sp اگر فیلتر از قابلیت "delay" پشتیبانی کند، Git می‌تواند پرچم "can\-delay" را پس از دستور فیلتر و نام مسیر ارسال کند\&. این پرچم نشان می‌دهد که فیلتر می‌تواند فیلتر کردن blob فعلی را به تأخیر بیندازد (مثلاً برای جبران تأخیرهای شبکه) و در پاسخ، بدون محتوا وضعیت "delayed" و یک بستهٔ تخلیه ارسال کند\&. .sp .if n \{\ .RS 4 .\} .nf packet: git> command=smudge packet: git> pathname=path/testfile\&.dat packet: git> can\-delay=1 packet: git> 0000 packet: git> CONTENT packet: git> 0000 packet: git< status=delayed packet: git< 0000 .fi .if n \{\ .RE .\} .sp .sp اگر فیلتر از قابلیت "delay" پشتیبانی کند، باید از دستور "list_available_blobs" نیز پشتیبانی کند\&. اگر Git این دستور را ارسال کند، فیلتر باید فهرستی از مسیرهای نشان‌دهندهٔ حباب‌هایی را که قبلاً به تأخیر افتاده بودند و اکنون در دسترس هستند بازگرداند\&. این فهرست باید با یک بستهٔ تخلیه و به دنبال آن وضعیت "success" که آن هم با بستهٔ تخلیه خاتمه می‌یابد بسته شود\&. اگر هیچ حبابی هنوز در دسترس نیست، فیلتر باید پاسخ را مسدود کند تا زمانی که حداقل یک حباب در دسترس قرار گیرد\&. فیلتر می‌تواند با ارسال یک فهرست خالی به Git اعلام کند که دیگر حباب با تأخیر ندارد\&. تمام حباب‌هایی که Git تا این نقطه دریافت نکرده باشد مفقود در نظر گرفته شده و منجر به خطا می‌شوند\&. .sp .if n \{\ .RS 4 .\} .nf packet: git> command=list_available_blobs packet: git> 0000 packet: git< pathname=path/testfile\&.dat packet: git< pathname=path/otherfile\&.dat packet: git< 0000 packet: git< status=success packet: git< 0000 .fi .if n \{\ .RE .\} .sp .sp پس از اینکه Git نام مسیرها را دریافت کرد، حباب‌های مربوطه را دوباره درخواست می‌کند\&. این درخواست‌ها شامل یک نام مسیر و بخش محتوای خالی هستند\&. فیلتر باید با محتوای پالایش‌شده (smudge) به شیوهٔ معمول پاسخ دهد\&. .sp .if n \{\ .RS 4 .\} .nf packet: git> command=smudge packet: git> pathname=path/testfile\&.dat packet: git> 0000 packet: git> 0000 # محتوای خالی! packet: git< status=success packet: git< 0000 packet: git< SMUDGED_CONTENT packet: git< 0000 packet: git< 0000 # فهرست خالی، وضعیت دست‌نخورده می‌ماند! .fi .if n \{\ .RE .\} .sp .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBمثال\fR .RS 4 .sp یک پیاده‌سازی نمایشی از فیلتر طولانی‌مدت را می‌توان در \fBcontrib/long\-running\-filter/example\&.pl\fR واقع در مخزن اصلی Git یافت\&. اگر فیلتر فرایندی خود را توسعه می‌دهید، متغیرهای محیطی \fBGIT_TRACE_PACKET\fR می‌توانند برای اشکال‌زدایی بسیار مفید باشند (به \fBgit\fR(1) مراجعه کنید)\&. .sp لطفاً توجه داشته باشید که نمی‌توانید از دستورهای موجود \fBfilter\&.\fR\fI\fR\fB\&.clean\fR یا \fBfilter\&.\fR\fI\fR\fB\&.smudge\fR با \fBfilter\&.\fR\fI\fR\fB\&.process\fR استفاده کنید زیرا دو مورد اول از پروتکل متفاوتی نسبت به مورد دوم استفاده می‌کنند\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBتعامل میان مشخصه‌های ثبت/دریافت\fR .RS 4 .sp در مسیر کد ثبت (check\-in)، فایل درخت کاری ابتدا با گردانندهٔ \fBfilter\fR (در صورت تعیین و تعریف گرداننده مربوطه) تبدیل می‌شود، سپس نتیجه با \fBident\fR (در صورت تعیین) پردازش شده و در نهایت با \fBtext\fR (در صورت تعیین و کاربردپذیری) پردازش می‌گردد\&. .sp در مسیر کد دریافت (check\-out)، محتوای blob ابتدا با \fBtext\fR تبدیل شده و سپس با \fBident\fR پردازش و به \fBfilter\fR تحویل داده می‌شود\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBادغام شاخه‌ها با مشخصه‌های ثبت/دریافت متفاوت\fR .RS 4 .sp اگر مشخصه‌هایی را به فایلی اضافه کرده‌اید که باعث تغییر قالب استاندارد مخزن برای آن فایل می‌شود (مانند افزودن فیلتر clean/smudge یا مشخصه‌های text/eol/ident)، ادغام مواردی که مشخصه در آن‌ها اعمال نشده معمولاً باعث تعارض‌های ادغام (merge conflicts) می‌شود\&. .sp برای جلوگیری از این تعارض‌های غیرضروری، می‌توان با تنظیم متغیر پیکربندی \fBmerge\&.renormalize\fR به Git دستور داد تا یک دریافت و ثبت مجازی را برای هر سه مرحله از فایلی که نیاز به ادغام سه‌طرفه دارد اجرا کند\&. این کار از ایجاد تعارض‌های ادغام ساختگی ناشی از تبدیل در هنگام ثبت جلوگیری می‌کند\&. .sp تا زمانی که یک "smudge\(->clean" حتی روی فایل‌هایی که از قبل فیلتر شده‌اند نتیجه‌ای یکسان با "clean" داشته باشد، این راهبرد تمام تعارض‌های مربوط به فیلتر را به طور خودکار حل می‌کند\&. فیلترهایی که این‌گونه عمل نمی‌کنند ممکن است تعارض‌های ادغام دیگری ایجاد کنند که باید به صورت دستی حل شوند\&. .RE .SS "تولید متن تفاوت‌ها (Generating diff text)" .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBdiff\fR .RS 4 .sp مشخصهٔ \fBdiff\fR بر نحوهٔ تولید تفاوت‌ها (diffs) برای فایل‌های خاص توسط Git تأثیر می‌گذارد\&. این مشخصه می‌تواند به Git بگوید که آیا یک وصله متنی تولید کند یا با مسیر به عنوان یک فایل باینری رفتار کند\&. همچنین می‌تواند بر خطی که در سرآیند تکه‌کد (hunk header) در خط \fB@@\fR \fB\-k\fR,l \fB+n\fR,m \fB@@\fR نمایش داده می‌شود تأثیر بگذارد، به Git بگوید از یک دستور خارجی برای تولید تفاوت استفاده کند، یا از Git بخواهد قبل از تولید تفاوت، فایل‌های باینری را به یک قالب متنی تبدیل کند\&. .PP تنظیم‌شده (Set) .RS 4 مسیری که مشخصهٔ \fBdiff\fR برای آن تنظیم شده است به عنوان متن در نظر گرفته می‌شود، حتی زمانی که حاوی مقادیر بایتی باشد که معمولاً در فایل‌های متنی ظاهر نمی‌شوند (مانند NUL)\&. .RE .PP تنظیم‌نشده (Unset) .RS 4 مسیری که مشخصهٔ \fBdiff\fR برای آن تنظیم نشده باشد عبارت \fBBinary\fR \fBfiles\fR \fBdiffer\fR را تولید می‌کند (یا یک وصله باینری، در صورتی که وصله‌های باینری فعال باشند)\&. .RE .PP مشخص‌نشده (Unspecified) .RS 4 مسیری که مشخصهٔ \fBdiff\fR برای آن مشخص نشده است، ابتدا محتویات آن بررسی می‌شود؛ اگر شبیه متن باشد و کوچکتری از core\&.bigFileThreshold باشد، به عنوان متن در نظر گرفته می‌شود\&. در غیر این صورت عبارت \fBBinary\fR \fBfiles\fR \fBdiffer\fR تولید می‌شود\&. .RE .PP رشته (String) .RS 4 تفاوت‌ها با استفاده از گردانندهٔ تفاوت (diff driver) مشخص‌شده نمایش داده می‌شوند\&. گزینه‌های گردانندهٔ "foo" با متغیرهای پیکربندی در بخش "diff\&.foo" فایل پیکربندی Git تعریف می‌شوند\&. .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBتعریف یک گرداننده تفاوت خارجی\fR .RS 4 .sp تعریف گرداننده تفاوت در فایل \fBgitconfig\fR انجام می‌شود و نه در فایل \fBgitattributes\fR\&. با این حال: .sp برای تعریف یک گرداننده تفاوت خارجی \fBjcdiff\fR، بخشی مانند زیر را به فایل \fB$GIT_DIR/config\fR (یا \fB$HOME/\&.gitconfig\fR) خود اضافه کنید: .sp .if n \{\ .RS 4 .\} .nf [diff "jcdiff"] command = j\-c\-diff .fi .if n \{\ .RE .\} .sp .sp هنگامی که Git نیاز به نمایش تفاوت برای مسیری با مشخصهٔ \fBdiff=jcdiff\fR دارد، دستور مشخص‌شده (\fBj\-c\-diff\fR) را با ۷ پارامتر فراخوانی می‌کند، درست مانند برنامهٔ \fBGIT_EXTERNAL_DIFF\fR\&. برای جزئیات به \fBgit\fR(1) مراجعه کنید\&. .sp اگر برنامه قادر به نادیده گرفتن برخی تغییرات است (مشابه \fBgit\fR \fBdiff\fR \fB\-\-ignore\-space\-change\fR)، گزینهٔ \fBtrustExitCode\fR را نیز روی true تنظیم کنید\&. در این حالت انتظار می‌رود در صورت یافتن تغییرات معنادار با کد خروج ۱ و در غیر این صورت با ۰ خارج شود\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBتنظیم الگوریتم تفاوت داخلی\fR .RS 4 .sp الگوریتم تفاوت را می‌توان از طریق کلید پیکربندی \fBdiff\&.algorithm\fR تنظیم کرد، اما گاهی اوقات تنظیم آن به ازای هر مسیر مفید است\&. برای مثال، ممکن است بخواهید از الگوریتم \fBminimal\fR برای فایل‌های \&.json و \fBhistogram\fR برای فایل‌های \&.c استفاده کنید\&. .sp ابتدا در \fB\&.gitattributes\fR مشخصهٔ \fBdiff\fR را به مسیرها اختصاص دهید: .sp .if n \{\ .RS 4 .\} .nf *\&.json diff= .fi .if n \{\ .RE .\} .sp .sp سپس، یک پیکربندی "diff\&.\&.algorithm" برای تعیین الگوریتم تعریف کنید؛ با انتخاب از میان \fBmyers\fR، \fBpatience\fR، \fBminimal\fR، یا \fBhistogram\fR\&. .sp .if n \{\ .RS 4 .\} .nf [diff ""] algorithm = histogram .fi .if n \{\ .RE .\} .sp .sp این الگوریتم برای خروجی‌های تفاوت کاربرمحور مانند git\-diff(1) و git\-show(1) اعمال شده و برای خروجی \fB\-\-stat\fR نیز استفاده می‌شود\&. موتور ادغام از این روش استفاده نخواهد کرد\&. .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBنکته\fR .ps -1 .br .sp اگر \fBdiff\&.\fR\fI\fR\fB\&.command\fR برای مسیری با مشخصهٔ \fBdiff=\fR\fI\fR تعریف شده باشد، به عنوان یک گرداننده تفاوت خارجی اجرا می‌شود و افزودن \fBdiff\&.\fR\fI\fR\fB\&.algorithm\fR هیچ تأثیری نخواهد داشت\&. .sp .5v .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBتعریف سرآیند تکه‌کد سفارشی (Custom Hunk-Header)\fR .RS 4 .sp هر گروه از تغییرات (به نام "hunk" یا تکه‌کد) در خروجی متنی diff با خطی به این شکل شروع می‌شود: .sp .if n \{\ .RS 4 .\} .nf @@ \-k,l +n,m @@ TEXT .fi .if n \{\ .RE .\} .sp به این خط \fIسرآیند تکه‌کد (hunk header)\fR می‌گویند\&. بخش "TEXT" به طور پیش‌فرض خطی است که با یک حرف الفبا، زیرخط (_) یا علامت دلار ($) شروع می‌شود\&. برای تغییر این الگو می‌توانید یک الگوی سفارشی تعریف کنید\&. .sp ابتدا در \&.gitattributes مشخصهٔ \fBdiff\fR را برای مسیرها تعیین کنید: .sp .if n \{\ .RS 4 .\} .nf *\&.tex diff=tex .fi .if n \{\ .RE .\} .sp .sp سپس پیکربندی "diff\&.tex\&.xfuncname" را برای تعیین یک عبارت منظم (regular expression) تعریف کنید\&. بخشی را به فایل \fB$GIT_DIR/config\fR (یا \fB$HOME/\&.gitconfig\fR) مانند زیر اضافه کنید: .sp .if n \{\ .RS 4 .\} .nf [diff "tex"] xfuncname = "^(\e\e\e\e(sub)*section\e\e{\&.*)$" .fi .if n \{\ .RE .\} .sp .sp نکته: یک سطح از بک‌اسلش‌ها توسط تجزیه‌کننده فایل پیکربندی مصرف می‌شود، بنابراین باید بک‌اسلش‌ها را دو برابر کنید\&. .sp چندین الگوی توکار برای سهولت کار وجود دارد و \fBtex\fR یکی از آن‌هاست، بنابراین نیازی نیست متن فوق را در فایل پیکربندی بنویسید (تنها کافی است آن را در \fB\&.gitattributes\fR فعال کنید)\&. الگوهای توکار زیر در دسترس هستند: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBada\fR مناسب برای کد منبع زبان Ada\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBbash\fR مناسب برای کد منبع پوستهٔ Bourne\-Again SHell\&. تعاریف توابع پوستهٔ POSIX را پوشش می‌دهد\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBbibtex\fR مناسب برای فایل‌های حاوی ارجاعات BibTeX\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBcpp\fR مناسب برای کد منبع زبان‌های C و ++C\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBcsharp\fR مناسب برای کد منبع زبان #C\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBcss\fR مناسب برای شیوه‌نامه‌های آبشاری (CSS)\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBdts\fR مناسب برای فایل‌های devicetree (DTS)\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBelixir\fR مناسب برای کد منبع زبان Elixir\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBfortran\fR مناسب برای کد منبع زبان Fortran\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBfountain\fR مناسب برای اسناد Fountain\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBgolang\fR مناسب برای کد منبع زبان Go\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBhtml\fR مناسب برای اسناد HTML/XHTML\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBjava\fR مناسب برای کد منبع زبان Java\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBkotlin\fR مناسب برای کد منبع زبان Kotlin\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBmarkdown\fR مناسب برای اسناد Markdown\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBmatlab\fR مناسب برای کد منبع زبان‌های MATLAB و Octave\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBobjc\fR مناسب برای کد منبع زبان Objective\-C\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBpascal\fR مناسب برای کد منبع زبان Pascal/Delphi\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBperl\fR مناسب برای کد منبع زبان Perl\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBphp\fR مناسب برای کد منبع زبان PHP\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBpython\fR مناسب برای کد منبع زبان Python\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBruby\fR مناسب برای کد منبع زبان Ruby\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBrust\fR مناسب برای کد منبع زبان Rust\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBscheme\fR مناسب برای اکثر لهجه‌های Lisp از جمله Scheme، Emacs Lisp، Common Lisp، و Clojure\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} \fBtex\fR مناسب برای کد منبع اسناد LaTeX\&. .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBسفارشی‌سازی تفاوت کلمه‌ای (Customizing word diff)\fR .RS 4 .sp می‌توانید قواعدی را که \fBgit\fR \fBdiff\fR \fB\-\-word\-diff\fR برای تقسیم کلمات در یک خط استفاده می‌کند با تعیین یک عبارت منظم در متغیر پیکربندی "diff\&.*\&.wordRegex" سفارشی کنید\&. برای مثال: .sp .if n \{\ .RS 4 .\} .nf [diff "tex"] wordRegex = "\e\e\e\e[a\-zA\-Z]+|[{}]|\e\e\e\e\&.|[^\e\e{}[:space:]]+" .fi .if n \{\ .RE .\} .sp .sp برای تمامی زبان‌های فهرست‌شده در بخش قبل، یک الگوی پیش‌فرض توکار ارائه شده است\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBاجرای تفاوت متنی برای فایل‌های باینری\fR .RS 4 .sp گاهی اوقات مطلوب است که تفاوت نگارش متنی تبدیل‌شده از برخی فایل‌های باینری مشاهده شود\&. برای مثال، یک سند واژه‌پرداز را می‌توان به نمایش متنی ASCII تبدیل کرد و تفاوت متن را نشان داد\&. اگرچه در این تبدیل برخی اطلاعات از دست می‌رود، اما تفاوت حاصل برای مشاهده انسان بسیار مفید است (اگرچه مستقیماً قابل اعمال نیست)\&. .sp گزینهٔ پیکربندی \fBtextconv\fR برای تعریف برنامه‌ای جهت انجام چنین تبدیلی استفاده می‌شود\&. برنامه باید یک آرگومان واحد (نام فایل) را دریافت کرده و متن حاصل را در stdout تولید کند\&. .sp برای مثال، برای نمایش تفاوت اطلاعات exif یک فایل به جای داده‌های باینری: .sp .if n \{\ .RS 4 .\} .nf [diff "jpg"] textconv = exif .fi .if n \{\ .RE .\} .sp .if n \{\ .sp .\} .RS 4 .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBنکته\fR .ps -1 .br .sp تبدیل متن معمولاً یک تبدیل یک‌طرفه است\&. این بدان معنی است که تفاوت‌های تولیدشده توسط textconv برای اعمال کردن با patch مناسب \fIنیستند\fR\&. به همین دلیل، تنها \fBgit\fR \fBdiff\fR و خانواده دستورهای \fBgit\fR \fBlog\fR تبدیل متن را انجام می‌دهند؛ دستور \fBgit\fR \fBformat\-patch\fR هرگز این خروجی را تولید نخواهد کرد\&. .sp .5v .RE .sp از آنجا که تبدیل متن می‌تواند کند باشد، Git مکانیزمی برای حافظهٔ پنهان (cache) کردن خروجی و استفاده مجدد از آن فراهم می‌کند\&. برای فعال‌سازی، متغیر "cachetextconv" را در پیکربندی گردانندهٔ تفاوت تنظیم کنید: .sp .if n \{\ .RS 4 .\} .nf [diff "jpg"] textconv = exif cachetextconv = true .fi .if n \{\ .RE .\} .sp .sp این کار نتیجهٔ اجرای "exif" را برای هر حباب به صورت نامحدود در حافظه پنهان نگه می‌دارد\&. برای پاک‌سازی دستی حافظه پنهان، می‌توانید از دستور \fBgit\fR \fBupdate\-ref\fR \fB\-d\fR \fBrefs/notes/textconv/jpg\fR استفاده کنید\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBانتخاب بین textconv و تفاوت خارجی\fR .RS 4 .sp مزیت استفاده از دستور تفاوت خارجی انعطاف‌پذیری است؛ شما مقید به تغییرات خط‌محور نیستید\&. در مقابل، textconv محدودتر است اما مزایایی دارد: .sp .RS 4 .ie n \{\ \h'-04' 1.\h'+01'\c .\} .el \{\ .sp -1 .IP " 1." 4.2 .\} سهولت استفاده: تبدیل باینری به متن اغلب بسیار ساده‌تر از نوشتن یک برنامهٔ کامل diff است\&. .RE .sp .RS 4 .ie n \{\ \h'-04' 2.\h'+01'\c .\} .el \{\ .sp -1 .IP " 2." 4.2 .\} ویژگی‌های Git diff: با انجام تبدیل، همچنان می‌توانید از قابلیت‌های رنگ‌آمیزی، word\-diff، و تفاوت‌های ترکیبی بهره‌مند شوید\&. .RE .sp .RS 4 .ie n \{\ \h'-04' 3.\h'+01'\c .\} .el \{\ .sp -1 .IP " 3." 4.2 .\} حافظهٔ پنهان: قابلیت کش textconv سرعت تکرار تفاوت‌ها در دستورهایی نظیر \fBgit\fR \fBlog\fR \fB\-p\fR را افزایش می‌دهد\&. .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBنشانه‌گذاری فایل‌ها به عنوان باینری\fR .RS 4 .sp ساده‌ترین راه برای نشانه‌گذاری یک فایل به عنوان باینری، لغو تنظیم مشخصهٔ diff در فایل \fB\&.gitattributes\fR است: .sp .if n \{\ .RS 4 .\} .nf *\&.ps \-diff .fi .if n \{\ .RE .\} .sp .sp این کار باعث می‌شود Git به جای تفاوت معمولی، عبارت \fBBinary\fR \fBfiles\fR \fBdiffer\fR را تولید کند\&. .sp با این حال اگر می‌خواهید هم‌زمان از \fBtextconv\fR استفاده کنید و با فایل به عنوان باینری رفتار شود، از گزینهٔ \fBdiff\&.*\&.binary\fR در پیکربندی استفاده کنید: .sp .if n \{\ .RS 4 .\} .nf [diff "ps"] textconv = ps2ascii binary = true .fi .if n \{\ .RE .\} .sp .RE .SS "انجام یک ادغام سه‌طرفه (Performing a three\-way merge)" .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBmerge\fR .RS 4 .sp مشخصهٔ \fBmerge\fR نحوهٔ ادغام سه نگارش از یک فایل را هنگام نیاز به ادغام در سطح فایل در طول \fBgit\fR \fBmerge\fR و سایر دستورها مانند \fBgit\fR \fBrevert\fR و \fBgit\fR \fBcherry\-pick\fR تعیین می‌کند\&. .PP تنظیم‌شده (Set) .RS 4 از گردانندهٔ ادغام سه‌طرفه توکار به روشی مشابه دستور \fImerge\fR مجموعهٔ \fBRCS\fR استفاده می‌شود\&. این حالت برای فایل‌های متنی معمولی مناسب است\&. .RE .PP تنظیم‌نشده (Unset) .RS 4 نگارش شاخهٔ فعلی را به عنوان نتیجهٔ ادغام موقت در نظر می‌گیرد و اعلام می‌کند که ادغام دارای تعارض است\&. این حالت برای فایل‌های باینری بدون معناشناسی ادغام مشخص مناسب است\&. .RE .PP مشخص‌نشده (Unspecified) .RS 4 به طور پیش‌فرض، از همان گردانندهٔ توکار سه‌طرفه مانند حالت تنظیم‌شده استفاده می‌کند\&. با این حال متغیر پیکربندی \fBmerge\&.default\fR می‌تواند نام گردانندهٔ دیگری را برای این مسیرها مشخص کند\&. .RE .PP رشته (String) .RS 4 ادغام سه‌طرفه با استفاده از گردانندهٔ ادغام سفارشی مشخص‌شده انجام می‌شود\&. گردانندهٔ توکار را می‌توان صراحتاً با "text" و گردانندهٔ "نگه‌داشتن شاخهٔ فعلی" را با "binary" درخواست کرد\&. .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBگرداننده‌های ادغام توکار\fR .RS 4 .sp چندین گردانندهٔ سطح‌پایین توکار وجود دارند که می‌توان از طریق مشخصهٔ \fBmerge\fR آن‌ها را درخواست کرد: .PP text .RS 4 ادغام معمولی سه‌طرفه برای فایل‌های متنی\&. نواحی دارای تعارض با نشانگرهای تعارض <<<<<<<، \fB=======\fR و >>>>>>> مشخص می‌شوند\&. .RE .PP binary .RS 4 نگارش شاخهٔ شما را در درخت کاری حفظ می‌کند اما مسیر را در حالت تعارض باقی می‌گذارد تا کاربر آن را حل کند\&. .RE .PP union .RS 4 ادغام متنی سه‌طرفه را اجرا می‌کند اما خطوط هر دو نگارش را به جای درج نشانگرهای تعارض اضافه می‌کند\&. اگر از عواقب آن آگاهی ندارید از این گزینه استفاده نکنید\&. .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBتعریف یک گرداننده ادغام سفارشی\fR .RS 4 .sp تعریف یک گرداننده ادغام در فایل \fB\&.git/config\fR انجام می‌شود\&. .sp برای تعریف یک گردانندهٔ سفارشی \fBfilfre\fR، بخشی مانند زیر را اضافه کنید: .sp .if n \{\ .RS 4 .\} .nf [merge "filfre"] name = feel\-free merge driver driver = filfre %O %A %B %L %P recursive = binary .fi .if n \{\ .RE .\} .sp .sp متغیر \fBmerge\&.*\&.name\fR یک نام قابل خواندن برای انسان به گرداننده می‌دهد\&. .sp مقدار متغیر \(oqmerge\&.*\&.driver` برای ساخت فرمانی جهت اجرا روی نگارش نیای مشترک (\fB%O\fR)، نگارش فعلی (\fB%A\fR) و نگارش شاخهٔ دیگر (\fB%B\fR) استفاده می‌شود\&. این سه نشانگر با نام فایل‌های موقتی جایگزین می‌شوند\&. علاوه بر این، \fB%L\fR با اندازه نشانگر تعارض جایگزین می‌شود\&. .sp انتظار می‌رود گرداننده نتیجه ادغام را با بازنویسی در فایل \fB%A\fR ذخیره کرده و در صورت ادغام موفقیت‌آمیز با وضعیت صفر، یا در صورت وجود تعارض با وضعیت غیر صفر خارج شود\&. .sp متغیر \fBmerge\&.*\&.recursive\fR مشخص می‌کند هنگام ادغام داخلی بین نیاهای مشترک از چه گردانندهٔ دیگری استفاده شود\&. .sp گرداننده می‌تواند نام مسیر نتیجه ادغام را از طریق \fB%P\fR دریافت کند\&. برچسب‌های تعارض نیز با \fB%S\fR، \fB%X\fR و \fB%Y\fR قابل ارسال هستند\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBconflict-marker-size\fR .RS 4 .sp این مشخصه طول نشانگرهای تعارض باقی‌مانده در فایل درخت کاری را در طول ادغام کنترل می‌کند (پیش‌فرض ۷ نویسه است)\&. .sp .if n \{\ .RS 4 .\} .nf Documentation/git\-merge\&.adoc conflict\-marker\-size=32 .fi .if n \{\ .RE .\} .sp .RE .SS "بررسی خطاهای فاصله‌های خالی (Checking whitespace errors)" .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBwhitespace\fR .RS 4 .sp متغیر پیکربندی \fBcore\&.whitespace\fR به شما امکان می‌دهد آنچه را که \fIdiff\fR و \fIapply\fR باید خطای فاصله در نظر بگیرند تعریف کنید (به \fBgit-config\fR(1) مراجعه کنید)\&. این مشخصه کنترل دقیق‌تری برای هر مسیر فراهم می‌کند\&. .PP تنظیم‌شده (Set) .RS 4 تمام انواع خطاهای بالقوه فاصلهٔ شناخته‌شده برای Git را شناسایی می‌کند\&. .RE .PP تنظیم‌نشده (Unset) .RS 4 هیچ موردی را به عنوان خطا شناسایی نمی‌کند\&. .RE .PP مشخص‌نشده (Unspecified) .RS 4 از مقدار متغیر پیکربندی \fBcore\&.whitespace\fR استفاده می‌کند\&. .RE .PP رشته (String) .RS 4 فهرستی از مشکلات رایج فاصله را که با کاما جدا شده‌اند با همان قالب متغیر \fBcore\&.whitespace\fR مشخص می‌کند\&. .RE .RE .SS "ایجاد بایگانی (Creating an archive)" .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBexport-ignore\fR .RS 4 .sp فایل‌ها و شاخه‌های دارای مشخصهٔ \fBexport\-ignore\fR به فایل‌های بایگانی اضافه نخواهند شد\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBexport-subst\fR .RS 4 .sp اگر مشخصهٔ \fBexport\-subst\fR برای فایلی تنظیم شده باشد، Git هنگام افزودن این فایل به بایگانی چندین جای‌نگهدار (placeholder) را بسط می‌دهد\&. جای‌نگهدارها مشابه گزینهٔ \fB\-\-pretty=format:\fR در \fBgit-log\fR(1) هستند، با این تفاوت که باید در فایل به صورت \fB$Format:PLACEHOLDERS$\fR قرار گیرند (مانند \fB$Format:%H$\fR برای هش کامیت)\&. .RE .SS "بسته‌بندی اشیاء (Packing objects)" .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBdelta\fR .RS 4 .sp برای حباب‌های مربوط به مسیرهایی با مشخصهٔ \fBdelta\fR تنظیم‌شده روی false، فشرده‌سازی دلتا انجام نخواهد شد\&. .RE .SS "مشاهده فایل‌ها در ابزارهای گرافیکی (Viewing files in GUI tools)" .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBencoding\fR .RS 4 .sp مقدار این مشخصه، کدگذاری نویسه‌ای را تعیین می‌کند که باید توسط ابزارهای رابط کاربری گرافیکی (مانند \fBgitk\fR(1) و \fBgit-gui\fR(1)) برای نمایش محتویات فایل مربوطه استفاده شود\&. .sp اگر این مشخصه تنظیم نشده باشد یا مقدار نامعتبر داشته باشد، از متغیر پیکربندی \fBgui\&.encoding\fR استفاده می‌شود\&. .RE .SH "استفاده از مشخصه‌های ماکرو (USING MACRO ATTRIBUTES)" .sp شما نمی‌خواهید تبدیل پایان خط یا تفاوت متنی برای فایل‌های باینری اعمال شود\&. ممکن است نیاز باشد بنویسید: .sp .if n \{\ .RS 4 .\} .nf *\&.jpg \-text \-diff .fi .if n \{\ .RE .\} .sp .sp اما داشتن مشخصه‌های فراوان خسته‌کننده می‌شود\&. با استفاده از مشخصه‌های ماکرو می‌توانید مشخصه‌ای تعریف کنید که هنگام تنظیم، چند مشخصهٔ دیگر را هم‌زمان تنظیم یا لغو کند\&. سیستم دارای ماکروی توکار \fBbinary\fR است: .sp .if n \{\ .RS 4 .\} .nf *\&.jpg binary .fi .if n \{\ .RE .\} .sp .sp تنظیم مشخصهٔ "binary" باعث لغو مشخصه‌های "text" و "diff" می‌شود\&. توجه داشته باشید مشخصه‌های ماکرو تنها می‌توانند در حالت "Set" باشند\&. .SH "تعریف مشخصه‌های ماکرو (DEFINING MACRO ATTRIBUTES)" .sp مشخصه‌های ماکروی سفارشی را فقط می‌توان در فایل‌های سطح بالای gitattributes تعریف کرد (\fB$GIT_DIR/info/attributes\fR، فایل \fB\&.gitattributes\fR در ریشهٔ درخت کاری، یا فایل‌های سراسری/سیستمی)\&. ماکروی توکار "binary" معادل عبارت زیر است: .sp .if n \{\ .RS 4 .\} .nf [attr]binary \-diff \-merge \-text .fi .if n \{\ .RE .\} .sp .SH "نکات (NOTES)" .sp ابزار Git هنگام دسترسی به فایل \fB\&.gitattributes\fR در درخت کاری از پیوندهای نمادین (symbolic links) پیروی نمی‌کند\&. .SH "مثال‌ها (EXAMPLES)" .sp اگر این سه فایل \fBgitattributes\fR را داشته باشید: .sp .if n \{\ .RS 4 .\} .nf (در $GIT_DIR/info/attributes) a* foo !bar \-baz (در \&.gitattributes) abc foo bar baz (در t/\&.gitattributes) ab* merge=filfre abc \-foo \-bar *\&.c frotz .fi .if n \{\ .RE .\} .sp .sp مشخصه‌های اختصاص داده شده به مسیر \fBt/abc\fR به صورت زیر محاسبه می‌شوند: .sp .RS 4 .ie n \{\ \h'-04' 1.\h'+01'\c .\} .el \{\ .sp -1 .IP " 1." 4.2 .\} با بررسی \fBt/\&.gitattributes\fR (که در همان شاخهٔ مسیر است)، خط اول مطابقت دارد و \fBmerge\fR تنظیم می‌شود\&. خط دوم نیز مطابقت دارد و \fBfoo\fR و \fBbar\fR لغو می‌شوند\&. .RE .sp .RS 4 .ie n \{\ \h'-04' 2.\h'+01'\c .\} .el \{\ .sp -1 .IP " 2." 4.2 .\} سپس \fB\&.gitattributes\fR (شاخهٔ والد) بررسی می‌شود\&. خط اول مطابقت دارد، اما فایل \fBt/\&.gitattributes\fR قبلاً وضعیت \fBmerge\fR، \fBfoo\fR و \fBbar\fR را تعیین کرده است؛ بنابراین \fBfoo\fR و \fBbar\fR بدون تغییر می‌مانند و مشخصهٔ \fBbaz\fR تنظیم می‌شود\&. .RE .sp .RS 4 .ie n \{\ \h'-04' 3.\h'+01'\c .\} .el \{\ .sp -1 .IP " 3." 4.2 .\} در نهایت \fB$GIT_DIR/info/attributes\fR بررسی می‌شود که تنظیمات درون‌درخت را بازنویسی می‌کند\&. خط اول مطابقت دارد و \fBfoo\fR تنظیم می‌شود، \fBbar\fR به حالت نامشخص برمی‌گردد، و \fBbaz\fR لغو می‌شود\&. .RE .sp در نتیجه، مشخصه‌های اختصاص‌یافته به \fBt/abc\fR به این صورت خواهد بود: .sp .if n \{\ .RS 4 .\} .nf foo set to true bar unspecified baz set to false merge set to string value "filfre" frotz unspecified .fi .if n \{\ .RE .\} .sp .SH "همچنین ببینید (SEE ALSO)" .sp \fBgit-check-attr\fR(1)\&. .SH "گیت (GIT)" .sp بخشی از مجموعهٔ \fBgit\fR(1)