مونجهاري کان سواءِ ٽيم ڪم: گٽ ۾ برانچنگ حڪمت عملي کي سمجھڻ

تعارف

Git سافٽ ويئر ٺاهڻ ۾ ورزن ڪنٽرول لاءِ فيڪٽو انڊسٽري جو معيار بڻجي چڪو آهي. انهي بابت سکڻ لاءِ ته گيٽ ڇا آهي ۽ ڪيئن شروع ڪجي، پهرين پڙهو منهنجو مضمون ان بابت. ڇا توهان ان کي پڙهيو آهي؟ عظيم، اچو ته اڳتي وڌو! اهو پسند ڪريو يا نه، اهو اوزار جيڪو لينس ٽوالڊس ٺاهيو آهي اهو رٽائر ٿيڻ وارو ناهي. تنهن ڪري، اهو سمجهڻ جو مطلب آهي ته ڪيئن ورهايل ٽيمون گٽ ۾ ڪم ڪن ٿيون ۽ انهي لاء ڪهڙي برانچنگ حڪمت عملي چونڊيو وڃي. ۽ اهو سڀ ڪجهه بيڪار سوال ناهي. گهڻو ڪري، اهڙي صورتحال ۾ جتي ڊولپرز جي هڪ نئين ٽيم گڏ ڪئي وئي آهي جن هڪ ٻئي سان تعاون نه ڪيو آهي، برانچنگ حڪمت عملي پهرين شين مان هڪ آهي جنهن کي فيصلو ڪرڻ جي ضرورت آهي. ۽ اهڙا ماڻهو هوندا جيڪي وات تي فوم ڪندا ته ثابت ڪن ته هڪ حڪمت عملي ٻي کان بهتر آهي. تنهن ڪري، مان توهان کي معلومات پهچائڻ چاهيان ٿو ته اهي عام طور تي ڇا آهن.

ڇا برانچنگ حڪمت عمليون ضروري آهن؟

پر اهي گهربل آهن، ۽ اهي اڃا تائين گهربل آهن. ڇو ته جيڪڏهن توهان ٽيم ۾ ڪنهن شيءِ تي متفق نه آهيو، اهو ظاهر ٿئي ٿو ته هرڪو اهو ڪندو جيڪو هو چاهي ٿو:

• شاخ ۾ ڪم ڪريو جنهن ۾ هو چاهي ٿو؛
• ٻين شاخن ۾ ضم ٿي جيڪو هو چاهي ٿو؛
• ڪجھ شاخون ختم ڪريو؛
• نئون ٺاهيو؛
• وغيره - ٽيم جي ميمبرن مان هر هڪ غير ڪنٽرول وهڪري ۾ آهي.

تنهن ڪري، هيٺيون ٽي حڪمت عمليون آهن. وڃ!

GitHub فلو حڪمت عملي

برانچنگ حڪمت عملي، ڪابه ڳالهه اها ڪيتري به عجيب نه هجي، GitHub ۾ ترجيح ڏني وئي آهي :) ان سان ڳنڍيل قاعدن جو هڪ سيٽ آهي جنهن جي پيروي ڪرڻ جي ضرورت آهي:

1. ماسٽر برانچ ۾ ڪوڊ لازمي طور تي اڻڄاتل هجي ۽ ڪنهن به وقت تيار ٿيڻ لاء تيار هجي (يعني، توهان اتي ڪوڊ نه وجهي سگهو ٿا جيڪو منصوبي جي تعمير ۽ سرور تي ان کي ترتيب ڏيڻ ۾ مداخلت ڪندو).
2. جڏهن توهان نئين ڪارڪردگي تي ڪم ڪرڻ جو منصوبو ٺاهيو ٿا، توهان کي ماسٽر برانچ جي بنياد تي هڪ نئين شاخ (فيچر برانچ) ٺاهڻ جي ضرورت آهي ۽ ان کي هڪ معني وارو نالو ڏيو. پنھنجي ڪوڊ کي مقامي طور تي ڪم ڪريو ۽ باقاعده پنھنجي تبديلين کي ھڪڙي شاخ ۾ ھڪڙي ريموٽ مخزن ۾ وڌايو.
3. هڪ پل-درخواست کوليو (توهان پڙهي سگهو ٿا ته پل-درخواست ڇا آهي هتي ) جڏهن واضح محسوس ٿئي ته ڪم تيار آهي ۽ ماسٽر برانچ ۾ ضم ٿي سگهي ٿو (يا جيڪڏهن توهان کي پڪ ناهي، پر راء حاصل ڪرڻ چاهيو ٿا. ڪم ڪيو ويو).
4. پل جي درخواست ۾ نئين خصوصيت منظور ٿيڻ کان پوء، ان کي ماسٽر برانچ ۾ ملائي سگھجي ٿو.
5. جڏهن تبديليون ماسٽر برانچ ۾ ضم ٿي وڃن ٿيون، انهن کي فوري طور تي سرور تي ترتيب ڏيڻ جي ضرورت آهي.

GitHub Flow جي مطابق، اهو ظاهر ٿئي ٿو ته توهان ڪنهن نئين شيء تي ڪم ڪرڻ شروع ڪرڻ کان اڳ، اهو هڪ فيڪس يا نئين خاصيت آهي، توهان کي ماسٽر جي بنياد تي هڪ نئين برانچ ٺاهي ۽ ان کي هڪ مناسب نالو ڏيڻ جي ضرورت آهي. اڳيون، ڪم تي عملدرآمد تي شروع ٿئي ٿو. توهان کي ضرورت آهي ته مسلسل ڪمٽ کي هڪ ئي نالي سان ريموٽ سرور ڏانهن. جڏهن توهان سمجھو ٿا ته هر شي تيار آهي، توهان کي ماسٽر برانچ ۾ پل جي درخواست ٺاهڻ جي ضرورت آهي. پوء گهٽ ۾ گهٽ هڪ، يا اڃا بهتر، ٻه ماڻهو هن ڪوڊ کي ڏسڻ گهرجي ۽ ڪلڪ ڪريو منظور ڪريو. عام طور تي، منصوبي جي ٽيم جي اڳواڻي ۽ ڪنهن ٻئي کي ان کي ڏسڻ گهرجي، ۽ پوء توهان مڪمل ڪري سگهو ٿا پل جي درخواست. GitHub Flow هڪ منصوبي تي مسلسل پهچائڻ (CD) هلائڻ لاء پڻ مشهور آهي . ڇاڪاڻ ته جڏهن ماسٽر برانچ ۾ تبديليون ڪيون وينديون آهن، انهن کي فوري طور تي سرور ڏانهن پهچايو وڃي.

GitFlow حڪمت عملي

پوئين حڪمت عملي (GitHub فلو) بنيادي طور تي تمام پيچيده نه هئي. شاخن جا ٻه قسم آهن: ماسٽر ۽ فيچر شاخون. پر GitFlow وڌيڪ سنجيده آهي. گهٽ ۾ گهٽ مٿي ڏنل تصوير مان توهان هن کي سمجهي سگهو ٿا) پوء، هي حڪمت عملي ڪيئن ڪم ڪري ٿي؟ عام طور تي، GitFlow ٻن مستقل شاخن ۽ ڪيترن ئي قسمن جي عارضي شاخن تي مشتمل آھي (GitHub فلو جي حوالي سان، ماسٽر برانچ مستقل آھي ۽ ٻيا عارضي آھن). مستقل شاخون:

• ماسٽر: هن شاخ کي ڪنهن کي به هٿ نه ڏيڻو پوندو / اتي ڪنهن به شيء کي ڌڪايو. هن حڪمت عملي ۾، ماسٽر ڏيکاري ٿو جديد مستحڪم نسخو جيڪو پيداوار ۾ استعمال ٿئي ٿو (جيڪو حقيقي سرور تي آهي)؛
• ترقي ترقي جي شاخ آهي. اهو ممڪن طور تي غير مستحڪم ٿي سگهي ٿو.

ترقي ٽن معاون عارضي شاخن کي استعمال ڪندي ڪيو ويندو آهي :

1. خصوصيت شاخون - نئين ڪارڪردگي کي ترقي ڪرڻ لاء.
2. رليز شاخون - منصوبي جي نئين نسخي جي ڇڏڻ لاء تيار ڪرڻ لاء.
3. Hotfix برانچ هڪ خرابي جو تڪڙو حل آهي جيڪو اڳ ۾ ئي حقيقي صارفين طرفان حقيقي سرور تي مليو هو.

خصوصيت شاخون

خصوصيت شاخون ڊولپرز پاران نئين ڪارڪردگي لاء ٺاهيا ويا آهن. انهن کي هميشه ترقي جي شاخ جي بنياد تي ٺاهيو وڃي. نئين ڪارڪردگي تي ڪم مڪمل ڪرڻ کان پوء، توهان کي ترقي جي شاخ ۾ پل درخواست ٺاهڻ جي ضرورت آهي. اهو واضح آهي ته وڏي ٽيمن ۾ هڪ وقت ۾ هڪ کان وڌيڪ فيچر برانچ ٿي سگهي ٿي. هڪ ڀيرو ٻيهر، GitFlow حڪمت عملي جي وضاحت جي شروعات ۾ تصوير تي ڌيان ڏيو.

شاخون ڇڏڻ

جڏهن ڊولپمينٽ برانچ ۾ نون فيچرز جو گهربل تعداد تيار ڪيو ويو آهي، توهان تيار ڪري سگهو ٿا پراڊڪٽ جو نئون ورزن جاري ڪرڻ لاءِ. رليز برانچ هن سان اسان جي مدد ڪندي. جيڪا ترقي جي شاخ جي بنياد تي ٺاهي وئي آهي. رليز برانچ سان ڪم ڪرڻ دوران، توهان کي سڀني خرابين کي ڳولڻ ۽ درست ڪرڻ جي ضرورت آهي. ريليز برانچ کي مستحڪم ڪرڻ لاء ڪا به نئين تبديليون گهربل آهن پڻ ترقي ۾ واپس ملن ٿيون. اهو شاخ کي مستحڪم ۽ ترقي ڪرڻ لاء ڪيو ويو آهي. جڏهن جاچ ڪندڙ چون ٿا ته برانچ نئين رليز لاءِ ڪافي مستحڪم آهي، ان کي ماسٽر برانچ ۾ ضم ڪيو ويو آهي. اڳيون، هڪ ٽيگ هن ڪمٽ تي ٺاهي وئي آهي (ٽيگ: توهان ان بابت وڌيڪ پڙهي سگهو ٿا هتي )، جيڪو هڪ نسخو نمبر مقرر ڪيو ويو آهي. مثال طور، توهان حڪمت عملي جي شروعات ۾ تصوير کي ڏسي سگهو ٿا. تنهن ڪري، اتي ٽيگ 1.0 صرف هڪ ليبل آهي جيڪو اشارو ڪري ٿو نسخو 1.0 پروجيڪٽ جو. ۽ آخري شيء هڪ برانچ hotfix آهي.

Hotfix شاخون

