الجھن کے بغیر ٹیم ورک: گٹ میں برانچنگ کی حکمت عملیوں کو سمجھنا

تعارف

Git سافٹ ویئر ڈویلپمنٹ میں ورژن کنٹرول سسٹم کے لیے ڈی فیکٹو انڈسٹری کا معیار بن گیا ہے۔ آپ کو پہلے میرا مضمون پڑھنا چاہیے کہ گٹ کیا ہے اور کیسے شروع کیا جائے۔ کیا آپ نے اسے پڑھا ہے؟ بہت اچھا، آئیے چلتے ہیں! اسے پسند کریں یا نہ کریں، Linus Tovalds کے ذریعہ تیار کردہ یہ ٹول ریٹائر نہیں ہونے والا ہے۔ لہذا، یہ بات سمجھ میں آتی ہے کہ تقسیم شدہ ٹیمیں Git کے ساتھ کس طرح کام کرتی ہیں اور اس کے لیے انہیں کون سی برانچنگ حکمت عملی کا انتخاب کرنا چاہیے۔ یہ کوئی غیر ضروری سوال نہیں ہے۔ ایک نئی ترقیاتی ٹیم کو جمع کرتے وقت جس نے پہلے ایک ساتھ کام نہیں کیا ہے، شاخ سازی کی حکمت عملی اکثر فیصلہ کرنے والی پہلی چیزوں میں سے ایک ہوتی ہے۔ اور کچھ لوگ یہ ثابت کرنے کے لیے منہ سے جھاگ اڑا رہے ہوں گے کہ ایک حکمت عملی دوسری سے بہتر ہے۔ لہذا، میں آپ کو ان کے بارے میں کچھ عمومی معلومات پہنچانا چاہتا ہوں۔

کیا برانچنگ کی حکمت عملی ضروری ہے؟

وہ واقعی ضروری ہیں۔ بہت ضروری۔ کیونکہ اگر ٹیم کسی چیز پر متفق نہیں ہے، تو ٹیم کا ہر رکن وہی کرے گا جو وہ چاہے گا:

• کسی بھی برانچ میں کام کرنا
• من مانی دیگر شاخوں میں ضم
• کچھ شاخوں کو حذف کرنا
• نئے بنانا
• اور اس طرح ٹیم کا ہر رکن غیر منظم بہاؤ میں کام کرے گا۔

اسی لیے ہمارے پاس ذیل میں غور کرنے کے لیے تین حکمت عملی ہیں۔ چلو!

گٹ ہب فلو

یہ برانچنگ حکمت عملی، عجیب طور پر، GitHub پر ترجیح دی جاتی ہے :) یہ قواعد کے ایک سیٹ کے ساتھ آتی ہے :

1. ماسٹر برانچ میں کوڈ کو توڑا نہیں جانا چاہئے۔ اسے کسی بھی وقت تعینات کرنے کے لیے تیار رہنا چاہیے۔ یعنی، آپ کو وہاں کوڈ نہیں لگانا چاہیے جو آپ کو پروجیکٹ بنانے اور اسے سرور پر تعینات کرنے سے روکے۔
2. جب آپ نئی فعالیت پر کام کرنے کا ارادہ کرتے ہیں، تو آپ کو ماسٹر برانچ کی بنیاد پر ایک نئی فیچر برانچ بنانے اور اسے ایک معنی خیز نام دینے کی ضرورت ہوتی ہے۔ مقامی طور پر اپنے کوڈ کا ارتکاب کریں اور ریموٹ ریپوزٹری میں اپنی تبدیلیوں کو اسی برانچ میں باقاعدگی سے دھکیلیں۔
3. جب آپ کو لگتا ہے کہ کام تیار ہے اور اسے ماسٹر برانچ میں ضم کیا جا سکتا ہے (یا اگر آپ کو یقین نہیں ہے، لیکن کام کیے جانے کے بارے میں رائے حاصل کرنا چاہتے ہیں) تو پل کی درخواست کھولیں (آپ یہاں پل کی درخواستوں کے بارے میں پڑھ سکتے ہیں ) ۔
4. پل کی درخواست میں نئے فیچر کی منظوری کے بعد، اسے ماسٹر برانچ میں ضم کیا جا سکتا ہے۔
5. جب تبدیلیاں ماسٹر برانچ میں ضم ہوجاتی ہیں، تو انہیں فوری طور پر سرور پر تعینات کیا جانا چاہیے۔

