GIT-TAG(1) Git Manual GIT-TAG(1)

git-tag - ایجاد، فهرست کردن، حذف یا اعتبارسنجی تگ‌ها

git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
        [(--trailer <token>[(=|:)<value>])...]
        <tagname> [<commit> | <object>]
git tag -d <tagname>...
git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
        [--points-at <object>] [--column[=<options>] | --no-column]
        [--create-reflog] [--sort=<key>] [--format=<format>]
        [--merged <commit>] [--no-merged <commit>] [<pattern>...]
git tag -v [--format=<format>] <tagname>...

یک مرجع تگ در refs/tags/ اضافه می‌کند، مگر اینکه -d/-l/-v برای حذف، فهرست کردن یا اعتبارسنجی تگ‌ها داده شده باشد.

مگر در حالتی که -f داده شده باشد، تگ نام‌برده نباید از قبل وجود داشته باشد.

اگر یکی از گزینه‌های -a، -s یا -u <key-id> داده شود، این دستور یک شیء tag ایجاد کرده و نیازمند یک پیام تگ خواهد بود. مگر اینکه -m <msg> یا -F <file> داده شده باشد، یک ویرایشگر باز می‌شود تا کاربر پیام تگ را وارد کند.

اگر -m <msg> یا -F <file> یا --trailer <token>[=<value>] داده شود و گزینه‌های -a، -s و -u <key-id> غایب باشند، -a به صورت ضمنی در نظر گرفته می‌شود.

در غیر این صورت، یک مرجع تگ که مستقیماً به شیء داده‌شده اشاره می‌کند (یعنی یک تگ سبک یا lightweight tag) ایجاد می‌شود.

هنگامی که از -s یا -u <key-id> استفاده شود، یک شیء تگ با امضای رمزنگاری‌شده ایجاد خواهد شد. پشت‌بند امضا (مانند GPG، X.509، SSH و غیره) توسط متغیر پیکربندی gpg.format کنترل می‌شود که مقدار پیش‌فرض آن OpenPGP است. هنگامی که از -u <key-id> استفاده نشود، هویت کامیت‌کننده برای کاربر جاری جهت یافتن کلید امضا استفاده می‌شود. متغیر پیکربندی gpg.program برای تعیین برنامه باینری سفارشی امضا استفاده می‌شود.

اشیاء تگ (ایجادشده با -a، -s یا -u) تگ‌های «حاشیه‌نویسی‌شده» (annotated) نامیده می‌شوند؛ آن‌ها شامل تاریخ ایجاد، نام و ایمیل ایجادکننده تگ، پیام تگ و یک امضای رمزنگاری‌شده اختیاری هستند. در حالی که یک تگ «سبک» (lightweight) صرفاً یک نام برای یک شیء (معمولاً یک شیء کامیت) است.

تگ‌های حاشیه‌نویسی‌شده برای انتشار در نظر گرفته شده‌اند در حالی که تگ‌های سبک برای برچسب‌گذاری موقت یا خصوصی اشیاء هستند. به همین دلیل، برخی دستورات گیت برای نام‌گذاری اشیاء (مانند git describe) به صورت پیش‌فرض تگ‌های سبک را نادیده می‌گیرند.

-a, --annotate

ایجاد یک شیء تگ حاشیه‌نویسی‌شده و بدون امضا

-s, --sign

ایجاد یک تگ با امضای رمزنگاری‌شده با استفاده از کلید امضای پیش‌فرض. پشت‌بند امضای مورداستفاده به متغیر پیکربندی gpg.format بستگی دارد. کلید پیش‌فرض توسط پشت‌بند تعیین می‌شود. برای GPG، این کلید بر اساس آدرس ایمیل کامیت‌کننده است، در حالی که برای SSH ممکن است یک فایل کلید مشخص یا هویت کارگزار باشد. به git-config(1) مراجعه کنید.

--no-sign

نادیده گرفتن متغیر پیکربندی tag.gpgSign که برای اجبار به امضا شدن همه تگ‌ها تنظیم شده است.

-u <key-id>, --local-user=<key-id>

ایجاد یک تگ با امضای رمزنگاری‌شده با استفاده از کلید مشخص‌شده. قالب <key-id> و پشت‌بند مورداستفاده به متغیر پیکربندی gpg.format بستگی دارد. به git-config(1) مراجعه کنید.

