Chapters ▾ 2nd Edition

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

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

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

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

$ git config --global user.name "Your Username"
$ git config --global user.email email@example.com

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

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

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

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

هر یک از این "سطوح" (سیستم، جهانی، محلی) مقادیر سطح قبلی را بازنویسی می‌کند، بنابراین مقادیر در .git/config بر مقادیر در /etc/gitconfig ارجحیت دارند، به عنوان مثال.

یادداشت

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

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

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

$ 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 که به این شکل باشد:

خط توضیحات (سعی کنید زیر 50 کاراکتر نگه دارید)

توضیحات چند خطی از کامیت،
احساس راحتی کنید که جزئیات بیشتری اضافه کنید.

[Ticket: X]

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

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

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

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

خط موضوع (سعی کنید زیر 50 کاراکتر نگه دارید)

توضیح چندخطی درباره‌ی commit،
برای توضیح جزئیات بیشتر آزاد هستید.

[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

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

$ git config --global core.pager ''

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

user.signingkey

اگر شما در حال ایجاد تگ‌های verified و حاشیه‌نویسی شده (طبق توضیحات در 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 سعی نکند آن‌ها را stage کند، همان‌طور که در نادیده گرفتن فایل‌ها توضیح داده شده است.

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

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

*~
.*.swp
.DS_Store

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

help.autocorrect

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

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

آیا منظور شما این بود؟
    checkout

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

$ 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...

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

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

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

color.ui

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

$ git config --global color.ui false

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

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

color.*

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

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

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

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

شما می‌توانید رنگ را به هر یک از مقادیر زیر تنظیم کنید: normal، black، red، green، yellow، blue، magenta، cyan، یا white. اگر می‌خواهید ویژگی‌ای مانند بولد در مثال قبلی داشته باشید، می‌توانید از bold، dim، ul (زیرخط)، blink و reverse (معکوس کردن پیش‌زمینه و پس‌زمینه) انتخاب کنید.

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

اگرچه Git یک پیاده‌سازی داخلی از diff دارد، که همان چیزی است که در این کتاب نشان داده‌ایم، شما می‌توانید به جای آن از یک ابزار خارجی استفاده کنید. همچنین می‌توانید یک ابزار گرافیکی برای حل تضادهای ادغام (merge conflicts) تنظیم کنید، به جای اینکه مجبور باشید تضادها را به‌صورت دستی حل کنید. در اینجا، نحوه تنظیم ابزار Perforce Visual Merge Tool (P4Merge) برای انجام diffها و حل تضادهای ادغام را نشان خواهیم داد، زیرا این یک ابزار گرافیکی خوب و رایگان است.

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

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

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

wrapper diff بررسی می‌کند که آیا هفت آرگومان ارائه شده است و دو تا از آن‌ها را به اسکریپت ادغام شما منتقل می‌کند. به طور پیش‌فرض، گیت آرگومان‌های زیر را به برنامه diff منتقل می‌کند:

path old-file old-hex old-mode new-file new-hex new-mode

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

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

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

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

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

$ 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.
نمودار 143. P4Merge.

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

نکته خوب در مورد این تنظیمات wrapper این است که می‌توانید ابزارهای تفاوت و ادغام خود را به راحتی تغییر دهید. به عنوان مثال، برای تغییر ابزارهای extDiff و extMerge به KDiff3، تنها کاری که باید انجام دهید ویرایش فایل extMerge است:

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

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

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

$ git mergetool --tool-help
'git mergetool --tool=<tool>' ممکن است به یکی از موارد زیر تنظیم شود:
        emerge
        gvimdiff
        gvimdiff2
        opendiff
        p4merge
        vimdiff
        vimdiff2

ابزارهای زیر معتبر هستند، اما در حال حاضر در دسترس نیستند:
        araxis
        bc3
        codecompare
        deltawalker
        diffmerge
        diffuse
        ecmerge
        kdiff3
        meld
        tkdiff
        tortoisemerge
        xxdiff

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

اگر به استفاده از KDiff3 برای تفاوت‌ها علاقه‌مند نیستید، بلکه فقط می‌خواهید از آن برای حل ادغام استفاده کنید و دستور kdiff3 در مسیر شما قرار دارد، می‌توانید این دستور را اجرا کنید:

$ git config --global merge.tool kdiff3

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

فرمت‌بندی و فاصله‌گذاری

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

core.autocrlf

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

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

$ git config --global core.autocrlf true

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

$ git config --global core.autocrlf input

این تنظیم باید به شما اجازه دهد که انتهای CRLF را در چک‌اوت‌های ویندوز داشته باشید، اما انتهای LF را در سیستم‌های macOS و Linux و در مخزن داشته باشید.

اگر شما یک برنامه‌نویس ویندوز هستید که پروژه‌ای فقط برای ویندوز انجام می‌دهید، می‌توانید این قابلیت را خاموش کنید و بازگشت‌های کاراکتر را در مخزن با تنظیم مقدار پیکربندی به false ثبت کنید:

$ git config --global core.autocrlf false

core.whitespace

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

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

سه موردی که به طور پیش‌فرض غیرفعال هستند اما می‌توانند فعال شوند indent-with-non-tab است، که به دنبال خطوطی می‌گردد که با فضاها به جای تب‌ها شروع می‌شوند (و توسط گزینه tabwidth کنترل می‌شود)؛ tab-in-indent، که به دنبال تب‌ها در بخش فاصله‌گذاری یک خط می‌گردد؛ و cr-at-eol، که به گیت می‌گوید که بازگشت‌های کاراکتر در انتهای خطوط اشکالی ندارد.

می‌توانید به گیت بگویید که کدام یک از این‌ها را می‌خواهید با تنظیم 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 diff را اجرا می‌کنید شناسایی می‌کند و سعی می‌کند آن‌ها را رنگ‌آمیزی کند تا بتوانید قبل از کامیت آن‌ها را اصلاح کنید. همچنین از این مقادیر برای کمک به شما هنگام اعمال وصله‌ها با git apply استفاده خواهد کرد. هنگامی که وصله‌ها را اعمال می‌کنید، می‌توانید از گیت بخواهید که اگر وصله‌هایی با مسائل فاصله‌گذاری مشخص شده را اعمال می‌کند، به شما هشدار دهد:

$ git apply --whitespace=warn <patch>

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

$ git apply --whitespace=fix <patch>

این گزینه‌ها همچنین به دستور git rebase اعمال می‌شوند. اگر شما مسائل فاصله‌گذاری را کامیت کرده‌اید اما هنوز به بالا فشار نداده‌اید، می‌توانید دستور git rebase --whitespace=fix را اجرا کنید تا گیت به طور خودکار مسائل فاصله‌گذاری را در حین بازنویسی وصله‌ها اصلاح کند.

Server Configuration (پیکربندی سرور)

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

receive.fsckObjects

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

$ git config --system receive.fsckObjects true

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

receive.denyNonFastForwards

اگر شما کامیت‌هایی را که قبلاً push کرده‌اید rebase کنید و سپس دوباره تلاش کنید تا آن‌ها را push کنید، یا به‌طور کلی تلاش کنید تا یک کامیت را به یک شاخه‌ی ریموتی که شامل کامیتی نیست که شاخه‌ی ریموتی به آن اشاره می‌کند، ارسال کنید، درخواست شما رد خواهد شد. این معمولاً سیاست خوبی است؛ اما در مورد rebase، ممکن است تشخیص دهید که می‌دانید چه کاری انجام می‌دهید و می‌توانید با استفاده از پرچم -f در دستور push خود، شاخه‌ی ریموتی را مجبور به به‌روزرسانی کنید.

برای اینکه به Git بگویید که force-pushها را رد کند، می‌توانید receive.denyNonFastForwards را تنظیم کنید:

$ git config --system receive.denyNonFastForwards true

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

receive.denyDeletes

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

$ git config --system receive.denyDeletes true

این تنظیم هرگونه حذف شاخه‌ها یا تگ‌ها را رد می‌کند — هیچ کاربری قادر به انجام این کار نخواهد بود. برای حذف شاخه‌های ریموت، باید فایل‌های ref را از سرور به‌طور دستی حذف کنید. همچنین روش‌های جالب‌تری برای انجام این کار به‌صورت اختصاصی برای هر کاربر از طریق ACLها وجود دارد، همانطور که در An Example Git-Enforced Policy (یک مثال از سیاست‌های تحمیلی گیت) خواهید آموخت.

scroll-to-top