GitHub Flow کے مطابق، اس سے پہلے کہ آپ کسی نئی چیز پر کام شروع کریں، چاہے وہ فکس ہو یا کوئی نیا فیچر، آپ کو ماسٹر کی بنیاد پر ایک نئی برانچ بنانے اور اسے ایک مناسب نام دینے کی ضرورت ہے۔ اگلا، عملدرآمد پر کام شروع ہوتا ہے. آپ کو مسلسل اسی نام کے ساتھ ریموٹ سرور پر کمٹ جمع کروانا چاہیے۔ جب آپ یہ نتیجہ اخذ کرتے ہیں کہ سب کچھ تیار ہے، تو آپ کو ماسٹر برانچ میں پل کی درخواست بنانے کی ضرورت ہے۔ پھر کم از کم ایک، یا اس سے بہتر، دو لوگوں کو "منظور کریں" پر کلک کرنے سے پہلے اس کوڈ کو دیکھنا چاہیے۔ عام طور پر، پروجیکٹ کی ٹیم لیڈ اور ایک دوسرے شخص کو ضرور ایک نظر ڈالنی چاہیے۔ پھر آپ پل کی درخواست مکمل کر سکتے ہیں۔ GitHub Flow منصوبوں میں مسلسل ترسیل (CD) چلانے کے لیے بھی جانا جاتا ہے۔ اس کی وجہ یہ ہے کہ جب تبدیلیاں ماسٹر برانچ میں جاتی ہیں، تو انہیں فوری طور پر سرور پر تعینات کیا جانا چاہیے۔

گٹ فلو

پچھلی حکمت عملی (گٹ ہب فلو) اپنے بنیادی طور پر زیادہ پیچیدہ نہیں ہے۔ شاخوں کی دو قسمیں ہیں: ماسٹر اور فیچر برانچز۔ لیکن گٹ فلو زیادہ سنجیدہ ہے۔ کم از کم، اوپر کی تصویر کو یہ واضح کرنا چاہئے :) تو یہ حکمت عملی کیسے کام کرتی ہے؟ عام طور پر، GitFlow دو مستقل شاخوں اور کئی قسم کی عارضی شاخوں پر مشتمل ہوتا ہے۔ GitHub Flow کے تناظر میں، ماسٹر برانچ مستقل ہے اور باقی عارضی ہیں۔ مستقل شاخیں۔

• ماسٹر: اس شاخ کو کسی کو چھونا یا دھکیلنا نہیں چاہیے۔ اس حکمت عملی میں، ماسٹر تازہ ترین مستحکم ورژن کی نمائندگی کرتا ہے، جو پیداوار میں استعمال ہوتا ہے (یعنی حقیقی سرور پر)
• ترقی: ترقی کی شاخ۔ یہ غیر مستحکم ہو سکتا ہے۔

ترقی تین معاون عارضی شاخوں کا استعمال کرتے ہوئے ہوتی ہے :

1. خصوصیت کی شاخیں — نئی فعالیت کو فروغ دینے کے لیے۔
2. پراجیکٹ کے نئے ورژن کی ریلیز کی تیاری کے لیے — ریلیز برانچز۔
3. ہاٹ فکس برانچز — حقیقی سرور پر حقیقی صارفین کے ذریعے پائے جانے والے بگ کو فوری طور پر ٹھیک کرنے کے لیے۔

نمایاں شاخیں۔

فیچر برانچز ڈیولپرز کے ذریعے نئی فعالیت کے لیے بنائی جاتی ہیں۔ انہیں ہمیشہ ترقی کی شاخ کی بنیاد پر بنایا جانا چاہئے۔ نئی فعالیت پر کام مکمل کرنے کے بعد، آپ کو ڈویلپمنٹ برانچ میں پل کی درخواست بنانے کی ضرورت ہے۔ واضح طور پر، بڑی ٹیمیں ایک وقت میں ایک سے زیادہ فیچر برانچ رکھ سکتی ہیں۔ GitFlow حکمت عملی کی تفصیل کے آغاز میں تصویر پر ایک اور نظر ڈالیں۔

شاخیں جاری کریں۔

