Chapters ▾ 2nd Edition

8.1 سفارشی‌سازی Git (Customizing Git) - پیکربندی گیت (Git Configuration)

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

پیکربندی گیت (Git Configuration)

همان‌طور که به‌طور خلاصه در شروع به کار (getting started) خواندید، می‌توانید تنظیمات پیکربندی گیت را با دستور git config مشخص کنید. یکی از اولین کارهایی که انجام دادید، تنظیم نام و آدرس ایمیل‌تان بود:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

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

ابتدا یک مرور سریع: گیت از مجموعه‌ای فایل پیکربندی برای تعیین رفتار غیرپیش‌فرض که ممکن است بخواهید، استفاده می‌کند. اولین جایی که گیت به دنبال این مقادیر می‌گردد، فایل سیستمی [path]/etc/gitconfig است که شامل تنظیماتی است که برای همه کاربران سیستم و تمام مخازن آن‌ها اعمال می‌شود. اگر گزینه --system را به دستور git config بدهید، به‌طور خاص این فایل را می‌خواند و می‌نویسد.

گام بعدی، فایل ~/.gitconfig (یا ~/.config/git/config) است که مخصوص هر کاربر است. می‌توانید با دادن گزینه --global به گیت بگویید این فایل را بخواند و بنویسد.

در نهایت، گیت به دنبال مقادیر پیکربندی در فایل پیکربندی موجود در پوشه گیت (.git/config) مخزنی که در حال حاضر استفاده می‌کنید می‌گردد. این مقادیر مختص همان مخزن خاص هستند و معادل دادن گزینه --local به دستور git config است. اگر مشخص نکنید که کدام سطح را می‌خواهید تنظیم کنید، این سطح به‌طور پیش‌فرض انتخاب می‌شود.

هر یک از این «سطوح» (سیستمی، سراسری، محلی) مقادیر سطوح قبلی را بازنویسی می‌کنند، به‌طوری‌که مقادیر موجود در .git/config بر مقادیر [path]/etc/gitconfig اولویت دارند.

یادداشت

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

پیکربندی پایهٔ کلاینت (Basic Client Configuration)

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

$ man git-config

این دستور تمام گزینه‌های موجود را با جزئیات زیادی فهرست می‌کند. شما همچنین می‌توانید این مطالب مرجع را در https://git-scm.com/docs/git-config پیدا کنید.

یادداشت

برای موارد استفاده پیشرفته ممکن است بخواهید "شامل‌های شرطی" را در مستندات ذکر شده در بالا جستجو کنید.

ویرایشگر اصلی (core.editor)

به طور پیش‌فرض، گیت از ویرایشگری که به عنوان ویرایشگر متنی پیش‌فرض خود از طریق یکی از متغیرهای محیطی شل VISUAL یا EDITOR تنظیم کرده‌اید استفاده می‌کند، و در غیر این صورت به ویرایشگر vi بازمی‌گردد تا پیام‌های کامیت و تگ شما را ایجاد و ویرایش کند. برای تغییر این پیش‌فرض به گزینه‌ای دیگر، می‌توانید از تنظیم core.editor استفاده کنید:

$ git config --global core.editor emacs

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

قالب کامیت (commit.template)

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

برای مثال، فرض کنید یک فایل قالب در مسیر ~/.gitmessage.txt دارید که به این صورت است:

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]

توجه کنید چگونه این قالب کامیت به کامیت‌کننده یادآوری می‌کند که خط موضوع را کوتاه نگه دارد (برای خروجی git log --oneline)، جزئیات بیشتری را در زیر آن اضافه کند، و در صورت وجود، به شماره تیکت مسئله یا باگ ردیاب اشاره نماید.

برای اینکه به گیت بگویید این فایل را به عنوان پیام پیش‌فرضی که هنگام اجرای git commit در ویرایشگر ظاهر می‌شود استفاده کند، مقدار پیکربندی commit.template را تنظیم کنید:

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

