'\" t
.\"     Title: git-tag
.\"    Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net>
.\"      Date: 2026-06-29
.\"    Manual: Git Manual
.\"    Source: Git 2.55.0
.\"  Language: English
.\"
.TH "GIT\-TAG" "1" "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)"
git-tag \- ایجاد، فهرست کردن، حذف یا اعتبارسنجی تگ‌ها
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
\fBgit\fR \fBtag\fR [\fB\-a\fR | \fB\-s\fR | \fB\-u\fR \fI<key\-id>\fR] [\fB\-f\fR] [\fB\-m\fR \fI<msg>\fR | \fB\-F\fR \fI<file>\fR] [\fB\-e\fR]
        [(\fB\-\-trailer\fR \fI<token>\fR[(\fB=\fR|\fB:\fR)\fI<value>\fR])\&...]
        \fI<tagname>\fR [\fI<commit>\fR | \fI<object>\fR]
\fBgit\fR \fBtag\fR \fB\-d\fR \fI<tagname>\fR\&...
\fBgit\fR \fBtag\fR [\fB\-n\fR[\fI<num>\fR]] \fB\-l\fR [\fB\-\-contains\fR \fI<commit>\fR] [\fB\-\-no\-contains\fR \fI<commit>\fR]
        [\fB\-\-points\-at\fR \fI<object>\fR] [\fB\-\-column\fR[\fB=\fR\fI<options>\fR] | \fB\-\-no\-column\fR]
        [\fB\-\-create\-reflog\fR] [\fB\-\-sort=\fR\fI<key>\fR] [\fB\-\-format=\fR\fI<format>\fR]
        [\fB\-\-merged\fR \fI<commit>\fR] [\fB\-\-no\-merged\fR \fI<commit>\fR] [\fI<pattern>\fR\&...]