جب ڈیولپمنٹ برانچ میں نئی ​​خصوصیات کا مطلوبہ سیٹ تیار ہو جائے تو آپ پروڈکٹ کے نئے ورژن کی ریلیز کی تیاری کر سکتے ہیں۔ ایک ریلیز برانچ، جو ڈیولپمنٹ برانچ کی بنیاد پر بنائی گئی ہے، اس میں ہماری مدد کرے گی۔ ریلیز برانچ کے ساتھ کام کرتے وقت، آپ کو تمام کیڑے تلاش کرنے اور ٹھیک کرنے کی ضرورت ہے۔ کوئی بھی نئی تبدیلیاں جو ریلیز برانچ کو مستحکم کرنے کے لیے درکار ہیں انہیں بھی ڈیولپمنٹ برانچ میں دوبارہ ضم کیا جانا چاہیے۔ یہ ترقی کی شاخ کو بھی مستحکم کرنے کے لیے کیا جاتا ہے۔ جب ٹیسٹرز کہتے ہیں کہ برانچ نئی ریلیز کے لیے کافی مستحکم ہے، تو اسے ماسٹر برانچ میں ضم کر دیا جاتا ہے۔ بعد میں ایک ٹیگ، جسے ایک ورژن نمبر تفویض کیا جاتا ہے، اس کمٹ کے لیے بنایا جاتا ہے۔ مثال دیکھنے کے لیے حکمت عملی کے آغاز میں تصویر کو دیکھیں۔ وہاں آپ کو ٹیگ 1.0 نظر آئے گا — یہ صرف ایک ٹیگ ہے جو پروجیکٹ کے ورژن 1.0 کی نشاندہی کرتا ہے۔ اور آخر کار، ہمارے پاس ہاٹ فکس برانچ ہے۔

ہاٹ فکس شاخیں۔

ہاٹ فکس برانچز کا مقصد ماسٹر برانچ کو نیا ورژن جاری کرنا بھی ہے۔ فرق صرف اتنا ہے کہ ان ریلیز کی منصوبہ بندی نہیں کی گئی ہے۔ ایسے حالات ہوتے ہیں جب کیڑے جاری کردہ ورژن میں آتے ہیں اور پیداواری ماحول میں دریافت ہوتے ہیں۔ iOS کو ہی لیں: جیسے ہی کوئی نیا ورژن ریلیز ہوتا ہے، آپ کو فوری طور پر ان کیڑوں کے لیے اصلاحات کے ساتھ اپ ڈیٹس کا ایک گروپ ملتا ہے جو ریلیز کے بعد پائے گئے تھے۔ اس کے مطابق، ہمیں فوری طور پر ایک بگ کو ٹھیک کرنے اور ایک نیا ورژن جاری کرنے کی ضرورت ہے۔ ہماری تصویر میں، یہ ورژن 1.0.1 کے مساوی ہے۔ خیال یہ ہے کہ نئی فعالیت پر کام کو اس وقت رکنے کی ضرورت نہیں ہے جب کسی حقیقی سرور پر بگ کو ٹھیک کرنا ضروری ہو (یا جیسا کہ ہم کہتے ہیں، "پروڈکشن میں" یا "پروڈکشن میں")۔ ہاٹ فکس برانچ کو ماسٹر برانچ سے بنایا جانا چاہئے، کیونکہ یہ اس کی نمائندگی کرتا ہے جو فی الحال پروڈکشن میں چل رہا ہے۔ جیسے ہی بگ فکس تیار ہوتا ہے، اسے ماسٹر میں ضم کر دیا جاتا ہے، اور ایک نیا ٹیگ بنایا جاتا ہے۔ ریلیز برانچ کو تیار کرنے کی طرح، ہاٹ فکس برانچ کو بھی اپنی فکس کو دوبارہ ڈیولپمنٹ برانچ میں ضم کرنا چاہیے۔

فورکنگ ورک فلو

فورکنگ ورک فلو میں، ترقی میں دو ذخیرے شامل ہوتے ہیں:

1. اصل ذخیرہ، جس میں تمام تبدیلیاں ضم ہو جائیں گی۔
2. کانٹے کا ذخیرہ۔ یہ اصل ذخیرے کی ایک نقل ہے، جو کسی دوسرے ڈویلپر کی ملکیت ہے جو اصل میں تبدیلیاں کرنا چاہتا ہے۔