سپس ویرایشگر شما باز می‌شود و چیزی شبیه به این برای پیام تعهد موقت شما هنگام انجام commit نمایش داده می‌شود:

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C

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

صفحه‌بند اصلی (core.pager)

این تنظیم تعیین می‌کند که هنگام نمایش خروجی‌هایی مانند log و diff، از کدام صفحه‌بند (pager) استفاده شود. می‌توانید آن را روی more یا صفحه‌بند مورد علاقه خود تنظیم کنید (به طور پیش‌فرض less است)، یا با تنظیم آن روی رشته خالی، آن را غیرفعال کنید:

$ git config --global core.pager ''

اگر این دستور را اجرا کنید، Git تمام خروجی تمام دستورات را چاپ می‌کند، بدون توجه به طول آن‌ها.

کلید امضای کاربر (user.signingkey)

اگر در حال ساختن تگ‌های Annotated امضا شده هستید (همانطور که در Signing Your Work (امضای کارهای شما) بحث شده)، تنظیم کلید امضای GPG خود به عنوان یک تنظیمات پیکربندی کار را آسان‌تر می‌کند. شناسه کلید خود را به این شکل تنظیم کنید:

$ git config --global user.signingkey <gpg-key-id>

حال می‌توانید بدون اینکه هر بار در دستور git tag کلید خود را مشخص کنید، تگ‌ها را امضا کنید:

$ git tag -s <tag-name>

core.excludesfile

می‌توانید الگوهایی را در فایل .gitignore پروژه خود قرار دهید تا Git آن‌ها را به عنوان فایل‌های ردیابی‌نشده نبیند یا هنگام اجرای git add آن‌ها را برای مرحله‌بندی در نظر نگیرد، همانطور که در فایل های ایگنور شده (Ignoring Files) توضیح داده شده.

اما گاهی می‌خواهید بعضی فایل‌ها را برای همه مخازنی که با آن‌ها کار می‌کنید نادیده بگیرید. اگر سیستم شما macOS است، احتمالا با فایل‌های .DS_Store آشنا هستید. اگر ویرایشگر مورد علاقه شما Emacs یا Vim است، با فایل‌هایی که با ~ یا .swp پایان می‌یابند آشنایید.

این تنظیم به شما امکان می‌دهد یک نوع فایل .gitignore سراسری بنویسید. اگر یک فایل ~/.gitignore_global با این محتویات ایجاد کنید:

*~
.*.swp
.DS_Store

…و دستور git config --global core.excludesfile ~/.gitignore_global را اجرا کنید، Git دیگر هرگز شما را درباره این فایل‌ها اذیت نخواهد کرد.

اصلاح خودکار راهنما (help.autocorrect)

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

$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.

The most similar command is
    checkout

گیت به طور مفید سعی می‌کند بفهمد منظورتان چه بوده است، اما همچنان از انجام آن خودداری می‌کند. اگر help.autocorrect را روی ۱ تنظیم کنید، گیت در واقع این دستور را برای شما اجرا خواهد کرد:

$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...

به آن "۰.۱ ثانیه" توجه کنید. help.autocorrect در واقع یک عدد صحیح است که دهم ثانیه را نشان می‌دهد. بنابراین اگر آن را روی ۵۰ تنظیم کنید، گیت به شما ۵ ثانیه فرصت می‌دهد تا قبل از اجرای دستور تصحیح‌شده خودکار، نظر خود را تغییر دهید.

رنگ ها در گیت (Colors in Git)

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

رنگ‌بندی رابط کاربری (color.ui)

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

$ git config --global color.ui false

تنظیم پیش‌فرض auto است که خروجی را وقتی مستقیماً به ترمینال می‌رود رنگی می‌کند، اما کدهای کنترل رنگ را وقتی خروجی به لوله یا فایل هدایت می‌شود، حذف می‌کند.

