راه کار های مدیریت بهتر پروژه‌ها در Git

پ.ن: این مقاله برای کسانی مناسب است که حداقل آشنایی لازم و تجربه کار با Git را داشته باشند.

مهم ترین دغدغه مدیریت پروژه در GIT

همانطور که مطلع هستید، Git یک ابزار برای مدیریت تغییرات در یک پروژه است، به عنوان مثال در تیم های کوچک (۲ تا ۳ نفره)، استفاده از گیت به سادگی قابل انجام است و تا حدودی نیز کمک کننده است؛ حال اگر بخواهیم این مسئله را به پروژه های بلند مدت و با پیچیدگی و وابستگی های بالا یا به اجرای پروژه در تیم های بزرگتر تعمیم دهیم، آن وقت چه اتفاقی رخ خواهد داد؟

اینجاست که اگر قوانین سختگیرانه‌ای در مورد "چگونگی اعمال تغییرات روی خود Git" نداشته باشیم؛ ممکن است در دراز مدت شاهد یک پروژه با Git بسیار بهم ریخته و اصطلاحا شلخته روبه‌رو شویم.

چرا اینقدر پروژه‌ام در GIT بهم ریخته اس؟

دلایل زیادی میتواند باعث بهم ریختگی پروژه شود؛ در ادامه چند مورد از دلایلی که طبق تجربه خودم، از عوامل تخریب نظم پروژه هستند را باهم بررسی میکنیم:

• طول عمر زیاد Branchهای پروژه
• عدم وجود مدیریت منسجم روی Merge شدن Branchها
• عدم وجود رابطه کامل بین نرم افزار Project manager مانند Jira با نرم‌افزار کنترل نسخه مانند Git
• عدم وجود قائده کامنت گذاری مشخص
• عدم وجود قائده مشخصی برای ایجاد Branchها و نام‌گذاری آنها
• و دلایل دیگر...

نمونه ای از مشکلات بهم ریختگی پروژه

حال بیاید یک نمونه از پروژه های که از ابتدا بدون هیچ قانون و مدیریت خاصی روی Git تاکنون پیشرفت کرده را باهم بررسی کنیم؛ توجه کنید این پروژه یک پروژه موفق و پر بازده است، ما قرار است در بخش فنی و صرفا از نظر تکنیکال آن را مورد بررسی قرار دهیم.

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

در ادامه سعی کنید چند سوال خیلی مهم را با توجه به وضعیت پروژه در تصویر بالا پاسخ دهید:

• آخرین نسخه پایدار پروژه کجاست؟
• آخرین نسخه منتشر شده پروژه کجاست؟
• هر Branch مربوط به چه Task یا Bug است؟
• قاعده نام‌گذاری Branch ها چیست؟
• برای شروع تغییرات از کجا شروع کنیم؟
• مدیریت تغییرات روی Branch ها چطور انجام می‌شود؟
• تفاوت Branchهایی که عنوان master را یدک میکشند با یکدیگر چیست؟
• تفاوت پوشه Bug و Bugfix چیست؟
• تفاوت Branchهایی که در خارج از پوشه ها ساخته شده اند با مابقی Branchها چیست؟

اگر توانستید تمام سوالات بالا را جواب دهید؛ این مقاله به درد شما نمیخورد پس آن را ببندید و از وجود چنین مقاله ای اظهار بی‌اطلاعی کنید چون شما در Levelهای بالاتری از من و ۹۹ درصد توسعه دهندگان جهان زندگی می‌کنید.

خب راه کار مناسب برای جلوگیری از مشکل پیش آمده و شفاف کردن مسائل مطرح شده در سوالات بالا، چیست؟ اینجاست که ما با مفهومی به اسم Git Flow آشنا میشویم.

قهرمان داستان ما، GIT FLOW!!!

