در پست قبلی مم سعی کردم گیت رو به زبان ساده توضیح بدم و راه اندازی و استفاده اش رو هم ساده بیان کنیم.
در این پست الگوی توسعه ای را ارائه می دهم که من حدود یک سال پیش برای برخی از پروژه های خود (اعم از محل کار و خصوصی) معرفی کرده ام ، و بسیار موفق است. فقط در مورد جزئیات پروژه ها صحبت نخواهم کرد و در مورد استراتژی برنچ و مدیریت انتشار ها (Release) صحبت خواهم کرد.
برای رسیدن به پاسخ این سوال بحث های زیادی در بستر نت شده است و میتوان با یک جستجو به همه این ها رسید، پس ما هزینه ای برای توضیح این مورد نکرده و به گام بعدی میرویم.
ما همیشه دو برنچ داریم که عمر آنها نامتناهی است و هیچوقت پاک نمیشود.
برنچ Master که برای همه برنامه نویسان که با گیت کار میکنن آشناست، برنچی که همیشه محصول آماده برای انتشار در آن قرار میگیرد و به قولی مطمئن ترین نسخه و همچنین تست شده ترین از سیستم در حال توسعه در این برنچ قرار داد، برنچ Develop هم همتراز با برنچ Master پیش میره و همه توسعه ما و آخرین تغییرات تحویل داده شده توسط برنامه نویسان روی این برنچ می باشد.
وقتی که کد در برنچ Develop به یک نقطه پایدار میرسه و آماده انتشار میشه، باید تمام تغییرات را به نوعی در Master ادغام کرده و با شماره انتشار برچسب گذاری کنید. در مورد چگونگی انجام این کار به تفصیل در ادامه بحث خواهد شد.
در کنار برنچ های Master و Develop ، مدل توسعه ما از انواع مختلفی از برنچ ها برای کمک به توسعه موازی بین اعضای تیم حمایت میکند،که برای ردیابی ویژگی‌ها، آماده‌سازی برای انتشار نسخه و کمک به حل سریع مشکلات لحظه ای استفاده می شود. بر خلاف شاخه Master، این برنچ ها همیشه زمان محدودی دارند، چون در نهایت حذف خواهند شد.
انواع مختلفی که ما استفاده میکنیم عبارتند از:
هرکدام از این برنچ ها برای هدف خاصی ایجاد میشوند و همینطور مشخص میشود که از کدام برنچ انشعاب گرفته میشوند و کدام برنچ برای Merge شدن با آنها است.
به هیچ وجه این برنچ ها خاص نیستند و فقط ما برای هدف های خاصی این دسته بندی ها را ایجاد کرده ایم.
همینطور که از نام این دسته مشخص هست برای اضافه کردن ویژگی های جدید به سورس از این نوع برنچ ها استفاده میکنیم که برنچ ها از Develop منشعب شده و دوباره با همین برنچ ادغام (Merge) خواهند شد.
هرگز برای نام گذاری برنچ های منشعب شده از اسامی زیر استفاده ننمایید:
master, develop, release-*, hotfix-*
برنچ های feature برای توسعه ویژگی های جدید برای نسخه آینده یا آینده دور استفاده می شوند. هنگام شروع یک ویژگی جدید، تاریخ لانچ این ویژگی ممکن است در لحظه شروع ناشناخته باشد. ماهیت یک شاخه ویژگی این است که تا زمانی که این ویژگی در حال توسعه است ، وجود دارد ، اما در نهایت دوباره با develop ادغام می شود (قطعاً ویژگی جدید را به نسخه بعدی اضافه می کنیم) یا حذف(دور ریخته) می شود (در صورتی که تست ناامید کننده ای داشته باشد).
این برنچ ها فقط در برنچ های برنامه نویس موجود هستیند و در origin وجود ندارند.
از این نوع برنچ برای تهیه نسخه های بیلد استفاده میکنیم در واقع وقتی میخواهیم نسخه ای استیبل از سیستم با ویژگی های جدید خروجی گرفته شود از این نوع استفاده میکنیم.
وقتی به نقطه ای میرسیم که میتوانیم یک release از سورس داشته باشیم به این معنی هست که تمامی feature برنچ های که ادغام شده اند عملا حذف گردید و برنچ develop برای ایجاد feature های جدید آماده شده است.
برای هدف رفع باگ های بهرانی(critical) سیستم استفاده میشود و همیشه از برنچ master انشعاب شده و با برنچ های master یا develop میتواند ادغام شود.
از نظر عملکردی شبیه به نوع برنچ های Release می باشد و بعد از پایان هر برنچ یک نسخه production به نسخه اصلی اضافه میشود.
این برنچ به این گونه است که سایر برنچ ها منتظر اتمام این برنچ نمی مانند و همه به مسیر خودشان ادامه میدهند، فقط بعد از پایان و مرج با master , develop سایر برنچ ها میتوانند از برنچ های اصلی pull گرفته تا تغییرات hotfix ها را داشته باشند.
حالا که همه اینها رو متوجه شدیم تصویر اولی برای ما تصویر مبهمی نیست و یک توصیر کلی (big picture) از روند کار می باشد.