ابھی تک تھوڑا سا عجیب لگتا ہے، ٹھیک ہے؟ کوئی بھی جو پہلے ہی اوپن سورس کی ترقی کا سامنا کر چکا ہے وہ پہلے ہی اس نقطہ نظر سے واقف ہے۔ یہ حکمت عملی درج ذیل فائدہ دیتی ہے: ترقی کانٹے کے ذخیرے میں اصل برانچ میں مشترکہ ترقی کے لیے اجازت دیے بغیر ہو سکتی ہے۔ قدرتی طور پر، اصل ذخیرہ کے مالک کو مجوزہ تبدیلیوں کو مسترد کرنے کا حق حاصل ہے۔ یا ان کو قبول کر کے ضم کرنا۔ یہ اصل ریپوزٹری کے مالک اور ڈویلپر دونوں کے لیے آسان ہے جو پروڈکٹ بنانے میں مدد کرنا چاہتے ہیں۔ مثال کے طور پر، آپ لینکس کرنل میں تبدیلیاں تجویز کر سکتے ہیں ۔ اگر Linus فیصلہ کرتا ہے کہ وہ سمجھدار ہیں، تبدیلیاں شامل کی جائیں گی (!!!)۔

فورکنگ ورک فلو کی ایک مثال

فورکنگ ورک فلو GitHub پر لاگو ہوتا ہے جب کوئی لائبریری موجود ہو جسے آپ استعمال کرنا چاہتے ہیں۔ اس میں ایک بگ ہے جو آپ کو اسے مکمل طور پر استعمال کرنے سے روکتا ہے۔ فرض کریں کہ آپ مسئلے میں کافی گہرائی میں ڈوبتے ہیں اور اس کا حل جانتے ہیں۔ فورکنگ ورک فلو کا استعمال کرتے ہوئے، آپ لائبریری کے اصل ذخیرے میں کام کرنے کے حقوق کے بغیر مسئلہ حل کر سکتے ہیں۔ شروع کرنے کے لیے، آپ کو کچھ ذخیرہ منتخب کرنے کی ضرورت ہے، مثال کے طور پر، Spring Framework ۔ اوپری دائیں کونے میں "فورک" بٹن تلاش کریں اور کلک کریں: اس میں کچھ وقت لگے گا۔ پھر آپ کے ذاتی اکاؤنٹ میں اصل ذخیرے کی ایک کاپی نمودار ہوگی، جو اس بات کی نشاندہی کرے گی کہ یہ ایک کانٹا ہے: اب آپ اس ذخیرے کے ساتھ معمول کے مطابق کام کر سکتے ہیں، ماسٹر برانچ میں تبدیلیاں شامل کر سکتے ہیں، اور جب سب کچھ تیار ہو جائے گا، آپ ایک تخلیق کر سکتے ہیں۔ اصل ذخیرے کی درخواست کو کھینچیں۔ ایسا کرنے کے لیے، نئے پل کی درخواست کے بٹن پر کلک کریں:

کون سی حکمت عملی کا انتخاب کرنا ہے۔

Git ایک لچکدار اور طاقتور ٹول ہے جو آپ کو مختلف قسم کے عمل اور حکمت عملیوں کا استعمال کرتے ہوئے کام کرنے دیتا ہے۔ لیکن آپ کے پاس جتنے زیادہ انتخاب ہوں گے، یہ فیصلہ کرنا اتنا ہی مشکل ہوگا کہ کون سی حکمت عملی کا انتخاب کرنا ہے۔ یہ واضح ہے کہ ہر ایک کے لئے کوئی ایک جواب نہیں ہے۔ سب کچھ صورتحال پر منحصر ہے۔ اس نے کہا، کئی رہنما خطوط ہیں جو اس میں مدد کر سکتے ہیں:

1. سب سے پہلے آسان ترین حکمت عملی کا انتخاب کرنا بہتر ہے۔ زیادہ پیچیدہ حکمت عملیوں کی طرف صرف ضرورت پڑنے پر ہی جائیں۔
2. ان حکمت عملیوں پر غور کریں جن میں ڈویلپرز کے لیے ممکنہ حد تک کم شاخ کی اقسام ہیں۔
3. مختلف حکمت عملیوں کے فوائد اور نقصانات کو دیکھیں، اور پھر اپنے پروجیکٹ کے لیے جس کی ضرورت ہے اسے منتخب کریں۔

میں گٹ میں برانچنگ کی حکمت عملیوں کے بارے میں بس اتنا ہی کہنا چاہتا تھا۔ آپ کی توجہ کا شکریہ :) مجھے GitHub پر فالو کریں ، جہاں میں اکثر اپنی تخلیقات پوسٹ کرتا ہوں جن میں مختلف ٹیکنالوجیز اور ٹولز شامل ہوتے ہیں جو میں اپنے کام میں استعمال کرتا ہوں۔