همچنین می‌توانید آن را روی always تنظیم کنید تا تفاوت بین ترمینال‌ها و لوله‌ها نادیده گرفته شود. شما به ندرت این را می‌خواهید؛ در بیشتر سناریوها، اگر کدهای رنگی در خروجی هدایت‌شده خود می‌خواهید، می‌توانید به جای آن پرچم --color را به دستور گیت پاس دهید تا آن را مجبور به استفاده از کدهای رنگی کند. تنظیمات پیش‌فرض تقریباً همیشه همان چیزی است که می‌خواهید.

تنظیمات رنگ‌بندی عمومی (color.*)

اگر می‌خواهید در مورد اینکه کدام دستورات رنگی هستند و چگونه، دقیق‌تر باشید، گیت تنظیمات رنگ‌آمیزی خاص فعل را ارائه می‌دهد. هر یک از این موارد را می‌توان روی true، false یا always تنظیم کرد:

color.branch
color.diff
color.interactive
color.status

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

$ git config --global color.diff.meta "blue black bold"

می‌توانید رنگ را روی هر یک از مقادیر زیر تنظیم کنید: عادی، سیاه، قرمز، سبز، زرد، آبی، سرخابی، فیروزه‌ای یا سفید. اگر می‌خواهید ویژگی‌ای مانند پررنگ در مثال قبلی داشته باشید، می‌توانید از بین bold (پررنگ)، dim (کم‌نور)، ul (زیرخط)، blink (چشمک زدن) و reverse (جابجایی پیش‌زمینه و پس‌زمینه) انتخاب کنید.

ابزارهای خارجی ادغام و مقایسه (External Merge and Diff Tools)

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

اگر می‌خواهید این را امتحان کنید، P4Merge روی تمام پلتفرم‌های اصلی کار می‌کند، بنابراین باید بتوانید این کار را انجام دهید. در مثال‌هایی که روی سیستم‌های macOS و لینوکس کار می‌کنند، از نام مسیرها استفاده خواهیم کرد؛ برای ویندوز، باید /usr/local/bin را به مسیر اجرایی در محیط خود تغییر دهید.

برای شروع, download P4Merge from Perforce. بعداً، اسکریپت‌های پوشش خارجی را برای اجرای دستورات خود راه‌اندازی خواهید کرد. ما از مسیر macOS برای فایل اجرایی استفاده خواهیم کرد؛ در سیستم‌های دیگر، این مسیر جایی خواهد بود که باینری p4merge شما نصب شده است. یک اسکریپت پوشش ادغام به نام extMerge ایجاد کنید که با تمام آرگومان‌های ارائه شده باینری شما را فراخوانی می‌کند:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
 روکش diff بررسی می‌کند که هفت آرگومان فراهم شده باشند و دو تا از آن‌ها را به اسکریپت merge شما منتقل می‌کند.
به طور پیش‌فرض، گیت آرگومان‌های زیر را به برنامه diff منتقل می‌کند:
path old-file old-hex old-mode new-file new-hex new-mode

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

$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

همچنین باید مطمئن شوید این ابزارها قابل اجرا (executable) هستند:

$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff

حالا می‌توانید فایل پیکربندی خود را طوری تنظیم کنید که از ابزارهای اختصاصی حل تداخلات merge و نمایش diff شما استفاده کند. این کار به چند تنظیم اختصاصی نیاز دارد: merge.tool برای گفتن به گیت که از چه استراتژی‌ای استفاده کند، mergetool.<tool>.cmd برای مشخص کردن چگونگی اجرای فرمان، mergetool.<tool>.trustExitCode برای اطلاع به گیت که آیا کد خروج آن برنامه نشان‌دهنده حل موفقیت‌آمیز merge است یا خیر، و diff.external برای معرفی فرمانی که برای عملیات diff اجرا شود. بنابراین، شما می‌توانید چهار فرمان تنظیمات را اجرا کنید:

$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
  'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff

یا می‌توانید فایل ~/.gitconfig خود را ویرایش کنید و این خطوط را اضافه کنید:

[merge]
  tool = extMerge
[mergetool "extMerge"]
  cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
  trustExitCode = false
