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

تعارف

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

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

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

• اس شاخ میں کام کریں جس میں وہ چاہتا ہے؛
• دوسری شاخوں میں ضم ہو جائیں جو وہ چاہتا ہے؛
• کچھ شاخیں حذف کریں؛
• نئے بنائیں؛
• اور اسی طرح — ٹیم کا ہر رکن ایک بے قابو بہاؤ میں ہے۔

لہذا، ذیل میں تین حکمت عملی ہیں. جاؤ!

گٹ ہب فلو حکمت عملی

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

1. ماسٹر برانچ میں موجود کوڈ کو غیر منقطع اور کسی بھی وقت تعینات کرنے کے لیے تیار ہونا چاہیے (یعنی، آپ وہاں کوڈ نہیں ڈال سکتے جو پروجیکٹ کو بنانے اور اسے سرور پر تعینات کرنے میں مداخلت کرے)۔
2. جب آپ نئی فعالیت پر کام کرنے کا ارادہ رکھتے ہیں، تو آپ کو ماسٹر برانچ کی بنیاد پر ایک نئی برانچ (فیچر برانچ) بنانے اور اسے ایک معنی خیز نام دینے کی ضرورت ہے۔ مقامی طور پر اپنے کوڈ کا ارتکاب کریں اور باقاعدگی سے اپنی تبدیلیوں کو دور دراز کے ذخیرے میں اسی برانچ میں دھکیلیں۔
3. Pull-Request کھولیں (آپ پڑھ سکتے ہیں کہ پل کی درخواست کیا ہے کام ہو گیا)۔
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 پر فورکنگ فلو استعمال کیا جاتا ہے جب کوئی لائبریری موجود ہو جسے آپ استعمال کرنا چاہتے ہیں۔ اس میں ایک خرابی ہے جو اسے مکمل طور پر استعمال ہونے سے روکتی ہے۔ ہم کہتے ہیں کہ آپ نے مسئلہ کا کافی حد تک جائزہ لیا ہے اور اس کا حل جانتے ہیں۔ فورکنگ ورک فلو حکمت عملی کا استعمال کرتے ہوئے، آپ اصل لائبریری کے ذخیرے میں کام کرنے کے حقوق دیے بغیر اس مسئلے کو حل کر سکتے ہیں۔ شروع کرنے کے لیے، آپ کو ایک ذخیرہ منتخب کرنے کی ضرورت ہے، مثال کے طور پر، اسپرنگ فریم ورک کور ۔ اوپری دائیں کونے میں فورک بٹن تلاش کریں اور اس پر کلک کریں: اس میں کچھ وقت لگے گا، جس کے بعد اس اصلی ذخیرے کی ایک کاپی آپ کے ذاتی اکاؤنٹ، جو اس بات کی نشاندہی کرے گا کہ یہ ایک کانٹا ہے: پھر آپ اس ریپوزٹری کے ساتھ معمول کے مطابق کام کر سکتے ہیں، ماسٹر برانچ میں تبدیلیاں شامل کر سکتے ہیں اور جب سب کچھ تیار ہو جائے تو اصل ریپوزٹری میں پل-ریکوسٹ بنائیں۔ ایسا کرنے کے لیے، نیو پل ریکوسٹ بٹن پر کلک کریں :

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

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

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

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

مفید لنکس

• GitHub فلو: Git اور GitHub استعمال کرنے کا بہترین طریقہ
• GitHub پر درخواستیں کھینچیں یا میں کسی اور کے پروجیکٹ میں تبدیلیاں کیسے کر سکتا ہوں۔
• گٹ ہب: پل کی درخواستوں کے بارے میں
• مسلسل انضمام، ترسیل، اور تعیناتی میں فرق
• گٹ کی بنیادی باتیں: ٹیگز کے ساتھ کام کرنا
• Habr: Git کے لیے کامیاب برانچنگ ماڈل