-f, --force

جایگزین کردن تگ موجود با نام داده‌شده (به جای ایجاد خطا)

-d, --delete

حذف تگ‌های موجود با نام‌های مشخص‌شده.

-v, --verify

اعتبارسنجی امضای رمزنگاری‌شده تگ‌های مشخص‌شده.

-n<num>

<num> مشخص می‌کند هنگام استفاده از -l چند خط از حاشیه‌نویسی (در صورت وجود) چاپ شود. به صورت ضمنی --list را فعال می‌کند.

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

-l, --list

فهرست کردن تگ‌ها. با <pattern>... اختیاری، مانند git tag --list 'v-*'، فقط تگ‌هایی را که با الگو(ها) مطابقت دارند فهرست می‌کند.

اجرای git tag بدون آرگومان نیز تمام تگ‌ها را فهرست می‌کند. الگو یک نویسه عام (wildcard) پوسته است (یعنی با استفاده از fnmatch(3) تطبیق داده می‌شود). چندین الگو می‌توانند مشخص شوند؛ اگر هر یک از آن‌ها مطابقت داشته باشد، تگ نشان داده می‌شود.

این گزینه در صورت ارائه هر گزینه فهرست‌مانند دیگری مانند --contains به صورت ضمنی فعال می‌شود. برای جزئیات به مستندات مربوط به هر یک از آن گزینه‌ها مراجعه کنید.

--sort=<key>

مرتب‌سازی بر اساس کلید ارائه‌شده. پیشوند - برای مرتب‌سازی نزولی مقادیر استفاده می‌شود. می‌توانید از گزینه --sort=<key> چندین بار استفاده کنید، که در این صورت آخرین <key> کلید اصلی مرتب‌سازی خواهد بود. همچنین از "version:refname" یا "v:refname" پشتیبانی می‌کند (نام‌های تگ به عنوان نسخه در نظر گرفته می‌شوند). ترتیب مرتب‌سازی "version:refname" همچنین می‌تواند تحت تأثیر متغیر پیکربندی "versionsort.suffix" قرار گیرد. کلیدهای پشتیبانی‌شده مشابه موارد موجود در git for-each-ref هستند. در صورت وجود متغیر tag.sort ترتیب مرتب‌سازی به مقدار آن متغیر، و در غیر این صورت به ترتیب لغت‌نگاری (lexicographic) پیش‌فرض است. به git-config(1) مراجعه کنید.

--color[=<when>]

رعایت هر رنگ مشخص‌شده در گزینه --format. فیلد <when> باید یکی از مقادیر always، never یا auto باشد (اگر <when> داده نشود، رفتاری مانند always خواهد داشت).

-i, --ignore-case

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

--omit-empty

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

--column[=<options>], --no-column

نمایش فهرست تگ‌ها در ستون‌ها. برای نحو (syntax) گزینه‌ها به متغیر پیکربندی column.tag مراجعه کنید. گزینه‌های --column و --no-column بدون گزینه، به ترتیب معادل always و never هستند.

این گزینه تنها هنگام فهرست کردن تگ‌ها بدون خطوط حاشیه‌نویسی کاربرد دارد.

--contains [<commit>]

فقط تگ‌هایی را فهرست می‌کند که حاوی <commit> هستند (در صورت عدم تعیین، HEAD). به صورت ضمنی --list را فعال می‌کند.

--no-contains [<commit>]

فقط تگ‌هایی را فهرست می‌کند که حاوی <commit> نیستند (در صورت عدم تعیین، HEAD). به صورت ضمنی --list را فعال می‌کند.

--merged [<commit>]

فقط تگ‌هایی را فهرست می‌کند که کامیت‌های آن‌ها از <commit> قابل دسترسی هستند (در صورت عدم تعیین، HEAD).

--no-merged [<commit>]

فقط تگ‌هایی را فهرست می‌کند که کامیت‌های آن‌ها از <commit> قابل دسترسی نیستند (در صورت عدم تعیین، HEAD).

--points-at [<object>]

فقط تگ‌های مربوط به <object> را فهرست می‌کند (در صورت عدم تعیین، HEAD). به صورت ضمنی --list را فعال می‌کند.

-m <msg>, --message=<msg>

