tagging.asc

برجسب‌گذاری

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

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

فهرست برچسب های موجود

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

$ git tag
v1.0
v2.0

این دستور، برچسب های موجود را به ترتیب حرف الفبا نشان می دهد; درواقع ترتیب نمایش آنها هیچ اهمیتی ندارد. همچنین می توان برچسب ها را جست و جو کنید و از الگوها نیز بهره‌مند شوید. برای نمونه مخزن اصلی گیت، بیش از 500 برچسب دارد. مثلا اگر می‌خواید تنها به دنبال برجسب‌های سری 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

Note

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

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

گیت دو گونه برچسب دارد: lightweight یا موقت و annotated یا توضیحی.

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

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

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

برچسب‌های توضیحی

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

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

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

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

$ git show v1.4
tag v1.4
Tagger: Ben Straub <[email protected]>
Date:   Sat May 3 20:19:12 2014 -0700

my version 1.4

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <[email protected]>
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 <[email protected]>
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

حالا فرض کنید که در کامیت updated rakefile فراموش کرده‌اید پروژ را با v1.2 تگ گذاری کنید. پس از کامیت می‌توانید این کار را انجام دهید.

برای تگ کردن کامیت مورد نظر، هش کد کامیت مورد نظر را در اخر دستور وارد کنید.

$ 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 <[email protected]>
Date:   Mon Feb 9 15:32:16 2009 -0800

version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <[email protected]>
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 [email protected]: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 [email protected]:schacon/simplegit.git
 * [new tag]         v1.4 -> v1.4
 * [new tag]         v1.4-lw -> v1.4-lw

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

Note	دستور 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/{tagnam}:

$ git push origin :refs/tags/v1.4-lw
To /[email protected]: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» اگر تغییراتی ایجاد کنید و آنها را کامیت کنید، تگ تغییر نخواهد کرد، اما کامیت شما در هیچ کدام از شاخه‌ها ثبت نخواهد شد و از دست می‌رود. مگر با کد کامل hash مربوط به آن کامیت. بنابراین اگر نیاز به ایجاد تغییرات دارید — مثلا می‌خواهید یک باگ را در نسخه‌های پیشین برطرف نمایید — شماه باید یک شاخهٔ جدید بسازید.

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

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