[diff]
  external = extDiff

بعد از انجام همه این تنظیمات، اگر فرمان‌های diff مانند این را اجرا کنید:

$ git diff 32d1776b1^ 32d1776b1

به جای نمایش خروجی diff در خط فرمان، گیت P4Merge را اجرا می‌کند که چیزی شبیه به این خواهد بود:

P4Merge
نمودار 168. P4Merge

اگر تلاش کنید دو شاخه را merge کنید و بعداً با تعارضات merge مواجه شوید، می‌توانید فرمان git mergetool را اجرا کنید؛ این فرمان P4Merge را راه‌اندازی می‌کند تا از طریق آن واسط گرافیکی تعارضات را حل کنید.

نکتهٔ خوب این راه‌حلِ روکشی این است که می‌توانید به راحتی ابزارهای diff و merge خود را تغییر دهید. برای مثال، برای تغییر ابزارهای extDiff و extMerge به KDiff3، کافی است فایل extMerge خود را ویرایش کنید:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

حالا گیت از ابزار KDiff3 برای نمایش diff و حل تعارضات merge استفاده خواهد کرد.

گیت به صورت پیش‌فرض برای استفاده از چندین ابزار حل تعارض دیگر نیز پیکربندی شده است بدون آنکه لازم باشد شما cmd را تنظیم کنید. برای دیدن فهرست ابزارهایی که پشتیبانی می‌کند، این را اجرا کنید:

$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
        emerge
        gvimdiff
        gvimdiff2
        opendiff
        p4merge
        vimdiff
        vimdiff2

The following tools are valid, but not currently available:
        araxis
        bc3
        codecompare
        deltawalker
        diffmerge
        diffuse
        ecmerge
        kdiff3
        meld
        tkdiff
        tortoisemerge
        xxdiff

Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.

اگر تمایلی به استفاده از KDiff3 برای نمایش diff ندارید اما می‌خواهید صرفاً برای حل تعارضات merge از آن استفاده کنید، و دستور kdiff3 در مسیر (PATH) شما قرار دارد، می‌توانید این دستور را اجرا کنید:

$ git config --global merge.tool kdiff3

اگر این را اجرا کنید و به‌جای ایجاد فایل‌های extMerge و extDiff، گیت از KDiff3 برای حل تداخل‌ها و از ابزار معمولی diff گیت برای مقایسه‌ها استفاده خواهد کرد.

قالب‌بندی و وایت اسپیس (Formatting and Whitespace)

مسائل مربوط به قالب‌بندی و فاصله‌های سفید از جمله مشکلات خسته‌کننده و ظریفی هستند که بسیاری از توسعه‌دهندگان هنگام همکاری، به‌ویژه در محیط‌های چندسکویی، با آن‌ها مواجه می‌شوند. خیلی آسان است که پَچ‌ها یا دیگر کارهای مشترک تغییرات ظریف در فاصله‌های سفید ایجاد کنند، زیرا ویرایشگرها این تغییرات را به‌صورت پنهانی اعمال می‌کنند، و اگر فایل‌های شما به سیستمی با ویندوز برسند ممکن است پایان خط‌ها (line endings) جایگزین شوند. گیت چند گزینهٔ پیکربندی برای کمک به این مسائل دارد.

تبدیل خودکار پایان خط‌ها (core.autocrlf)

اگر روی ویندوز برنامه‌نویسی می‌کنید و با افرادی کار می‌کنید که روی ویندوز نیستند (یا بالعکس)، احتمالاً دیر یا زود با مشکل پایان‌خط‌ها روبه‌رو خواهید شد. علت این است که ویندوز برای نشانه‌گذاری خطوط جدید از هر دو کاراکتر carriage-return و linefeed استفاده می‌کند، در حالی که macOS و لینوکس تنها از کاراکتر linefeed بهره می‌برند. این یک نکتهٔ ظریف اما بسیار آزاردهنده در کار میان‌پلتفرمی است؛ بسیاری از ویرایشگرها در ویندوز به‌صورت پنهانی پایان‌خط‌های به‌سبک LF را به CRLF تبدیل می‌کنند، یا هنگام فشردن کلید Enter هر دو کاراکتر پایان‌خط را وارد می‌کنند.