استفاده از <msg> (به جای درخواست از کاربر). اگر چندین گزینه -m داده شوند، مقادیر آن‌ها به عنوان بندهای جداگانه به یکدیگر متصل می‌شوند. اگر هیچ‌یک از گزینه‌های -a، -s یا -u <key-id> داده نشده باشند، به صورت ضمنی -a در نظر گرفته می‌شود.

-F <file>, --file=<file>

خواندن پیام تگ از <file>. برای خواندن پیام از ورودی استاندارد از - استفاده کنید. اگر هیچ‌یک از گزینه‌های -a، -s یا -u <key-id> داده نشده باشند، به صورت ضمنی -a در نظر گرفته می‌شود.

--trailer <token>[(=|:)<value>]

یک جفت (<token>، <value>) مشخص می‌کند که باید به عنوان تریلر اعمال شود. (مثلاً git tag --trailer "Custom-Key: value" یک تریلر "Custom-Key" به پیام تگ اضافه خواهد کرد.) متغیرهای پیکربندی trailer.* (git-interpret-trailers(1)) می‌توانند برای تعیین اینکه آیا تریلر تکراری حذف شود، هر تریلر در کجای دنباله تریلرها ظاهر شود و سایر جزئیات به کار روند. تریلرها را می‌توان در git tag --list با استفاده از متغیر جایگزین --format="%(trailers)" استخراج کرد.

-e, --edit

امکان ویرایش بیشتر پیامی را که با -F از فایل یا با -m از خط فرمان گرفته شده است فراهم می‌کند.

--cleanup=<mode>

نحوه پاک‌سازی پیام تگ را تعیین می‌کند. مقدار <mode> می‌تواند یکی از موارد verbatim، whitespace و strip باشد. حالت strip حالت پیش‌فرض است. حالت verbatim پیام را به هیچ وجه تغییر نمی‌دهد، whitespace فقط خطوط سفید ابتدا و انتها را حذف می‌کند و strip هم خطوط سفید و هم یادداشت‌ها و توضیحات را حذف می‌کند.

--create-reflog

ایجاد یک reflog برای تگ. برای فعال‌سازی سراسری reflog برای تگ‌ها، به core.logAllRefUpdates در git-config(1) مراجعه کنید. شکل منفی --no-create-reflog تنها مقدار قبلی --create-reflog را لغو می‌کند، اما در حال حاضر مقدار تنظیم‌شده در core.logAllRefUpdates را خنثی نمی‌کند.

--format=<format>

رشته‌ای که %(fieldname) را از یک مرجع تگ در حال نمایش و شیئی که به آن اشاره دارد جایگزین می‌کند. ساختار آن مشابه git-for-each-ref(1) است. در صورت عدم تعیین، پیش‌فرض %(refname:strip=2) است.

<tagname>

نام تگی که قرار است ایجاد، حذف یا توصیف شود. نام تگ جدید باید از تمام بررسی‌های تعریف‌شده توسط git-check-ref-format(1) عبور کند. برخی از این بررسی‌ها ممکن است نویسه‌های مجاز در یک نام تگ را محدود کنند.

<commit>, <object>

شیئی که تگ جدید به آن اشاره خواهد کرد، معمولاً یک کامیت. پیش‌فرض HEAD است.

به‌طور پیش‌فرض، git tag در حالت امضا با پیش‌فرض (-s) از هویت کامیت‌کننده شما (به شکل Your Name <your@email.address>) برای یافتن کلید استفاده می‌کند. اگر می‌خواهید از کلید پیش‌فرض متفاوتی استفاده کنید، می‌توانید آن را در پیکربندی مخزن به شکل زیر تعیین کنید:

[user]
    signingKey = <key-id>

پشت‌بند امضا را می‌توان با متغیر پیکربندی gpg.format انتخاب کرد که مقدار پیش‌فرض آن openpgp است. برای فهرستی از سایر قالب‌های پشتیبانی‌شده به git-config(1) مراجعه کنید.

مسیر برنامه‌ای که برای هر پشت‌بند امضا استفاده می‌شود را می‌توان با متغیر پیکربندی gpg.<format>.program مشخص کرد. برای پشت‌بند openpgp، می‌توان از gpg.program به عنوان مترادفی برای gpg.openpgp.program استفاده کرد. برای جزئیات به git-config(1) مراجعه کنید.

