همیشه با Git مشکل داشتم.
هر بار که میخواستم تغییری تو پروژه بدم، نمیدونستم دقیقاً کجا باید کد بزنم، از کجا برنچ بسازم، کی merge کنم و کی پاک کنم.
Git برام شده بود مثل یه جنگل تاریک بدون راهنما.
اما بعد از کلی کلنجار، نشستم تحقیق کردم، خوندم، تست کردم و بالاخره یه مدل پیدا کردم که ذهنمو از این آشفتهبازار نجات داد.
حالا اون تجربه رو با تو به اشتراک میذارم. شاید یه جرقهی جدید تو ذهن تو هم بزنه 💡
🧠 اول از همه: Git چیه، برنچ چیه؟
گیت یه سیستم کنترل نسخهست. یعنی میتونی باهاش همه تغییرات کدت رو مدیریت، پیگیری و اشتراکگذاری کنی.
برنچ یه مسیر جداگونه برای توسعه، بدون خراب کردن کد اصلی. مثلاً میخوای یه فیچر جدید بسازی؟ اول یه branch میزنی و تو اون کار میکنی.
خب حالا سوال اینه:
اگه ده نفر رو یه پروژه کار کنن، و هر کدوم یه کاری انجام بدن، چطوری این همه تغییر رو مدیریت کنیم؟
جوابش: یه ساختار مشخص برای برنچها، که اسمش هست Git Flow.
🌿 Git Flow – ساختار پیشنهادی برای نظم برنچها
Git Flow یه روش منظم برای ساخت برنچهاست که توسط آقای Vincent Driessen معرفی شد.
این روش بهت کمک میکنه بدونی: کی برنچ بسازی؟ از کجا بگیری؟ کِی و کجا مرج کنی؟ کِی پاکش کنی؟
🏗 ساختار اصلی Git Flow
🟩main (یا master)
نسخهی نهایی و پایدار پروژهست. همونی که کاربر میبینه. فقط چیزهایی که منتشر شدن اینجا قرار میگیرن.
🟩develop
همهی تغییرات در حال توسعه اینجا جمع میشن. مثل آشپزخونهایه که غذاها آماده میشن تا بعداً برن رستوران اصلی (main).
این برنچها بر اساس نوع کار ساخته میشن. بیا با مثالها بریم جلو:
مثلاً میخوای یه چت باکس بسازی؟ یه برنچ میزنی:
feature/notification
نکته: از develop ساخته میشه، به develop هم برمیگرده.
باگی پیدا کردی که بحرانی نیست ولی باید رفع بشه.
bugfix/fix-modal-close
نکته: از develop ساخته میشه، به develop هم برمیگرده.
یه باگ خیلی جدی تو نسخه منتشر شده پیدا شده. بلافاصله باید فیکس شه.
hotfix/fix-login-error
نکته: از main ساخته میشه. بعد از حل، به main برمیگرده و develop هم باهاش مرج میشه.
وقتی تو develop همه چیز آمادهی انتشار شد، یه برنچ میزنی برای نسخه جدید:
release/1.0.0
این برنچ فقط برای رفع باگهای نهایی، مستندسازی، تنظیم ورژن ساخته میشه و در نهایت مرج میشه به:
main برای انتشار و به develop برای هماهنگ شدن
اگه خواستی کد رو مرتبتر و قابلفهمتر کنی ولی خروجی همون باشه، میری سراغ refactor/
refactor/improve-auth-service
نکته: از develop ساخته میشه، به develop هم برمیگرده.
خب تا اینجا که یک نفر روی یک فیچر یا باگ بخواد کار کنه همه چیز ساده و قابل درکه اما فاجعه اصلی زمانی پیش میاد که قراره یک تیم روی یک فیچر کار کنن اونوقت چی؟
فرض کن قراره علی و مریم روی فیچر نوتیفیکیشن کار کنن:
اگر برنچ feature وجود نداشت در ابتدا یکی از اعضای تیم یا تیم لید از develop یک برنچ می سازد به اسم
feature/notification
از برنچ develop تمام تغییرات رو میگیره (pull می کنه)
هر کدوم یه زیر برنچ با توجه به کارایی که قراره انجام بدن میسازن مثلا علی قراره روی بک اند کار کنه و مریم هم قراره روی ظاهر اون فیچر کار کنه پس زیر برنچ ها میشن:
feature/notification/maryam-ui
feature/notification/ali-backend
هرکس کار خودشو انجام میده، commit و push میکنه.
وقتی تموم شد، یه PR میزنه به feature/notification.
بعد از اینکه همهی تغییرات اونجا جمع شد و تست شد، تیم لید اون رو merge میکنه به develop و در آخر هم تمام برنچ های فرعی پاک میشن (آخیش تمیز و مرتب میشه😃)
یادت باشه برنچ های فرعی رو بعد از merge شدن، هم از لوکال هم از ریموت پاکش کن که تمیز باقی بمونه نگران نباش تاریخچه همیشه تو git هست!
🧭 چرا این ساختار کمک میکنه؟
🧠 ذهنت رو آزاد میکنه چون هر کاری جای خودش رو داره
🚫 تداخل کاری بین اعضا بهوجود نمیاد.
🔍 گزارشگیری راحتتر میشه (تاریخچه شفافه).
🧼 Git تمیز و مرتب میمونه.
🔚 توصیه آخر
Git Flow قراره بهت نظم بده، نه اینکه دستوپات رو ببنده. با نیاز تیم میتونی شخصیسازیش کنی. فقط مهمه که همه تیم بدونن دقیقاً چی به چیه، تا توسعه، تمیز، سریع و بدون درگیری پیش بره.