گیت می‌تواند با تبدیل خودکار پایان‌خط‌های CRLF به LF هنگام افزودن فایل به ایندکس و بالعکس هنگام بیرون‌کشیدن کد به سیستم فایل شما با این وضعیت کنار بیاید. می‌توانید این قابلیت را با تنظیم core.autocrlf فعال کنید. اگر روی ماشین ویندوز هستید، آن را روی true قرار دهید — این کار هنگام بیرون‌کشیدن کد، پایان‌خط‌های LF را به CRLF تبدیل می‌کند:

$ git config --global core.autocrlf true

اگر روی سیستم لینوکس یا macOS هستید که از پایان‌خط‌های LF استفاده می‌کنند، معمولاً نمی‌خواهید گیت به‌صورت خودکار هنگام بیرون‌کشیدن فایل‌ها آن‌ها را تبدیل کند؛ با این حال اگر به‌طور تصادفی فایلی با پایان‌خط CRLF وارد شود، ممکن است بخواهید گیت آن را اصلاح کند. می‌توانید به گیت بگویید که CRLF را هنگام commit به LF تبدیل کند اما عکس این کار را انجام ندهد، با قرار دادن core.autocrlf روی input:

$ git config --global core.autocrlf input

این تنظیم باید در خروجی‌های checkout روی ویندوز پایان‌خط‌های CRLF و در macOS و لینوکس پایان‌خط‌های LF را حفظ کند.

اگر برنامه‌نویس ویندوز هستید و روی پروژه‌ای ویژهٔ ویندوز کار می‌کنید، می‌توانید این قابلیت را غیرفعال کنید و بازگشت‌خط‌ها (carriage return) را در مخزن ذخیره کنید، با تنظیم مقدار پیکربندی روی false:
$ git config --global core.autocrlf false

تنظیمات فاصله‌ها (Whitespace) اصلی (core.whitespace)

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

سه موردی که به‌طور پیش‌فرض روشن‌اند عبارت‌اند از: - blank-at-eol که به دنبال فاصله‌ها در پایان خط می‌گردد؛ - blank-at-eof که خطوط خالی در پایان فایل را تشخیص می‌دهد؛ - space-before-tab که به دنبال فاصله‌های قبل از تب در ابتدای خط می‌گردد.

سه موردی که به‌طور پیش‌فرض خاموش‌اند اما می‌توان آن‌ها را روشن کرد عبارت‌اند از: - indent-with-non-tab که به دنبال خطوطی می‌گردد که به‌جای تب با فاصله‌ها شروع شده‌اند (و توسط گزینهٔ tabwidth کنترل می‌شود)؛ - tab-in-indent که برای تب‌ها در بخش تورفتگی (indentation) خط نظارت می‌کند؛ - cr-at-eol که به Git می‌گوید وجود carriage return در انتهای خطوط مجاز است.

می‌توانید به Git بگویید کدام‌یک از این گزینه‌ها را فعال می‌خواهید با تنظیم core.whitespace روی مقادیر موردنظر، جدا‌شده با ویرگول. می‌توانید یک گزینه را با قرار دادن یک - قبل از نامش غیرفعال کنید، یا اگر بخواهید مقدار پیش‌فرض را حفظ کنید آن گزینه را اصلاً در رشتهٔ تنظیمات نیاورید. برای مثال، اگر بخواهید همهٔ گزینه‌ها به‌جز space-before-tab فعال باشند، می‌توانید این کار را انجام دهید (trailing-space به‌صورت کوتاه‌نویس هر دو گزینهٔ blank-at-eol و blank-at-eof را شامل می‌شود):

$ git config --global core.whitespace \
    trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

یا فقط بخش سفارشی‌سازی را مشخص کنید:

$ git config --global core.whitespace \
    -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

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

$ git apply --whitespace=warn <patch>

یا می‌توانید از Git بخواهید قبل از اعمال پچ تلاش کند مشکل را به‌صورت خودکار اصلاح کند:

$ git apply --whitespace=fix <patch>
 این گزینه‌ها برای دستور `git rebase` نیز اعمال می‌شوند.
اگر شما تغییراتی شامل مشکلات فاصله‌گذاری (whitespace) را کامیت کرده‌اید اما هنوز به مخزن راه دور (upstream) پوش نکرده‌اید، می‌توانید با اجرای `git rebase --whitespace=fix` اجازه دهید گیت هنگام بازنویسی پچ‌ها به‌طور خودکار مشکلات فاصله‌گذاری را اصلاح کند.

گزینه‌های پیکربندی سمت سرور گیت به اندازه سمت کلاینت زیاد نیستند، اما چند گزینهٔ جالب وجود دارد که شاید بخواهید به آن‌ها توجه کنید.

بررسی صحت اشیاء هنگام دریافت (receive.fsckObjects)

گیت قادر است بررسی کند هر آبجکت دریافتی در هنگام پوش هنوز با چکسام SHA-1 خود مطابقت دارد و به آبجکت‌های معتبر اشاره می‌کند. با این حال، این کار به‌طور پیش‌فرض انجام نمی‌شود؛ زیرا عملی نسبتاً هزینه‌بر است و ممکن است عملیات را کند کند، به‌ویژه در مخازن بزرگ یا پوش‌های حجیم. اگر می‌خواهید گیت در هر پوش سازگاری آبجکت‌ها را بررسی کند، می‌توانید با تنظیم receive.fsckObjects به true آن را مجبور به انجام این کار کنید:

$ git config --system receive.fsckObjects true

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

رد دریافت‌های غیر پیش‌رونده (receive.denyNonFastForwards)

اگر کامیت‌هایی را که قبلاً پوش کرده‌اید ری‌بیس کنید و سپس دوباره بخواهید پوش کنید، یا به‌طور کلی بخواهید کامیتی را به برنچی در راه دور پوش کنید که آن برنچ شامل آن کامیت نیست، درخواست شما رد خواهد شد. این به‌طور کلی سیاست خوبی است؛ اما در حالت ری‌بیس ممکن است شما بدانید چه می‌کنید و بتوانید با افزودن فلگ -f به دستور پوش، برنچ راه دور را به‌زور بروزرسانی (force-update) کنید.

برای این‌که به گیت بگویید پوش‌های اجباری (force-push) را نپذیرد، مقدار receive.denyNonFastForwards را تنظیم کنید:

$ git config --system receive.denyNonFastForwards true

راه دیگر برای این کار استفاده از هوک‌های سمت سرور برای دریافت (receive hooks) است که اندکی بعد به آن می‌پردازیم. این رویکرد به شما اجازه می‌دهد کارهای پیچیده‌تری انجام دهید، مثل جلوگیری از non-fast-forward برای زیرمجموعهٔ خاصی از کاربران.

رد حذف‌ها هنگام دریافت (receive.denyDeletes)

یکی از راه‌حل‌ها برای سیاست denyNonFastForwards این است که کاربر شاخه را حذف کند و سپس آن را با ارجاع جدید دوباره پوش کند. برای جلوگیری از این کار، receive.denyDeletes را روی true تنظیم کنید:

$ git config --system receive.denyDeletes true
 این از حذف هرگونه شاخه یا تگ جلوگیری می‌کند — هیچ کاربری قادر به انجام آن نیست.
برای حذف شاخه‌های راه دور، باید به‌صورت دستی فایل‌های ref را از روی سرور پاک کنید.
همچنین روش‌های جالب‌تری برای انجام این کار به‌صورت تفکیک‌شده برای هر کاربر از طریق ACLها وجود دارد که در <<_an_example_git_enforced_policy>> خواهید آموخت.
scroll-to-top