متغیر pager.tag تنها هنگام فهرست کردن تگ‌ها رعایت می‌شود، یعنی زمانی که -l استفاده شده یا ضمنی باشد. پیش‌فرض استفاده از صفحه‌بند (pager) است.

برای جزئیات بیشتر و سایر متغیرهای پیکربندی به git-config(1) مراجعه کنید.

هنگامی که به اشتباه یک کامیت نادرست را تگ می‌کنید و می‌خواهید مجدداً تگ بگذارید، چه باید بکنید؟

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

اما اگر تغییرات را push کرده‌اید (یا دیگران می‌توانستند مستقیماً مخزن شما را بخوانند)، آنگاه دیگران قبلاً تگ قدیمی را دیده‌اند. در این حالت می‌توانید یکی از این دو کار را انجام دهید:

1.روش معقولانه. فقط بپذیرید که اشتباه کرده‌اید، و از نام متفاوتی استفاده کنید. دیگران قبلاً یک نام تگ را دیده‌اند، و اگر همان نام را نگه دارید، ممکن است در موقعیتی قرار بگیرید که دو نفر هر دو "نسخه X" را داشته باشند، اما در واقع نسخه‌های متفاوتی از "X" را در اختیار داشته باشند. بنابراین فقط آن را "X.1" بنامید و کار را تمام کنید.
2.روش غیرمعقول. شما واقعاً می‌خواهید نسخه جدید را هم "X" بنامید، حتی با اینکه دیگران قبلاً نسخه قدیمی را دیده‌اند. بنابراین مجدداً از git tag -f استفاده کنید، گویی که هرگز تگ قدیمی را منتشر نکرده بودید.

با این حال، گیت تگ‌ها را پشت سر کاربران تغییر نمی‌دهد (و نباید هم بدهد). بنابراین اگر کسی قبلاً تگ قدیمی را دریافت کرده باشد، اجرای git pull روی درخت شما نباید تگ قدیمی او را رونویسی کند.

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

Ok, I messed up, and I pushed out an earlier version tagged as X. I
then fixed something, and retagged the *fixed* tree as X again.
If you got the wrong tag, and want the new one, please delete
the old one and fetch the new one by doing:
        git tag -d X
        git fetch origin tag X
to get my updated tag.
You can test which tag you have by doing
        git rev-parse X
which should return 0123456789abcdef.. if you have the new version.
Sorry for the inconvenience.

آیا این کمی پیچیده به نظر می‌رسد؟ باید هم باشد. هیچ راهی وجود ندارد که "درست کردن" خودکار آن کار صحیحی باشد. افراد باید بدانند که ممکن است تگ‌هایشان تغییر کرده باشد.

اگر در حال دنبال کردن درخت شخص دیگری هستید، به احتمال زیاد از شاخه‌های ردیابی از راه دور (مانند refs/remotes/origin/master) استفاده می‌کنید. شما معمولاً تگ‌های طرف مقابل را می‌خواهید.

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

اغلب، پیام‌های "لطفاً pull کنید" در فهرست پستی صرفاً دو بخش اطلاعاتی را ارائه می‌دهند: یک آدرس اینترنتی مخزن و یک نام شاخه؛ این قالب به گونه‌ای طراحی شده که به راحتی در انتهای یک خط فرمان git fetch رونوشت و جای‌گذاری شود:

Linus, please pull from
        git://git..../proj.git master
to get the following updates...

تبدیل می‌شود به:

$ git pull git://git..../proj.git master

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

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

یک pull تک‌باره نشانه‌ای از این است که تاریخچه کامیت اکنون در حال عبور از مرز میان یک گروه از افراد (مثلاً "افرادی که بیشتر به بخش شبکه هسته علاقه‌مندند") که ممکن است مجموعه تگ‌های خود را داشته باشند (مثلاً "این سومین نامزد انتشار از گروه شبکه است که برای استفاده عمومی با انتشار 2.6.21 پیشنهاد می‌شود") به گروه دیگری از افراد (مثلاً "افرادی که بهبودهای زیرسیستم‌های مختلف را ادغام می‌کنند") است. گروه دوم معمولاً به تگ‌های تفصیلی که به صورت داخلی در گروه اول استفاده می‌شوند علاقه‌ای ندارند (معنای "داخلی" همین است). به همین دلیل مطلوب است که در این حالت تگ‌ها به صورت خودکار دنبال نشوند.

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