Hotfix برانچ پڻ ماسٽر ۾ نئين ورزن جي ڇڏڻ جو ارادو ڪيو ويو آهي. فرق صرف اهو آهي ته هي رليز منصوبابندي نه ڪئي وئي آهي. حالتون آهن جڏهن خرابيون ڇڏڻ تائين پهچي وڃن ٿيون ۽ اڳ ۾ ئي پيداوار ۾ دريافت ڪيا ويا آهن. مثال طور، iOS: جيئن ئي اهي هڪ نئون ورزن جاري ڪن ٿا، توهان فوري طور تي تازه ڪارين جو هڪ گروپ حاصل ڪريو جيڪي رليز ٿيڻ کان پوء دريافت ڪيا ويا آهن. ان سلسلي ۾، ان کي فوري طور تي هن عيب کي درست ڪرڻ ۽ هڪ نئون نسخو ڇڏڻ ضروري آهي. اسان جي تصوير ۾ هي نسخو 1.0.1 سان ملندو آهي. خيال اهو آهي ته نئين ڪارڪردگي تي ڪم ان وقت بند نه ٿي سگھي جڏهن حقيقي سرور تي خرابي کي درست ڪرڻ ضروري آهي (جيئن اسان چئون ٿا، "پيداوار ۾": ٻيهر انگريزي لفظ پيداوار جي ڪاپي). هاٽ فڪس شاخ کي ماسٽر برانچ مان ٺاهيو وڃي، ڇو ته اها رياست جي نمائندگي ڪري ٿي جيڪا پيداوار ۾ ڪم ڪري ٿي. جيئن ئي عيب جو حل تيار آهي، اهو ماسٽر ۾ ضم ڪيو ويو آهي، ۽ هڪ نئون ليبل ٺاهيو ويندو آهي. بس رليز برانچ تيار ڪرڻ وانگر، هڪ هاٽ فڪس برانچ کي ان جي حل کي ڊولپمينٽ برانچ ۾ ملائڻ گهرجي.

فورڪنگ ورڪ فلو حڪمت عملي

فورڪنگ ورڪ فلو حڪمت عملي جي حصي جي طور تي، ترقي اهڙي طرح ڪئي وئي آهي ته اتي ٻه ذخيرا آهن:

1. اصل مخزن جنهن ۾ سڀ تبديليون ملائي وينديون.
2. هڪ فورڪ مخزن (هي اصل مخزن جي هڪ ڪاپي آهي ڪنهن ٻئي ڊولپر جي قبضي ۾ جيڪو اصل ۾ تبديليون ڪرڻ چاهي ٿو).

آواز ٿورڙو عجيب ايترو پري، صحيح؟ انهن لاءِ جيڪي اڳ ۾ ئي اوپن سورس ڊولپمينٽ کي منهن ڏئي چڪا آهن ، اهو طريقو اڳ ۾ ئي واقف آهي. هي حڪمت عملي هيٺ ڏنل فائدي فراهم ڪري ٿي: ترقي هڪ فورڪ ريپوزٽري ۾ ٿي سگهي ٿو بغير ڪنهن کي اصل ۾ گڏيل ترقي جا حق ڏيڻ جي. يقينا، اصل مخزن جي مالڪ کي تجويز ڪيل تبديلين کي رد ڪرڻ جو حق آهي. يا اتفاق ڪيو ۽ انهن کي ماريو. اهو ٻنهي لاءِ آسان آهي اصل مخزن جي مالڪ ۽ ڊولپر جيڪو ڪجهه پراڊڪٽ ٺاهڻ ۾ حصو وٺڻ چاهي ٿو. مثال طور، توھان تجويز ڪري سگھوٿا لينڪس ڪنيل ۾ تبديليون . جيڪڏهن لينس فيصلو ڪري ٿو ته اهي سمجهن ٿا، تبديليون شامل ڪيون وينديون (!!!).

فورڪنگ ورڪ فلو مثال

