Git 🌙
Chapters ▾ 2nd Edition

2.6 مقدمات گیت - برچسب‌گذاری

برچسب‌گذاری

مانند بیشتر VCSها، گیت قابلیت برچسب زدن در نقاطی خاص از تاریخچهٔ پروژه را به عنوان نقاط مهم دارد. معمولاً افراد از این قابلیت برای نشانه‌گذاری نسخه‌های قابل ارائه یا release استفاده می‌کنند (v1.0، v2.0 و به همین ترتیب). در این بخش می‌آموزید که چگونه برچسب‌های از پیش موجود را لیست کنید، چگونه برچسب بسازید و یا از بین ببرید و دیگر اینکه انواع مختلف تگ‌ها کدامند.

لیست‌کردن برچسب‌هایتان

لیست کردن برچسب‌های موجود در گیت بسیار ساده است. تنها نیاز است که دستور git tag (با -l و یا --list اختیاری) را وارد نمایید:

$ git tag
v1.0
v2.0

این دستور برچسب‌های موجود را به ترتیب حرف الفبا نشان می‌دهد؛ درواقع ترتیب نمایش آنها هیچ اهمیتی ندارد.

همچنین می‌توانید برچسب‌ها را بر اساس یک الگو خاص جستوجو کنید. برای نمونه مخزن اصلی گیت، بیش از ۵۰۰ برچسب دارد. مثلاً اگر می‌خواهید تنها به دنبال برچسب‌های سری 1.8.5 بگردید، می‌توانید دستور زیر را اجرا نمایید:

$ git tag -l "v1.8.5*"
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5
یادداشت
لیست کردن تگ‌ها با الگو‌ها نیازمند آپشن -l یا --list است

اگر صرفاً لیست کاملی از تگ‌ها می‌خواهید، با اجرای git tag دستور به طور ضمنی فرض می‌کند که به دنبال لیست کردن هستید و لیستی را به شما ارائه می‌کند؛ استفاده از -l یا --list در این مورد اختیاری است.

با این حال اگر خواستید یک لیستی مشخص با یک الگو را ببینید، استفاده از آپشن -l یا --list لازم است.

ساختن برچسب‌ها

گیت از دو نوع برچسب پشتیبانی می‌کند: lightweight یا سبک و annotated یا توصیف‌شده.

یک تگ سبک بسیار شبیه یک برنچ است که تغییر نمی‌کند — فقط یک نشانگر به کامیتی مشخص است.

با این حال، تگ‌‌‌های توصیف‌شده یا توضیحی به عنوان یک آبجکت کامل در پایگاه‌داده گیت ذخیره می‌شوند. آنها چک‌سام می‌شوند؛ شامل نام و ایمیل کسی که تگ را ثبت کرده و تاریخ می‌باشند؛ و می‌توانند با محافظ حریم خصوصی گنو (GNU Privacy Guard (GPG)) امضا و تأیید شوند. به طور کلی پیشنهاد می‌شود که از تگ توضیحی استفاده کنید تا در نتیجه‌ بتوانید تمام اطلاعات ذکر شده را داشته باشید؛ اما اگر می‌خواهید که یک تگ موقت ثبت کنید و بنا به دلایلی که نمی‌خواهید دیگر اطلاعات را نگه‌ دارید، تگ‌های موقت یا سبک هم موجود هستند.

برچسب‌های توصیف‌شده

ساخت یک برچسب توضیحی در گیت بسیار ساده است. آسان‌ترین راه افزودن آپشن -a هنگام اجرای دستور tag می‌باشد:

$ git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4

با آپشن -m می‌توانید یک پیام برچسب بنویسید که با تگ ذخیره می‌شود. اما اگر برای یک برچسب توضیحی پیامی مشخص نکنید، گیت ویرایشگر متن شما را برای نوشتن پیام تگ باز خواهد کرد.

شما می‌توانید اطلاعات مربوط به تگ را در کنار کامیتی که برچسب‌گذاری شده با استفاده از git show ببینید:

$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date:   Sat May 3 20:19:12 2014 -0700

my version 1.4

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    Change version number

این دستور اطلاعات تگ‌کننده، داده‌های کامیت برچسب گذاری شده و پیغام توضیحات را پیش از اطلاعات کامیت نشان می‌دهد.

برچسب‌های سبک

راه دیگری برای برچسب گذاری کامیت‌ها، برچسب سبک یا موقت است. این برچسب صرفاً چک‌سام کامیت است که در یک فایل ذخیره می‌شود — هیچ اطلاعات دیگری نگه‌داری نمی‌شود. برای ساخت یک برچسب موقت، هیچکدام از آپشن‌های -a، -s یا -m را بکار نگیرید، فقط نام برچسب را وارد نمایید.

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5