\fBgit\fR \fBtag\fR \fB\-v\fR [\fB\-\-format=\fR\fI<format>\fR] \fI<tagname>\fR\&...
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
یک مرجع تگ در \fBrefs/tags/\fR اضافه می‌کند، مگر اینکه \fB\-d\fR/\fB\-l\fR/\fB\-v\fR برای حذف، فهرست کردن یا اعتبارسنجی تگ‌ها داده شده باشد\&.
.sp
مگر در حالتی که \fB\-f\fR داده شده باشد، تگ نام‌برده نباید از قبل وجود داشته باشد\&.
.sp
اگر یکی از گزینه‌های \fB\-a\fR، \fB\-s\fR یا \fB\-u\fR \fI<key\-id>\fR داده شود، این دستور یک شیء \fItag\fR ایجاد کرده و نیازمند یک پیام تگ خواهد بود\&. مگر اینکه \fB\-m\fR \fI<msg>\fR یا \fB\-F\fR \fI<file>\fR داده شده باشد، یک ویرایشگر باز می‌شود تا کاربر پیام تگ را وارد کند\&.
.sp
اگر \fB\-m\fR \fI<msg>\fR یا \fB\-F\fR \fI<file>\fR یا \fB\-\-trailer\fR \fI<token>\fR[\fB=\fR\fI<value>\fR] داده شود و گزینه‌های \fB\-a\fR، \fB\-s\fR و \fB\-u\fR \fI<key\-id>\fR غایب باشند، \fB\-a\fR به صورت ضمنی در نظر گرفته می‌شود\&.
.sp
در غیر این صورت، یک مرجع تگ که مستقیماً به شیء داده‌شده اشاره می‌کند (یعنی یک تگ سبک یا lightweight tag) ایجاد می‌شود\&.
.sp
هنگامی که از \fB\-s\fR یا \fB\-u\fR \fI<key\-id>\fR استفاده شود، یک شیء تگ با امضای رمزنگاری‌شده ایجاد خواهد شد\&. پشت‌بند امضا (مانند GPG، X\&.509، SSH و غیره) توسط متغیر پیکربندی \fBgpg\&.format\fR کنترل می‌شود که مقدار پیش‌فرض آن OpenPGP است\&. هنگامی که از \fB\-u\fR \fI<key\-id>\fR استفاده نشود، هویت کامیت‌کننده برای کاربر جاری جهت یافتن کلید امضا استفاده می‌شود\&. متغیر پیکربندی \fBgpg\&.program\fR برای تعیین برنامه باینری سفارشی امضا استفاده می‌شود\&.
.sp
اشیاء تگ (ایجادشده با \fB\-a\fR، \fB\-s\fR یا \fB\-u\fR) تگ‌های «حاشیه‌نویسی‌شده» (annotated) نامیده می‌شوند؛ آن‌ها شامل تاریخ ایجاد، نام و ایمیل ایجادکننده تگ، پیام تگ و یک امضای رمزنگاری‌شده اختیاری هستند\&. در حالی که یک تگ «سبک» (lightweight) صرفاً یک نام برای یک شیء (معمولاً یک شیء کامیت) است\&.
.sp
تگ‌های حاشیه‌نویسی‌شده برای انتشار در نظر گرفته شده‌اند در حالی که تگ‌های سبک برای برچسب‌گذاری موقت یا خصوصی اشیاء هستند\&. به همین دلیل، برخی دستورات گیت برای نام‌گذاری اشیاء (مانند \fBgit\fR \fBdescribe\fR) به صورت پیش‌فرض تگ‌های سبک را نادیده می‌گیرند\&.
.SH "گزینه‌ها (OPTIONS)"
.PP
\fB\-a\fR, \fB\-\-annotate\fR
.RS 4
ایجاد یک شیء تگ حاشیه‌نویسی‌شده و بدون امضا
.RE
.PP
\fB\-s\fR, \fB\-\-sign\fR
.RS 4
ایجاد یک تگ با امضای رمزنگاری‌شده با استفاده از کلید امضای پیش‌فرض\&. پشت‌بند امضای مورداستفاده به متغیر پیکربندی
\fBgpg\&.format\fR
بستگی دارد\&. کلید پیش‌فرض توسط پشت‌بند تعیین می‌شود\&. برای GPG، این کلید بر اساس آدرس ایمیل کامیت‌کننده است، در حالی که برای SSH ممکن است یک فایل کلید مشخص یا هویت کارگزار باشد\&. به
\fBgit-config\fR(1)
مراجعه کنید\&.
.RE
.PP
\fB\-\-no\-sign\fR
.RS 4
نادیده گرفتن متغیر پیکربندی
\fBtag\&.gpgSign\fR
که برای اجبار به امضا شدن همه تگ‌ها تنظیم شده است\&.
.RE
.PP
\fB\-u\fR \fI<key\-id>\fR, \fB\-\-local\-user=\fR\fI<key\-id>\fR
.RS 4
ایجاد یک تگ با امضای رمزنگاری‌شده با استفاده از کلید مشخص‌شده\&. قالب <key\-id> و پشت‌بند مورداستفاده به متغیر پیکربندی
\fBgpg\&.format\fR
بستگی دارد\&. به
\fBgit-config\fR(1)
مراجعه کنید\&.
.RE
.PP
\fB\-f\fR, \fB\-\-force\fR
.RS 4
جایگزین کردن تگ موجود با نام داده‌شده (به جای ایجاد خطا)
.RE
.PP
\fB\-d\fR, \fB\-\-delete\fR
.RS 4
حذف تگ‌های موجود با نام‌های مشخص‌شده\&.
.RE
.PP
\fB\-v\fR, \fB\-\-verify\fR
.RS 4
اعتبارسنجی امضای رمزنگاری‌شده تگ‌های مشخص‌شده\&.
.RE
.PP
\fB\-n\fR\fI<num>\fR
.RS 4
\fI<num>\fR
مشخص می‌کند هنگام استفاده از
\fB\-l\fR
چند خط از حاشیه‌نویسی (در صورت وجود) چاپ شود\&. به صورت ضمنی
\fB\-\-list\fR
را فعال می‌کند\&.
.sp
پیش‌فرض این است که هیچ خطی از حاشیه‌نویسی چاپ نشود\&. اگر هیچ عددی به
\fB\-n\fR
داده نشود، فقط خط اول چاپ می‌شود\&. اگر تگ حاشیه‌نویسی نشده باشد، به جای آن پیام کامیت نمایش داده می‌شود\&.
.RE
.PP
\fB\-l\fR, \fB\-\-list\fR
.RS 4
فهرست کردن تگ‌ها\&. با
\fI<pattern>\fR\&.\&.\&.
اختیاری، مانند
\fBgit\fR
\fBtag\fR
\fB\-\-list\fR
\*(Aqv\-*\*(Aq،
فقط تگ‌هایی را که با الگو(ها) مطابقت دارند فهرست می‌کند\&.
.sp
اجرای
\fBgit\fR
\fBtag\fR
بدون آرگومان نیز تمام تگ‌ها را فهرست می‌کند\&. الگو یک نویسه عام (wildcard) پوسته است (یعنی با استفاده از
\fBfnmatch\fR(3)
تطبیق داده می‌شود)\&. چندین الگو می‌توانند مشخص شوند؛ اگر هر یک از آن‌ها مطابقت داشته باشد، تگ نشان داده می‌شود\&.
.sp
این گزینه در صورت ارائه هر گزینه فهرست‌مانند دیگری مانند
\fB\-\-contains\fR
به صورت ضمنی فعال می‌شود\&. برای جزئیات به مستندات مربوط به هر یک از آن گزینه‌ها مراجعه کنید\&.
.RE
.PP
\fB\-\-sort=\fR\fI<key>\fR
.RS 4
مرتب‌سازی بر اساس کلید ارائه‌شده\&. پیشوند
\fB\-\fR
برای مرتب‌سازی نزولی مقادیر استفاده می‌شود\&. می‌توانید از گزینه
\fB\-\-sort=\fR\fI<key>\fR
چندین بار استفاده کنید، که در این صورت آخرین
\fI<key>\fR
کلید اصلی مرتب‌سازی خواهد بود\&. همچنین از "\fBversion:refname\fR" یا "\fBv:refname\fR" پشتیبانی می‌کند (نام‌های تگ به عنوان نسخه در نظر گرفته می‌شوند)\&. ترتیب مرتب‌سازی "\fBversion:refname\fR" همچنین می‌تواند تحت تأثیر متغیر پیکربندی "\fBversionsort\&.suffix\fR" قرار گیرد\&. کلیدهای پشتیبانی‌شده مشابه موارد موجود در
\fBgit\fR
\fBfor\-each\-ref\fR
هستند\&. در صورت وجود متغیر
\fBtag\&.sort\fR
ترتیب مرتب‌سازی به مقدار آن متغیر، و در غیر این صورت به ترتیب لغت‌نگاری (lexicographic) پیش‌فرض است\&. به
\fBgit-config\fR(1)
مراجعه کنید\&.
.RE
.PP
\fB\-\-color\fR[\fB=\fR\fI<when>\fR]
.RS 4
رعایت هر رنگ مشخص‌شده در گزینه
\fB\-\-format\fR\&.
فیلد
\fI<when>\fR
باید یکی از مقادیر
\fBalways\fR،
\fBnever\fR یا
\fBauto\fR
باشد (اگر
\fI<when>\fR
داده نشود، رفتاری مانند
\fBalways\fR
خواهد داشت)\&.
.RE
.PP
\fB\-i\fR, \fB\-\-ignore\-case\fR
.RS 4
مرتب‌سازی و فیلتر کردن تگ‌ها بدون حساسیت به حروف بزرگ و کوچک انجام می‌شود\&.
.RE
.PP
\fB\-\-omit\-empty\fR
.RS 4
پس از ارجاع‌های قالب‌بندی‌شده‌ای که فرمت آن‌ها به یک رشته خالی تبدیل می‌شود، خط جدیدی چاپ نمی‌کند\&.
.RE
.PP
\fB\-\-column\fR[\fB=\fR\fI<options>\fR], \fB\-\-no\-column\fR
.RS 4
نمایش فهرست تگ‌ها در ستون‌ها\&. برای نحو (syntax) گزینه‌ها به متغیر پیکربندی
\fBcolumn\&.tag\fR
مراجعه کنید\&. گزینه‌های
\fB\-\-column\fR
و
\fB\-\-no\-column\fR
بدون گزینه، به ترتیب معادل
\fBalways\fR
و
\fBnever\fR
هستند\&.
.sp
این گزینه تنها هنگام فهرست کردن تگ‌ها بدون خطوط حاشیه‌نویسی کاربرد دارد\&.
.RE
.PP
\fB\-\-contains\fR [\fI<commit>\fR]
.RS 4
فقط تگ‌هایی را فهرست می‌کند که حاوی
\fI<commit>\fR
هستند (در صورت عدم تعیین،
\fBHEAD\fR)\&.
به صورت ضمنی
\fB\-\-list\fR
را فعال می‌کند\&.
.RE
.PP
\fB\-\-no\-contains\fR [\fI<commit>\fR]
.RS 4
فقط تگ‌هایی را فهرست می‌کند که حاوی
\fI<commit>\fR
نیستند (در صورت عدم تعیین،
\fBHEAD\fR)\&.
به صورت ضمنی
\fB\-\-list\fR
را فعال می‌کند\&.
.RE
.PP
\fB\-\-merged\fR [\fI<commit>\fR]
.RS 4
فقط تگ‌هایی را فهرست می‌کند که کامیت‌های آن‌ها از
\fI<commit>\fR
قابل دسترسی هستند (در صورت عدم تعیین،
\fBHEAD\fR)\&.
.RE
.PP
\fB\-\-no\-merged\fR [\fI<commit>\fR]
.RS 4
فقط تگ‌هایی را فهرست می‌کند که کامیت‌های آن‌ها از
\fI<commit>\fR
قابل دسترسی نیستند (در صورت عدم تعیین،
\fBHEAD\fR)\&.
.RE
.PP
\fB\-\-points\-at\fR [\fI<object>\fR]
.RS 4
فقط تگ‌های مربوط به
\fI<object>\fR
را فهرست می‌کند (در صورت عدم تعیین،
\fBHEAD\fR)\&.
به صورت ضمنی
\fB\-\-list\fR
را فعال می‌کند\&.
.RE
.PP
\fB\-m\fR \fI<msg>\fR, \fB\-\-message=\fR\fI<msg>\fR
.RS 4
استفاده از
\fI<msg>\fR
(به جای درخواست از کاربر)\&. اگر چندین گزینه
\fB\-m\fR
داده شوند، مقادیر آن‌ها به عنوان بندهای جداگانه به یکدیگر متصل می‌شوند\&. اگر هیچ‌یک از گزینه‌های
\fB\-a\fR،
\fB\-s\fR یا
\fB\-u\fR
\fI<key\-id>\fR
داده نشده باشند، به صورت ضمنی
\fB\-a\fR
در نظر گرفته می‌شود\&.
.RE
.PP
\fB\-F\fR \fI<file>\fR, \fB\-\-file=\fR\fI<file>\fR
.RS 4
خواندن پیام تگ از
\fI<file>\fR\&.
برای خواندن پیام از ورودی استاندارد از
\fB\-\fR
استفاده کنید\&. اگر هیچ‌یک از گزینه‌های
\fB\-a\fR،
\fB\-s\fR یا
\fB\-u\fR
\fI<key\-id>\fR
داده نشده باشند، به صورت ضمنی
\fB\-a\fR
در نظر گرفته می‌شود\&.
.RE
.PP
\fB\-\-trailer\fR \fI<token>\fR[(\fB=\fR|\fB:\fR)\fI<value>\fR]
.RS 4
یک جفت (\fI<token>\fR،
\fI<value>\fR)
مشخص می‌کند که باید به عنوان تریلر اعمال شود\&. (مثلاً
\fBgit\fR
\fBtag\fR
\fB\-\-trailer\fR
"Custom\-Key:
\fBvalue\fR"
یک تریلر "Custom\-Key" به پیام تگ اضافه خواهد کرد\&.) متغیرهای پیکربندی
\fBtrailer\&.*\fR
(\fBgit-interpret-trailers\fR(1))
می‌توانند برای تعیین اینکه آیا تریلر تکراری حذف شود، هر تریلر در کجای دنباله تریلرها ظاهر شود و سایر جزئیات به کار روند\&. تریلرها را می‌توان در
\fBgit\fR
\fBtag\fR
\fB\-\-list\fR
با استفاده از متغیر جایگزین
\fB\-\-format=\fR"%(\fBtrailers\fR)"
استخراج کرد\&.
.RE
.PP
\fB\-e\fR, \fB\-\-edit\fR
.RS 4
امکان ویرایش بیشتر پیامی را که با
\fB\-F\fR
از فایل یا با
\fB\-m\fR
از خط فرمان گرفته شده است فراهم می‌کند\&.
.RE
.PP
\fB\-\-cleanup=\fR\fI<mode>\fR
.RS 4
نحوه پاک‌سازی پیام تگ را تعیین می‌کند\&. مقدار
\fI<mode>\fR
می‌تواند یکی از موارد
\fBverbatim\fR،
\fBwhitespace\fR
و
\fBstrip\fR
باشد\&. حالت
\fBstrip\fR
حالت پیش‌فرض است\&. حالت
\fBverbatim\fR
پیام را به هیچ وجه تغییر نمی‌دهد،
\fBwhitespace\fR
فقط خطوط سفید ابتدا و انتها را حذف می‌کند و
\fBstrip\fR
هم خطوط سفید و هم یادداشت‌ها و توضیحات را حذف می‌کند\&.
.RE
.PP
\fB\-\-create\-reflog\fR
.RS 4
ایجاد یک reflog برای تگ\&. برای فعال‌سازی سراسری reflog برای تگ‌ها، به
\fBcore\&.logAllRefUpdates\fR
در
\fBgit-config\fR(1)
مراجعه کنید\&. شکل منفی
\fB\-\-no\-create\-reflog\fR
تنها مقدار قبلی
\fB\-\-create\-reflog\fR
را لغو می‌کند، اما در حال حاضر مقدار تنظیم‌شده در
\fBcore\&.logAllRefUpdates\fR
را خنثی نمی‌کند\&.
.RE
.PP
\fB\-\-format=\fR\fI<format>\fR
.RS 4
رشته‌ای که
\fB%\fR(\fBfieldname\fR)
را از یک مرجع تگ در حال نمایش و شیئی که به آن اشاره دارد جایگزین می‌کند\&. ساختار آن مشابه
\fBgit-for-each-ref\fR(1)
است\&. در صورت عدم تعیین، پیش‌فرض
\fB%\fR(\fBrefname:strip=2\fR)
است\&.
.RE
.PP
\fI<tagname>\fR
.RS 4
نام تگی که قرار است ایجاد، حذف یا توصیف شود\&. نام تگ جدید باید از تمام بررسی‌های تعریف‌شده توسط
\fBgit-check-ref-format\fR(1)
عبور کند\&. برخی از این بررسی‌ها ممکن است نویسه‌های مجاز در یک نام تگ را محدود کنند\&.
.RE
.PP
\fI<commit>\fR, \fI<object>\fR
.RS 4
شیئی که تگ جدید به آن اشاره خواهد کرد، معمولاً یک کامیت\&. پیش‌فرض
\fBHEAD\fR
است\&.
.RE
.SH "پیکربندی (CONFIGURATION)"
.sp
به‌طور پیش‌فرض، \fBgit\fR \fBtag\fR در حالت امضا با پیش‌فرض (\fB\-s\fR) از هویت کامیت‌کننده شما (به شکل \fBYour\fR \fBName\fR <your@email\&.address>) برای یافتن کلید استفاده می‌کند\&. اگر می‌خواهید از کلید پیش‌فرض متفاوتی استفاده کنید، می‌توانید آن را در پیکربندی مخزن به شکل زیر تعیین کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
[user]
    signingKey = <key\-id>
.fi
.if n \{\
.RE
.\}
.sp
.sp
پشت‌بند امضا را می‌توان با متغیر پیکربندی \fBgpg\&.format\fR انتخاب کرد که مقدار پیش‌فرض آن \fBopenpgp\fR است\&. برای فهرستی از سایر قالب‌های پشتیبانی‌شده به \fBgit-config\fR(1) مراجعه کنید\&.
.sp
مسیر برنامه‌ای که برای هر پشت‌بند امضا استفاده می‌شود را می‌توان با متغیر پیکربندی \fBgpg\&.\fR\fI<format>\fR\fB\&.program\fR مشخص کرد\&. برای پشت‌بند \fBopenpgp\fR، می‌توان از \fBgpg\&.program\fR به عنوان مترادفی برای \fBgpg\&.openpgp\&.program\fR استفاده کرد\&. برای جزئیات به \fBgit-config\fR(1) مراجعه کنید\&.
.sp
متغیر \fBpager\&.tag\fR تنها هنگام فهرست کردن تگ‌ها رعایت می‌شود، یعنی زمانی که \fB\-l\fR استفاده شده یا ضمنی باشد\&. پیش‌فرض استفاده از صفحه‌بند (pager) است\&.
.sp
برای جزئیات بیشتر و سایر متغیرهای پیکربندی به \fBgit-config\fR(1) مراجعه کنید\&.
.SH "بحث و بررسی (DISCUSSION)"
.SS "درباره تگ‌گذاری مجدد (On Re\-tagging)"
.sp
هنگامی که به اشتباه یک کامیت نادرست را تگ می‌کنید و می‌خواهید مجدداً تگ بگذارید، چه باید بکنید؟
.sp
اگر هرگز چیزی را به بیرون push نکرده‌اید، فقط آن را مجدداً تگ بزنید\&. از \fB\-f\fR برای جایگزینی تگ قبلی استفاده کنید\&. و کار تمام است\&.
.sp
اما اگر تغییرات را push کرده‌اید (یا دیگران می‌توانستند مستقیماً مخزن شما را بخوانند)، آنگاه دیگران قبلاً تگ قدیمی را دیده‌اند\&. در این حالت می‌توانید یکی از این دو کار را انجام دهید:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
روش معقولانه\&. فقط بپذیرید که اشتباه کرده‌اید، و از نام متفاوتی استفاده کنید\&. دیگران قبلاً یک نام تگ را دیده‌اند، و اگر همان نام را نگه دارید، ممکن است در موقعیتی قرار بگیرید که دو نفر هر دو "نسخه X" را داشته باشند، اما در واقع نسخه‌های
\fIمتفاوتی\fR
از "X" را در اختیار داشته باشند\&. بنابراین فقط آن را "X\&.1" بنامید و کار را تمام کنید\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
روش غیرمعقول\&. شما واقعاً می‌خواهید نسخه جدید را هم "X" بنامید،
\fIحتی با اینکه\fR
دیگران قبلاً نسخه قدیمی را دیده‌اند\&. بنابراین مجدداً از
\fBgit\fR
\fBtag\fR
\fB\-f\fR
استفاده کنید، گویی که هرگز تگ قدیمی را منتشر نکرده بودید\&.
.RE
.sp
با این حال، گیت تگ‌ها را پشت سر کاربران تغییر \fBنمی‌دهد\fR (و نباید هم بدهد)\&. بنابراین اگر کسی قبلاً تگ قدیمی را دریافت کرده باشد، اجرای \fBgit\fR \fBpull\fR روی درخت شما نباید تگ قدیمی او را رونویسی کند\&.
.sp
اگر کسی یک تگ انتشار از شما دریافت کرده است، نمی‌توانید صرفاً با به‌روزرسانی تگ خودتان، تگ او را تغییر دهید\&. این یک مسئله امنیتی بزرگ است، زیرا افراد باید بتوانند به نام‌های تگ خود اطمینان کنند\&. اگر واقعاً می‌خواهید آن کار غیرمعقول را انجام دهید، باید صادقانه به آن اعتراف کنید و به افراد اطلاع دهید که دچار اشتباه شده‌اید\&. می‌توانید این کار را با یک اعلان عمومی به این صورت انجام دهید:
.sp
.if n \{\
.RS 4
.\}
.nf
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\&.
.fi
.if n \{\
.RE
.\}
.sp
.sp
آیا این کمی پیچیده به نظر می‌رسد؟ \fBباید هم باشد\fR\&. هیچ راهی وجود ندارد که "درست کردن" خودکار آن کار صحیحی باشد\&. افراد باید بدانند که ممکن است تگ‌هایشان تغییر کرده باشد\&.
.SS "درباره دنبال کردن خودکار (On Automatic following)"
.sp
اگر در حال دنبال کردن درخت شخص دیگری هستید، به احتمال زیاد از شاخه‌های ردیابی از راه دور (مانند \fBrefs/remotes/origin/master\fR) استفاده می‌کنید\&. شما معمولاً تگ‌های طرف مقابل را می‌خواهید\&.
.sp
از سوی دیگر، اگر به این دلیل fetch می‌کنید که می‌خواهید یک ادغام تک‌باره از شخص دیگری انجام دهید، معمولاً نمی‌خواهید تگ‌ها را از آنجا دریافت کنید\&. این موضوع بیشتر برای افراد نزدیک به بالاترین رده‌های پروژه اتفاق می‌افتد اما محدود به آن‌ها نیست\&. کاربران معمولی هنگام pull کردن از یکدیگر لزوماً نمی‌خواهند تگ‌های نقاط لنگرگاه خصوصی طرف مقابل را دریافت کنند\&.
.sp
اغلب، پیام‌های "لطفاً pull کنید" در فهرست پستی صرفاً دو بخش اطلاعاتی را ارائه می‌دهند: یک آدرس اینترنتی مخزن و یک نام شاخه؛ این قالب به گونه‌ای طراحی شده که به راحتی در انتهای یک خط فرمان \fBgit\fR \fBfetch\fR رونوشت و جای‌گذاری شود:
.sp
.if n \{\
.RS 4
.\}
.nf
Linus, please pull from

        git://git\&.\&.\&.\&./proj\&.git master

to get the following updates\&.\&.\&.
.fi
.if n \{\
.RE
.\}
.sp
.sp
تبدیل می‌شود به:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git pull git://git\&.\&.\&.\&./proj\&.git master
.fi
.if n \{\
.RE
.\}
.sp
.sp
در چنین شرایطی، شما مایل نیستید تگ‌های شخص دیگر را به طور خودکار دنبال کنید\&.
.sp
یکی از جنبه‌های مهم گیت ماهیت توزیع‌شده آن است، که اساساً بدان معناست که هیچ "بالادست" یا "پایین‌دست" ذاتی در سیستم وجود ندارد\&. در ظاهر، مثال بالا ممکن است نشان دهد که فضای نام تگ‌ها متعلق به سطوح بالای سلسله‌مراتب است و تگ‌ها فقط به سمت پایین جریان دارند، اما واقعیت چنین نیست\&. این صرفاً نشان می‌دهد که الگوی استفاده مشخص می‌کند چه کسانی به تگ‌های چه کسانی علاقه‌مندند\&.
.sp
یک pull تک‌باره نشانه‌ای از این است که تاریخچه کامیت اکنون در حال عبور از مرز میان یک گروه از افراد (مثلاً "افرادی که بیشتر به بخش شبکه هسته علاقه‌مندند") که ممکن است مجموعه تگ‌های خود را داشته باشند (مثلاً "این سومین نامزد انتشار از گروه شبکه است که برای استفاده عمومی با انتشار 2\&.6\&.21 پیشنهاد می‌شود") به گروه دیگری از افراد (مثلاً "افرادی که بهبودهای زیرسیستم‌های مختلف را ادغام می‌کنند") است\&. گروه دوم معمولاً به تگ‌های تفصیلی که به صورت داخلی در گروه اول استفاده می‌شوند علاقه‌ای ندارند (معنای "داخلی" همین است)\&. به همین دلیل مطلوب است که در این حالت تگ‌ها به صورت خودکار دنبال نشوند\&.
.sp
ممکن است افراد بخش شبکه بخواهند تگ‌های داخلی گروه خود را مبادله کنند، اما در آن گردش کار احتمالاً از طریق شاخه‌های ردیابی از راه دور پیشرفت یکدیگر را دنبال می‌کنند\&. در این حالت نیز منطق دنبال کردن خودکار چنین تگ‌هایی بسیار سودمند است\&.
.SS "درباره تاریخ‌گذاری گذشته‌نگر تگ‌ها (On Backdating Tags)"
.sp
اگر تغییراتی را از یک سیستم کنترل نسخه دیگر وارد کرده‌اید و می‌خواهید تگ‌هایی برای انتشار‌های اصلی کار خود اضافه کنید، تعیین تاریخی برای گنجاندن در شیء تگ بسیار سودمند است؛ این داده در شیء تگ، برای مثال، بر ترتیب نمایش تگ‌ها در رابط وب‌گیت (gitweb) تأثیر می‌گذارد\&.
.sp
برای تعیین تاریخ مورد استفاده در اشیاء تگ آینده، متغیر محیطی GIT_COMMITTER_DATE را تنظیم کنید (به بحث بعدی پیرامون مقادیر ممکن مراجعه فرمایید؛ رایج‌ترین قالب "YYYY\-MM\-DD HH:MM" است)\&.
.sp
برای مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
$ GIT_COMMITTER_DATE="2006\-10\-02 10:31" git tag \-s v1\&.0\&.1
.fi
.if n \{\
.RE
.\}
.sp
.SH "قالب‌های تاریخ (DATE FORMATS)"
.sp
متغیرهای محیطی \fBGIT_AUTHOR_DATE\fR و \fBGIT_COMMITTER_DATE\fR از قالب‌های تاریخ زیر پشتیبانی می‌کنند:
.PP
قالب داخلی گیت (Git internal format)
.RS 4
به صورت
\fI<unix\-timestamp>\fR
\fI<time\-zone\-offset>\fR
است، که در آن
\fI<unix\-timestamp>\fR
تعداد ثانیه‌ها از مبدأ یونیکس (UNIX epoch) است\&.
\fI<time\-zone\-offset>\fR
یک افست زمانی مثبت یا منفی از UTC است\&. برای مثال CET (که یک ساعت جلوتر از UTC است) برابر با
\fB+0100\fR
است\&.
.sp
ایمن‌تر است که پیش از
\fI<unix\-timestamp>\fR
علامت
\fB@\fR
قرار دهید (مثلاً
\fB@0\fR
\fB+0000\fR)،
که گیت را وادار می‌کند آن را به عنوان یک برچسب زمانی خام تفسیر کند\&. این کار برای مقادیر کمتر از ۱۰۰٬۰۰۰٬۰۰۰ (که کمتر از ۹ رقم دارند) الزامی است تا از اشتباه گرفته شدن با سایر قالب‌های تاریخ مانند
\fBYYYYMMDD\fR
جلوگیری شود\&.
.RE
.PP
استاندارد RFC 2822
.RS 4
قالب تاریخ استاندارد طبق استاندارد RFC 2822، به عنوان مثال
\fBThu\fR,
\fB07\fR
\fBApr\fR
\fB2005\fR
\fB22:13:13\fR
\fB+0200\fR\&.
.RE
.PP
استاندارد ISO 8601
.RS 4
زمان و تاریخ تعیین‌شده طبق استاندارد ISO 8601، به عنوان مثال
\fB2005\-04\-07T22:13:13\fR\&.
تجزیه‌کننده یک فاصله را نیز به جای نویسه
\fBT\fR
می‌پذیرد\&. بخش‌های کسری ثانیه نادیده گرفته می‌شوند، برای مثال
\fB2005\-04\-07T22:13:13\&.019\fR
مانند
\fB2005\-04\-07T22:13:13\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
علاوه بر این، بخش تاریخ در قالب‌های زیر نیز پذیرفته می‌شود:
\fBYYYY\&.MM\&.DD\fR،
\fBMM/DD/YYYY\fR
و
\fBDD\&.MM\&.YYYY\fR\&.
.sp .5v
.RE
.RE
.SH "فایل‌ها (FILES)"
.PP
\fB$GIT_DIR/TAG_EDITMSG\fR
.RS 4
این فایل حاوی پیام یک تگ حاشیه‌نویسی‌شده در حال انجام است\&. اگر
\fBgit\fR
\fBtag\fR
پیش از ایجاد تگ حاشیه‌نویسی‌شده با خطا متوقف شود، پیام تگی که توسط کاربر در نشست ویرایشگر ارائه شده بود در این فایل باقی خواهد ماند، اما ممکن است با اجرای بعدی
\fBgit\fR
\fBtag\fR
رونویسی گردد\&.
.RE
.SH "پیکربندی (CONFIGURATION)"
.sp
تمام موارد زیر این خط در این بخش به صورت گزینش‌شده از مستندات \fBgit-config\fR(1) گنجانده شده است\&. محتوا معادل همان چیزی است که در آنجا یافت می‌شود:
.PP
\fBtag\&.forceSignAnnotated\fR
.RS 4
یک مقدار بولی که مشخص می‌کند آیا تگ‌های حاشیه‌نویسی‌شده ایجادشده باید با GPG امضا شوند یا خیر\&. اگر
\fB\-\-annotate\fR
در خط فرمان مشخص شده باشد، بر این گزینه اولویت دارد\&.
.RE
.PP
\fBtag\&.sort\fR
.RS 4
این متغیر ترتیب مرتب‌سازی تگ‌ها را هنگام نمایش با
\fBgit\-tag\fR
کنترل می‌کند\&. در صورت عدم ارائه گزینه
\fB\-\-sort=\fR\fI<value>\fR،
مقدار این متغیر به عنوان پیش‌فرض در نظر گرفته می‌شود\&.
.RE
.PP
\fBtag\&.gpgSign\fR
.RS 4
یک مقدار بولی که مشخص می‌کند آیا تمام تگ‌ها باید با GPG امضا شوند یا خیر\&. استفاده از این گزینه در اسکریپت‌های خودکار ممکن است موجب امضای تعداد زیادی تگ شود\&. بنابراین استفاده از یک کارگزار (agent) برای پرهیز از تایپ مکرر عبارت عبور GPG پیشنهاد می‌شود\&. توجه داشته باشید که این گزینه بر رفتار امضای تگ که با گزینه‌های
\fB\-u\fR
\fI<keyid>\fR
یا
\fB\-\-local\-user=\fR\fI<keyid>\fR
فعال شده باشد، تأثیری ندارد\&.
.RE
.SH "نکات (NOTES)"
.sp
هنگام ترکیب چند فیلتر \fB\-\-contains\fR و \fB\-\-no\-contains\fR، تنها مراجعی نشان داده می‌شوند که حداقل شامل یکی از کامیت‌های \fB\-\-contains\fR بوده و شامل هیچ‌یک از کامیت‌های \fB\-\-no\-contains\fR نباشند\&.
.sp
هنگام ترکیب چند فیلتر \fB\-\-merged\fR و \fB\-\-no\-merged\fR، تنها مراجعی نشان داده می‌شوند که از حداقل یکی از کامیت‌های \fB\-\-merged\fR قابل دسترس بوده و از هیچ‌یک از کامیت‌های \fB\-\-no\-merged\fR قابل دسترس نباشند\&.
.SH "همچنین ببینید (SEE ALSO)"
.sp
\fBgit-check-ref-format\fR(1)\&. \fBgit-config\fR(1)\&.
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)