فورڪنگ فلو استعمال ڪيو ويندو آهي GitHub تي جڏهن ڪجهه لائبريري آهي جيڪا توهان استعمال ڪرڻ چاهيو ٿا. اهو هڪ نقص آهي جيڪو ان کي مڪمل طور تي استعمال ٿيڻ کان روڪي ٿو. اچو ته چئو ته توهان مسئلي ۾ ڪافي ڊيل ڪيو آهي ۽ حل ڄاڻو ٿا. Forking Workflow حڪمت عملي استعمال ڪندي، توھان ھي مسئلو حل ڪري سگھو ٿا بغير ڪم ڪرڻ جا حق ڏيڻ جي اصل لائبريري مخزن ۾. شروع ڪرڻ لاءِ، توهان کي هڪ مخزن چونڊڻ جي ضرورت آهي، مثال طور، اسپرنگ فريم ورڪ ڪور . مٿي ساڄي ڪنڊ ۾ فورڪ بٽڻ ڳولهيو ۽ ان تي ڪلڪ ڪريو: اهو ڪجهه وقت وٺندو، جنهن کان پوءِ هن اصل مخزن جي ڪاپي ظاهر ٿيندي. ذاتي اڪائونٽ، جيڪو ظاهر ڪندو ته اهو هڪ ڪانٽو آهي: پوء توهان هن مخزن سان معمول وانگر ڪم ڪري سگهو ٿا، ماسٽر برانچ ۾ تبديليون شامل ڪريو ۽ جڏهن سڀ ڪجهه تيار آهي، اصل مخزن ڏانهن پل-درخواست ٺاهيو. هن کي ڪرڻ لاء، ڪلڪ ڪريو نئون پل درخواست بٽڻ :

ڪهڙي حڪمت عملي چونڊڻ لاءِ

Git هڪ لچڪدار ۽ طاقتور اوزار آهي جيڪو توهان کي ڪم ڪرڻ جي اجازت ڏئي ٿو وسيع رينج ۽ حڪمت عمليون استعمال ڪندي. پر جيتري وڏي چونڊ، اوترو وڌيڪ ڏکيو اهو فيصلو ڪرڻ آهي ته ڪهڙي حڪمت عملي هاڻي چونڊيو وڃي. واضح طور تي، ڪو به هڪ-سائيز-فٽ-سڀ جواب نه آهي. اهو سڀ ڪجهه صورتحال تي منحصر آهي. بهرحال، ڪجھه سفارشون آھن جيڪي ھن سان مدد ڪري سگھن ٿيون:

1. اهو بهتر آهي ته پهرين آسان حڪمت عملي چونڊيو. وڌيڪ پيچيده حڪمت عملين ڏانهن وڃو صرف جڏهن ضروري هجي.
2. حڪمت عملين تي غور ڪريو جيڪي ممڪن طور تي ڊولپر شاخن جا ڪجھ قسم آھن.
3. مختلف حڪمت عملين جا فائدا ۽ نقصان ڏسو ۽، منصوبي جي مطابق، صحيح چونڊيو.

اهو سڀ ڪجهه آهي جيڪو مان توهان کي گٽ ۾ برانچنگ حڪمت عملي بابت ٻڌائڻ چاهيان ٿو. توهان جي توجه ڏيڻ جي مهرباني :) منهنجي GitHub اڪائونٽ ۾ رڪنيت حاصل ڪريو ، آئون اڪثر ڪري پنهنجو ڪم اتي مختلف ٽيڪنالاجيز ۽ اوزارن ۾ پوسٽ ڪندو آهيان جيڪي آئون پنهنجي ڪم ۾ استعمال ڪيان ٿو

مفيد لنڪس

• GitHub وهڪري: Git ۽ GitHub استعمال ڪرڻ جو بهترين طريقو
• GitHub تي درخواستون ڪڍو يا آئون ڪنهن ٻئي جي منصوبي ۾ تبديلي ڪيئن ڪري سگهان ٿو
• GitHub: پل جي درخواستن بابت
• مسلسل انضمام، پهچائڻ، ۽ ترتيب ڏيڻ ۾ فرق
• گٽ بنياديات: ٽيگ سان ڪم ڪرڻ
• Habr: Git لاء ڪامياب برانچنگ ماڊل