همانطور که در بحث مهندسی نرم افزار مفهومی تحت عنوان روش های مدیریت پروژه مانند Scrum, Agile, XP و موارد مشابه داریم، در بحث مدیریت Git نیز چنین مفاهیمی برای این مسئله داریم که شامل یک سری قوانین و اصول از پیش تعریف شده هستند که میتوانند بر اساس سیاست ها و ساختار هر تیم، شخصی‌سازی و مورد استفاده قرار گیرند؛ کلمه Git Flow در حقیقت اسم یکی از ابزار هایی است که Git برای مدیریتش در اختیار ما قرار می‌دهد.

وظایف GIT FLOW

از مهمترین وظایفی گه ما از Git Flow انتظار داریم برای ما برآورده کند، میتوانیم به موارد زیر اشاره کنیم:

• مشخص کردن نقش هر عضو از تیم یا پروژه در Git
• جلوگیری از بهم ریختگی های احتمالی
• بالا بردن ضریب اطمینان و سادگی کار با Git
• مشخص کردن Branch ها با موضوعات مشخص
• تسریع مدیریت Branch ها و جلوگیری از بروز تداخل
• دسترسی هر چه سریعتر به نسخه های موردنظر در پروژه
• حفظ کردن تاریخچه تغییرات مشترک مرتبط با هر Task

دسته بندی Branch‌ها در GIT FLOW

در فرایند Git Flow تمامی Branchها به چند دسته‌بندی زیر تقسیم می‌شوند و ساخت یک Branch خارج از این دسته‌بندی باعث بروز مشکلات گفته شده می‌شود.

ساختار موضوعی Branchها

• خوشه Master: شامل آخرین نسخه پایدار منتشر شده
• خوشه Develop: شامل آخرین نسخه پایدار توسعه یافته
• پوشه Hotfix: شامل نسخه های پایدار برای آپدیت های اورژانسی
• پوشه Release: شامل نسخه های رسمی منتشر شده
• پوشه Feature: شامل نسخه های پایدار دارای فقط یک ویژگی جدید یا بهبود یافته
• پوشه Bugfix: شامل نسخه های پایدار عاری از مشکلات شناسایی شده
• پوشه Upgrade: شامل نسخه های پایدار از تغییرات در ساختار فنی و هسته اصلی پروژه

مشخصات خوشه Master، تجسمی از اعتماد و پایداری

• شامل آخرین نسخه Production یا منتشر شده از پروژه است.
• هیچ کسی از پروژه مجاز به اعمال حتی یک Commit روی این Branch نیست.
• تنها عملیات مجاز، عمل Merge از سایر Branchهای پایدار است.
• تنها مدیر پروژه مجاز به اعمال تغییرات یا Merge است.
• نسخه ها با Tag منحصر به فرد قابل شناسایی هستند.
• هر نسخه بلافاصله بعد از Merge روی Master، منتشر میشود.
• تنها Branch های Hotfix و Release مجاز به Merge شدن روی Master هستند.

مشخصات خوشه Develop، دوست خوب من و تو

• شامل آخرین نسخه Development یا آماده انتشار از پروژه است.
• همه اعضای پروژه فقط مجاز به عمل Commit روی Develop هستند.
• تنها مدیر پروژه مجاز به عمل Merge روی Develop است.
• تمام Branchها مجاز هستند روی Develop ادغام شوند.
• تغییرات Develop از Master, Hotfix یا Release شروع میشود.
• میزان پایداری آن همانند Master است و همیشه آخرین نسخه پروژه در این Branch آماده انتشار است.

مشخصات پوشه Hotfix، اتاق عمل اورژانسی

فرض کنید بعد از یک ماه از انتشار آخرین نسخه، متوجه یک مشکل بحرانی در پروژه می‌شوید و از طرفی هم در شرایطی نیستید که بخواهید آخرین نسخه توسعه یافته پروژه خود را منتشر کنید یا اصطلاحا آپدیت جدید داشته باشید؛ در چنین شرایطی باید از Master یک Sub-Branch تحت عنوان Hotfix ایجاد کرده و بعد از رفع مشکل بلافاصله مجددا روی Master ادغام شود؛ بدیهی است که بعد از ادغام روی Master، تغییرات منتشر میشود.

مشخصات اصلی خوشه های زیر مجموعه از Hotfix به شرح زیر است:

• شامل نسخه هایی برای آپدیتهای بحرانی پروژه است.
• تغییرات آن از Master شروع میشود.
• درجه پایداری و اهمیت آن همانند Master است.
• همه اعضا فقط مجاز به اعمال Commit روی Hotfix هستند.
• تغییرات Hotfix تنها روی Develop و Master ادغام میشود.
• بعد از عمل Merge، نسخه به دست آمده مستقیماْ منتشر میشود.

مشخصات پوشه Feature[s]، تالار آفرینش

به طور کلی، هر ویژگی جدیدی که قرار است به پروژه اضافه شود یا هر تغییری که قرار است در ویژگی های فعلی پروژه اعمال شود، تحت عنوان Feature-Branch روی پروژه اعمال میشود.

همانطور که در جمله بالا مشخص است، برای تغییر روی ویژگی های فعلی پروژه باید از Feature استفاده کرد، حال اگر برای ویژگی موردنظر و Task مربوط به آن، از قبل یک Feature-Branch موجود باشد با ادغام Develop روی آن Branch، تغییرات را ادامه میدهیم در غیر این صورت برای تغییرات موردنظر یک ‌Feature-Branch جدید میسازیم.

مشخصات اصلی خوشه های زیر مجموعه از Feature به شرح زیر است:

• شامل نسخه هایی با ویژگی های جدید است.
• تغییرات آن از Develop شروع می‌شود.
• همه اعضای پروژه فقط مجاز به اعمال Commit هستند.
• تغییرات آن تنها روی Develop ادغام می‌شود.
• درجه پایداری آن همانند Develop است.
• در زمان آینده و بعد از Merge میتواند پایدارتر شود.
• از روی Feature هیچ Sub-Branch دیگری ساخته نمی‌شود.

در دسته‌بندی Branch های Git Flow، دو پوشه اختیاری به نام های ‌Bugfix و Upgrade مشاهده میشود که مشخصات و قوانین آن دقیقا مشابه Feature است؛ فقط در مورد Bugfix تنها نکته حائز اهمیت این است که اگر رفع مشکل مربوطه، فقط با یک Commit قابل حل باشد، تغییرات مربوط به آن روی Develop اعمال میشود در غیر این صورت یک Branch جدید تحت عنوان Bugfix برای آن ساخته میشود.

مشخصات پوشه Release، محلی برای رستگاری

هنگامی که تصمیم میگیریم یک نسخه جدید از آخرین تغییرات توسعه یافته پروژه را منتشر کنیم باید یکسری تغییرات روی پروژه اعمال کنیم که پیش زمینه انتشار نسخه جدید است، به عنوان مثال تغییر در Version Code پروژه، Rebuild پلاگین های مورد استفاده، جابجایی بین پلاگین های Market-Base مانند پلاگین های پرداخت و سایر تغییراتی که صرفا در فرایند آماده سازی خروجی برای نسخه جدید روی پروژه اعمال میشود؛ همگی از جمله تغییراتی هستند که تحت عنوان Release-Branch روی پروژه اعمال میشود.

مشخصات اصلی خوشه های زیر مجموعه از Release به شرح زیر است:

• شامل نسخه های رسمی و منتشر شده از پروژه است.
• تغییرات آن از Develop شروع میشود.
• همه اعضای پروژه فقط مجاز به اعمال Commit هستند.
• تغییرات آن تنها روی Develop و Master ادغام میشود.
• درجه پایداری آن همانند Master است
• دامنه تغییرات آن فقط در حد تغییر روی Build tagها و پیشنیاز های New-Build است.

چطور از Git Flow استفاده کنیم؟

(۱) استفاده از Command و ابزار Git Flow

همانطور که قبلا اشاره کردم، Git Flow یکی از ابزارها و دستورات Git است که برای تسهیل فرایند و قوانین گفته شده توسعه یافته است و میتوانید با اجرای دستور `git flow` و دستورات start و finish نسبت به مدیریت Flow خود اقدام کنید.

(۲) رعایت اصول مربوط به Git Flow در مدیریت Git

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

اصول اولیه در Git Flow برای مدیریت Git