در این لحظه، اگر شما دستور git show بر روی تگ اجرا کنید؛ اطلاعات اضافی نمی‌بینید. این دستور فقط کامیت‌ را نشان می‌دهد:

$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    Change version number

بعداً برچسب گذاشتن

شما این امکان را دارید که بعد از چند کامیت، کامیت‌ها قبلی را تگ بزنید. فرض کنید تاریخچهٔ کامیت‌های شما شبیه این باشد:

$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 Create write support
0d52aaab4479697da7686c15f77a3d64d9165190 One more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc Add commit function
4682c3261057305bdd616e23b64b0857d832627b Add todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a Create write support
9fceb02d0ae598e95dc970b74767f19372d61af8 Update rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc Commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme

حالا فرض کنید که پروژه را در v1.2 برچسب‌گذاری کنید، که مثلاً در کامیت «Updated rakefile» بوده است. پس از کامیت می‌توانید این کار را انجام دهید. برای برچسب زدن به کامیت مورد نظر، هش کد کامیت مورد نظر را در آخر دستور وارد کنید.

$ git tag -a v1.2 9fceb02

می‌بینید که کامیت مورد نظر برچسب گذاری شده است:

$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5

$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Feb 9 15:32:16 2009 -0800

version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date:   Sun Apr 27 20:43:35 2008 -0700

    Update rakefile
...

اشتراک گذاری برچسب‌‌ها

دستور git push برچسب‌ها را به صورت پیش فرض به سرور منتقل نمی‌کند. شما باید برچسب‌ها را پس از ساخت و ایجاد آنها، مستقلاً به سرور انتقال دهید. این فرآیند دقیقاً شبیه انتقال و انتشار شاخه‌های ریموت است — شما می‌توانید دستور git push origin <tagname> را اجرا کنید:

$ git push origin v1.5
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
 * [new tag]         v1.5 -> v1.5

اگر برچسب‌های زیادی دارید که می‌خواهید همه را یکجا به سرور منتقل کنید، می‌توانید از گزینهٔ --tags در دستور git push استفاده نمایید. این دستور تمام تگ‌هایی را که در سرور نیستند به سرور منتقل خواهد کرد.

$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
 * [new tag]         v1.4 -> v1.4
 * [new tag]         v1.4-lw -> v1.4-lw

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

یادداشت
git push هر دو نوع برچسب را پوش می‌کند

فرستادن برچسب‌ها به سمت سرور با دستور git push <tagname> --tags هیچ وجه تمایزی بین تگ توضیحی یا تگ سبک قائل نمی‌شود؛ هیچ آپشن ساده‌ای برای انتخاب یک نوع تگ جهت پوش کردن وجود ندارد.

حذف کردن برچسب‌ها

برای حذف برچسب‌های ساخت شده در مخزن محلی خود، می‌توانید از دستور git tag -d <tagname> استفاده کنید. برای مثال، ما می‌توانیم تگ‌های سبک خود را با دستور زیر حذف کنیم:

$ git tag -d v1.4-lw
Deleted tag 'v1.4-lw' (was e7d5add)

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

اولین راه، git push <remote> :refs/tags/<tagname> است:

$ git push origin :refs/tags/v1.4-lw
To /git@github.com:schacon/simplegit.git
 - [deleted] v1.4-lw

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

راه دوم (و منطقی‌تر) برای حذف برچسب از یک ریموت دستور زیر است:

$ git push origin --delete <tagname>

چک‌اوت کردن برچسب‌ها

اگر می‌خواهید نسخه‌هایی از فایل‌هایی را که یک تگ به آنها اشاره می‌کند ببینید، می‌توانید یک git checkout از آن تگ انجام دهید، هرچند که این کار مخزن شما را در وضعیت «detached HEAD» قرار می‌دهد، که عوارض جانبی بدی دارد:

$ git checkout 2.0.0
Note: checking out '2.0.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch>

HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final

$ git checkout 2.0-beta-0.1
Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final
HEAD is now at df3f601... Add atlas.json and cover image

در وضعیت «detached HEAD» اگر تغییراتی ایجاد کنید و سپس آنها را کامیت کنید، برچسب تغییر نخواهد کرد، اما کامیت شما در هیچ کدام از شاخه‌ها ثبت نخواهد شد و غیرقابل دسترسی خواهد بود، مگر با هش دقیق آن. بنابراین اگر نیاز به ایجاد تغییرات دارید — مثلاً می‌خواهید یک باگ را در نسخه‌های پیشین برطرف نمایید — به طور کل بهتر است که یک شاخهٔ جدید بسازید.

$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'

اگر دستور بالا را اجرا کنید و یک کامیت بسازید، شاخه version2 کمی با برچسب v2.0.0 شما متفاوت خواهد بود، چراکه با تغییرات جدید شما به جلو خواهد رفت، بنابراین مراقب باشید.

scroll-to-top