برای مدیریت برنامه های بزرگ ، نسخه سازی ضروری است. این امر به ردیابی استقرار و تغییرات در طول زمان کمک می کند و توسعه را سازمان یافته و قابل اعتماد تر می کند. شماره نسخه های پاک هم به توسعه دهندگان و هم به کاربران این امکان را می دهد تا درک کنند که چه نوع به روزرسانی ها ساخته شده است – چه ویژگی های جدید ، رفع اشکال یا تغییر در. نسخه معنایی (SEMVER) شماره های نسخه واضح را به نرم افزار اختصاص می دهد ، در حالی که برچسب های GIT آن نسخه ها را در تاریخ پروژه علامت گذاری می کنند.
در این مقاله نحوه انتشار یک برنامه با استفاده از SEMVER و مدیریت مؤثر آن نسخه ها با برچسب های GIT توضیح داده شده است.
1. نسخه معنایی (SEMVER)
اساساً نسخه معنایی مجموعه ای از قوانین برای نسخه سازی یک پروژه به روشی استاندارد است. برای جزئیات بیشتر از مستندات رسمی نسخه های معنایی بروید.
-
بروزرسانی عمده: اولین بخش از نسخه نشان دهنده تغییرات اساسی است. اگر برنامه تغییراتی داشته باشد که سازگار با عقب نباشد ، این تعداد توسط افزایش می یابد
1بشر فرض کنید یک نرم افزار در حال حاضر روی نسخه اجرا می شود2.x.x، و به روزرسانی بعدی شامل بازگرداندن URI مسیر API برای واکشی لیست محصول است. در نسخه جدید ، نقطه پایانی قبلی دیگر کار نخواهد کرد. این یک محسوب می شود تغییر تغییر، بنابراین نسخه بعدی باید باشد3.x.xبشر -
به روزرسانی جزئی: بخش دوم نسخه نشانگر تغییرات جزئی است. اگر تغییرات به عقب سازگار باشند ، برخلاف تغییرات عمده ، باید قسمت دوم شماره نسخه توسط افزایش یابد
1بشر فرض کنید یک نرم افزار در حال حاضر روی نسخه اجرا می شود1.1.x، و به روزرسانی بعدی ، نقاط پایانی جدید را برای جستجو اضافه می کند که ویژگی های موجود را نمی شکند. این یک نیست تغییر تغییر، بنابراین نسخه بعدی خواهد بود1.2.xبشر -
پچ: قسمت سوم نسخه ، تکه هایی را نشان می دهد ، مانند رفع اشکال که سازگار با عقب هستند. فرض کنید یک نرم افزار در حال حاضر روی نسخه اجرا می شود
1.1.1و برخی از اشکالات دارد. اگر بروزرسانی بعدی فقط آن اشکالات را برطرف کند ، نسخه بعدی خواهد بود1.1.2بشر -
پیش انتشار: این قسمت با یک هیفن و به دنبال آن یک شناسه اضافه می شود (
alphaباbetaباrc، و غیره). این بدان معناست که این نرم افزار ناپایدار است و برای آزمایش در نظر گرفته شده است. در نسخه های معنایی هیچ قاعده ای سختگیرانه برای نام های قبل از انتشار وجود ندارد.alphaباbetaوتrcمعمولاً کنوانسیون های مورد استفاده قرار می گیرند ، نه الزامات. معمولاً ،alphaیعنی این نرم افزار در مرحله اولیه است و ممکن است اشکالات داشته باشد ،betaیعنی کامل تر اما هنوز ناپایدار است ، وrc(نامزد انتشار) به این معنی است که بروزرسانی تقریباً نهایی است و احتمالاً به انتشار تبدیل می شود مگر اینکه اشکالات اساسی پیدا شود. نسخه قبل از انتشار نیز می تواند شامل نقاطی باشد ، مانند در1.0.0-alpha.1بشر تصویر زیر یک مثال ساده از نسخه سازی از یک نسخه پایدار به نسخه دیگر را نشان می دهد.
-
ابرداده بسازید: این بخش اطلاعات اضافی در مورد نسخه دارد. این یک قسمت اختیاری است که پس از یک علامت به علاوه اضافه شده است (
+) ، مانند1.3.0+build.456یا1.3.0+build.457بشر از آن برای ارائه جزئیاتی مانند شماره ساخت ، تعهد ، محیط زیست و غیره استفاده می شود. بر اولویت نسخه تأثیر نمی گذاردبشر به عنوان مثال ، اگر یک نرم افزار برای دو مرحله مختلف ساخته شده باشد –productionوتstaging– ابرداده ساخت می تواند باشدx.y.z+prodیاx.y.z+stagingبشر همچنین می تواند محیط هایی مانند را مشخص کندx.y.z+linux-prodیاx.y.z+windows-prodبشر
1.1 قوانین مهم
- شناسه های عددی نمی توانند داشته باشند صفر پیشروبشر به عنوان مثال-
01.1.1با1.0.02، یا ،1.2.3-beta01یک نسخه معتبر نیست. - هنگامی که نسخه جزئی به روز شد ، نسخه پچ دوباره تنظیم می شود
0بشر وقتی نسخه اصلی به روز شد ، هر دو نسخه جزئی و پچ دوباره تنظیم می شوند0بشر - اولین نسخه عمومی باید از نسخه استفاده کند
1.0.0بشر نسخه اصلی صفر (0.y.z) برای توسعه اولیه است.
1.2 تقدم
- برتری با مقایسه شماره های نسخه از چپ به راست – مایجور ، جزئی و پچ – با استفاده از مقادیر عددی تصمیم گرفته می شود. یعنی
1.2.0>1.1.3>1.1.2بشر - اگر نسخه های اصلی ، جزئی و پچ یکسان باشند ، نسخه ای با برچسب قبل از انتشار ، دارای سابقه کمتری نسبت به نسخه بدون آن است. به عنوان مثال-
1.0.0برتری بالاتری از1.0.0-rcبشر - اگر شناسه های قبل از انتشار یکسان باشند ، مقادیر عددی که دنبال می شوند مقایسه می شوند. تعداد بالاتر به معنای برتری بالاتر است – برای مثال:
2.1.2-beta.12>2.1.2-beta.3>2.1.2-beta.2بشر
2. برچسب git
برچسب GIT یک اشاره گر برای یک تعهد خاص در یک مخزن است. برای علامت گذاری یک تعهد خاص در میان بسیاری دیگر مفید است. به عنوان مثال ، هنگامی که یک به روزرسانی نسخه انجام می شود ، می توان از یک برچسب استفاده کرد تا تعهد دقیقی را که در آن نسخه رخ داده است مشخص کنید. این امر ردیابی و اشاره به آن نقطه از تاریخ پروژه را آسان تر می کند.
مثال دیگر می تواند در زمینه توسعه برنامه های موبایل باشد ، هنگامی که برنامه به فروشگاه Play یا App Store منتشر می شود ، شامل یک نسخه ساخت و شماره ساخت است. هر نسخه باعث افزایش نسخه ساخت و شماره می شود. با این حال ، مخزن هیچ اطلاعاتی در مورد تغییر نسخه و شماره ساخت در مورد آن ندارد. برای مدیریت و ردیابی این نسخه ها ، می توان از برچسب های GIT استفاده کرد. هر زمان که نسخه ساخت تغییر کند ، باید یک برچسب جدید وجود داشته باشد.
جزئیات کامل را می توان در این مستندات یافت.
برای GitHub ، پیوند
https://github.com/تعهدات بین دو برچسب را نشان می دهد./ /compare/ ...
2.1 برچسب git ایجاد کنید
دو نوع برچسب وجود دارد – برچسب حاشیه نویسی وت برچسب سبک وزنبشر در برچسب حاشیه نویسی حاوی اطلاعات بیشتر در مورد برچسب (مانند پیام برچسب ، نام برچسب و ایمیل ، تاریخ ایجاد و زمان و غیره) است ، در حالی که a برچسب سبک وزن هیچ اطلاعاتی را شامل نمی شود. این اساساً متعهد است که در یک پرونده ذخیره می شود. برای نسخه های عمومی ، برچسب حاشیه نویسی توصیه می شود بوها برچسب سبک وزن می توان برای نشانک های سریع و برچسب های داخلی یا موقت استفاده کرد.
نام برچسب یک رشته بدون است spaceبا ~با ^با :با?با *با [با \ شخصیت ها. از شروع نام برچسب خودداری کنید -، با استفاده از ..با @{، پایان دادن به .lockبشر همچنین ، یک نام برچسب نباید شبیه نام شعبه باشد. بهترین روش این است که نام برچسب را به عنوان نسخه معنایی پروژه مانند v2.0.0با 1.0.0با 2.1.3-beta، و غیره قالب vX.Y.Z معمولاً استفاده می شود
دستور زیر یک برچسب GIT برای تعهد ایجاد می کند
# Annotated Tag
git tag -a -m ""
# Lightweight Tag
git tag
علاوه بر این ، اگر نیاز به ایجاد برچسب در برابر تعهد از قبل وجود داشته باشد ، می توان آن را با اضافه کردن چک تعهد (یا بخشی از آن) مانند- به دست آورد 9fceb02 در پایان فرمان.
git tag -a
توجه: نام برچسب تکراری مجاز نیست.
2.2 برچسب های git را در مخزن از راه دور فشار دهید
وقتی git push origin فرمان اجرا ، به طور پیش فرض برچسب ها را به مخزن از راه دور فشار نمی دهد – فقط به تعهدات فشار می آورد. با اضافه کردن --tags در پایان دستور ، برچسب ها در کنار تعهدات تحت فشار قرار می گیرند. اگر هیچ تعهدی برای فشار دادن وجود نداشته باشد ، فقط برچسب ها را تحت فشار قرار می دهد.
git push origin --tags
2.3 نشان دادن برچسب های git
برای دیدن لیست برچسب ها در مخزن ، دستور زیر باید اجرا شود:
git tag
# or
git tag -l
# or
git tag --list
توجه: این دستور برچسب ها را به ترتیب الفبایی لیست می کند.
برای دیدن اطلاعات برچسب خاص ، دستور زیر باید اجرا شود:
git show
در برچسب حاشیه نویسی اطلاعات بیشتر را در مقایسه با a نشان می دهد برچسب سبک وزنبشر
2.4 برچسب git را حذف کنید
برای حذف یک برچسب از مخزن محلی ، می توان از دستور زیر استفاده کرد:
git tag -d
دستور زیر برچسب را از مخزن از راه دور نیز حذف می کند:
git push origin --delete
پایان
در پایان ، نسخه معنایی با ارائه یک روش واضح و یکنواخت برای توصیف تغییرات در نرم افزار ، درک به روزرسانی ها را برای هم توسعه دهندگان و کاربران آسان تر می کند. کنترل نسخه در هنگام ترکیب با برچسب های GIT مفیدتر می شود و به تیم ها امکان می دهد نسخه های دقیق تر نسخه ها را پیگیری کرده و روند توسعه را سرعت بخشند. با اتخاذ این شیوه ها ، تیم ها می توانند کنترل بهتری بر رشد برنامه داشته باشند و با اطمینان به روزرسانی ها را ارائه دهند.