دسته بندی توسعه دهندگان پروژه

اولین اصل مهم در مدیریت Git، مشخص کردن نقش هر عضو از پروژه در سیستم Git است؛ شخصیت ها در پروژه به ۵ دسته زیر دسته‌بندی میشوند:

1. Project Manager
2. Maintainer
3. Developer
4. Reporter
5. Guest

بررسی تفاوت های هر کدام از نقش های بالا خارج از حوصله این مقاله است، در صورتی که علاقه‌مند به آشنایی با این مفاهیم هستید میتوانید مقالات زیر را مطالعه کنید:
Repository roles for an organization on Git-Hub
Permissions and roles on Git-Lab

پس از مشخص کردن نقش هر شخص در پروژه، عملیات های اصلی روی Branchها در Git بر اساس جدول زیر میتواند انجام شود:

به دلیل عدم اثر گذاری نقش های Reporter و Guest در فرایند Git Flow، از آوردن آنها در جدول بالا خودداری کردیم.

قوانین کنترل Branchها

دومین و مهمترین اصل در مدیریت Git، قوانین مرتبط با کنترل Branchهای پروژه است چون ساختار و دسته‌بندی اصلی پروژه را مشخص میکند؛ این قوانین به شرح زیر است:

در اینجا فرض بر این است که برای مدیریت پیشرفت پروژه از Jira استفاده میشود و ارتباط بین Jira با Git به درستی برقرار بوده و همچنین قابلیت Smart Comment نیز فعال است.

• اعمال مستقیم Merge رو هر Branch غیرمجاز است.

هیچ کس حتی مدیر پروژه نمیتواند با دستور Merge این کار را مستقیما روی Branchها انجام دهد.

• تمام Mergeها در قالب یک Merge Request یا Pull Request برای مدیر پروژه ارسال میشود.

پس از ارسال درخواست ادغام Branchها، افرادی که قبلتر به آن اشاره کردم با بررسی سلسله تغییرات و تایید آنها، عملیات Merge را انجام میدهند.

• نام‌گذاری هر Branch باید بر اساس قالب زیر انجام شود.

{Base Git Address}/[Optional Branch Name]_[Jira Code]
origin/features/featureTestA_PFT-16

• شماره Task یا Jira Code در پیام هر Commit با قالب [ProjectCode-XX] درج شود.
• شماره Sprint یا Task در پیام هر Merge درج شود.

مشخصا هر ادغامی که صورت میگیرد نتیجه تکمیل شدن یک Sprint یا Task است که با درج کردن شماره آن در پیام هر Merge میتوان در آینده، ارتباط بهتری با تغییرات انجام شده برقرار کرد و بررسی مشکلات احتمالی را ساده‌تر میکند.

• برای پروژه های مشترک نام گذاری Branchها یکسان است.

به عنوان مثال، ممکن است یک پروژه شامل دو پروژه Server و Client باشد و یک Task نیازمند تغییرات مشترکی برای هر دو طرف پروژه باشد در چنین شرایطی نام‌گذاری Branch مربوطه برای هر دو طرف یکسان انجام میشود.

بررسی یک نجات یافته توسط Git Flow

در انتهای مقاله نیز به بررسی یکی از پروژه هایی که بیش از ۱ سال، اصول و قوانین Git Flow روی آن رعایت شده میپردازیم:

پ.ن ۱: به علت حفظ اصل محرمانگی داده و جلوگیری از آشکار شدن مشخصات پروژه، قسمت هایی که شامل اطلاعات حساس هستند از داخل تصویر بالا حذف شده‌اند.
پ.ن ۲: قسمت های قرمز رنگ همان پیشوند مربوط به پروژه در Jira است که در نام‌گذاری Branchها رعایت شده است.

حالا میتوانید سوالاتی که در ابتدای مقاله مطرح شد را اینجا از خود بپرسید و با توجه نکات مطرح شده و اطلاعات حاضر در تصویر بالا، به آن پاسخ دهید.

منتظر پیشنهادات و انتقادات سازنده. شما دوستان در این حوزه هستم.

موفق و سربلند باشید