اگر تغییراتی را از یک سیستم کنترل نسخه دیگر وارد کرده‌اید و می‌خواهید تگ‌هایی برای انتشار‌های اصلی کار خود اضافه کنید، تعیین تاریخی برای گنجاندن در شیء تگ بسیار سودمند است؛ این داده در شیء تگ، برای مثال، بر ترتیب نمایش تگ‌ها در رابط وب‌گیت (gitweb) تأثیر می‌گذارد.

برای تعیین تاریخ مورد استفاده در اشیاء تگ آینده، متغیر محیطی GIT_COMMITTER_DATE را تنظیم کنید (به بحث بعدی پیرامون مقادیر ممکن مراجعه فرمایید؛ رایج‌ترین قالب "YYYY-MM-DD HH:MM" است).

برای مثال:

$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1

متغیرهای محیطی GIT_AUTHOR_DATE و GIT_COMMITTER_DATE از قالب‌های تاریخ زیر پشتیبانی می‌کنند:

قالب داخلی گیت (Git internal format)

به صورت <unix-timestamp> <time-zone-offset> است، که در آن <unix-timestamp> تعداد ثانیه‌ها از مبدأ یونیکس (UNIX epoch) است. <time-zone-offset> یک افست زمانی مثبت یا منفی از UTC است. برای مثال CET (که یک ساعت جلوتر از UTC است) برابر با +0100 است.

ایمن‌تر است که پیش از <unix-timestamp> علامت @ قرار دهید (مثلاً @0 +0000)، که گیت را وادار می‌کند آن را به عنوان یک برچسب زمانی خام تفسیر کند. این کار برای مقادیر کمتر از ۱۰۰٬۰۰۰٬۰۰۰ (که کمتر از ۹ رقم دارند) الزامی است تا از اشتباه گرفته شدن با سایر قالب‌های تاریخ مانند YYYYMMDD جلوگیری شود.

استاندارد RFC 2822

قالب تاریخ استاندارد طبق استاندارد RFC 2822، به عنوان مثال Thu, 07 Apr 2005 22:13:13 +0200.

استاندارد ISO 8601

زمان و تاریخ تعیین‌شده طبق استاندارد ISO 8601، به عنوان مثال 2005-04-07T22:13:13. تجزیه‌کننده یک فاصله را نیز به جای نویسه T می‌پذیرد. بخش‌های کسری ثانیه نادیده گرفته می‌شوند، برای مثال 2005-04-07T22:13:13.019 مانند 2005-04-07T22:13:13 در نظر گرفته می‌شود.

یادداشت
علاوه بر این، بخش تاریخ در قالب‌های زیر نیز پذیرفته می‌شود: YYYY.MM.DD، MM/DD/YYYY و DD.MM.YYYY.

$GIT_DIR/TAG_EDITMSG

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

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

tag.forceSignAnnotated

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

tag.sort

این متغیر ترتیب مرتب‌سازی تگ‌ها را هنگام نمایش با git-tag کنترل می‌کند. در صورت عدم ارائه گزینه --sort=<value>، مقدار این متغیر به عنوان پیش‌فرض در نظر گرفته می‌شود.

tag.gpgSign

یک مقدار بولی که مشخص می‌کند آیا تمام تگ‌ها باید با GPG امضا شوند یا خیر. استفاده از این گزینه در اسکریپت‌های خودکار ممکن است موجب امضای تعداد زیادی تگ شود. بنابراین استفاده از یک کارگزار (agent) برای پرهیز از تایپ مکرر عبارت عبور GPG پیشنهاد می‌شود. توجه داشته باشید که این گزینه بر رفتار امضای تگ که با گزینه‌های -u <keyid> یا --local-user=<keyid> فعال شده باشد، تأثیری ندارد.

هنگام ترکیب چند فیلتر --contains و --no-contains، تنها مراجعی نشان داده می‌شوند که حداقل شامل یکی از کامیت‌های --contains بوده و شامل هیچ‌یک از کامیت‌های --no-contains نباشند.

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

git-check-ref-format(1). git-config(1).

بخشی از مجموعه git(1)

2026-06-29 Git 2.55.0