کار تیمی بدون سردرگمی: درک استراتژی های انشعاب در Git

معرفی

Git به استاندارد صنعت بالفعل برای سیستم های کنترل نسخه در توسعه نرم افزار تبدیل شده است. ابتدا باید مقاله من در مورد Git چیست و چگونه شروع کنید بخوانید. آیا آن را خوانده اید؟ عالی، بیایید شروع کنیم! دوست داشته باشید یا نخواهید، این ابزار ایجاد شده توسط لینوس تووالدز بازنشسته نمی شود. بنابراین، منطقی است که در مورد نحوه کار تیم های توزیع شده با Git و استراتژی انشعاب آنها برای این کار صحبت کنیم. این سوال بی اهمیتی نیست. هنگام جمع آوری یک تیم توسعه جدید که قبلاً با هم کار نکرده اند، استراتژی انشعاب اغلب یکی از اولین چیزهایی است که باید تصمیم گیری کرد. و برخی از مردم در دهان کف می کنند تا ثابت کنند که یک استراتژی بهتر از استراتژی دیگر است. بنابراین، من می خواهم اطلاعات کلی در مورد آنها را به شما منتقل کنم.

آیا استراتژی های انشعاب ضروری است؟

آنها واقعا ضروری هستند. بسیار ضروری. زیرا اگر تیم در مورد چیزی به توافق نرسد، هر یک از اعضای تیم آنچه را که می خواهد انجام می دهد:

• کار در هر شاخه ای
• ادغام در شاخه های دیگر دلخواه
• حذف برخی از شاخه ها
• ایجاد موارد جدید
• و بنابراین هر یک از اعضای تیم در یک جریان مدیریت نشده عمل خواهند کرد.

به همین دلیل است که در زیر سه استراتژی برای بررسی داریم. بیا بریم!

جریان GitHub

این استراتژی انشعاب، به اندازه کافی عجیب، در GitHub ترجیح داده می شود :) با مجموعه ای از قوانین همراه است :

1. کد موجود در شاخه اصلی نباید شکسته شود. باید در هر زمان آماده استقرار باشد. یعنی نباید کدی را در آنجا قرار دهید که مانع از ساخت پروژه و استقرار آن در سرور شود.
2. هنگامی که قصد دارید روی عملکرد جدید کار کنید، باید یک شاخه ویژگی جدید بر اساس شاخه اصلی ایجاد کنید و نامی معنادار به آن بدهید. کد خود را به صورت محلی متعهد کنید و به طور منظم تغییرات خود را به همان شعبه در مخزن راه دور فشار دهید.
3. زمانی که فکر می‌کنید کار آماده است و می‌توان آن را در شاخه اصلی ادغام کرد (یا اگر مطمئن نیستید، اما می‌خواهید درباره کار انجام شده بازخورد دریافت کنید)، یک درخواست کشش را باز کنید (در مورد درخواست‌های کشش اینجا بخوانید)
4. پس از تأیید ویژگی جدید در درخواست کشش، می توان آن را در شاخه اصلی ادغام کرد.
5. وقتی تغییرات در شاخه اصلی ادغام شدند، باید فوراً در سرور مستقر شوند.

طبق گفته GitHub Flow، قبل از شروع کار بر روی چیزی جدید، چه یک اصلاح یا یک ویژگی جدید، باید یک شاخه جدید بر اساس master ایجاد کنید و نام مناسبی برای آن بگذارید. بعد، کار بر روی پیاده سازی آغاز می شود. شما باید دائماً تعهدات را به سرور راه دور با همین نام ارسال کنید. وقتی به این نتیجه رسیدید که همه چیز آماده است، باید یک درخواست کشش به شاخه اصلی ایجاد کنید. سپس حداقل یک، یا بهتر است بگوییم، دو نفر باید قبل از کلیک بر روی "تأیید" به این کد نگاه کنند. معمولاً سرپرست تیم پروژه و نفر دوم باید حتماً نگاهی بیندازند. سپس می توانید درخواست کشش را تکمیل کنید. GitHub Flow همچنین برای هدایت تحویل مداوم (CD) در پروژه ها شناخته شده است. این به این دلیل است که وقتی تغییرات به شاخه اصلی می‌رود، باید فوراً در سرور مستقر شوند.

GitFlow

استراتژی قبلی (GitHub Flow) در هسته خود چندان پیچیده نیست. دو نوع شاخه وجود دارد: شاخه اصلی و شاخه. اما GitFlow جدی تر است. حداقل، تصویر بالا باید این را روشن کند :) پس این استراتژی چگونه کار می کند؟ به طور کلی GitFlow از دو شاخه دائمی و چندین نوع شاخه موقت تشکیل شده است. در زمینه GitHub Flow، شاخه اصلی پایدار است و بقیه موقتی هستند. شاخه های ماندگار

• استاد: هیچ کس نباید چیزی را لمس کند یا به این شاخه فشار دهد. در این استراتژی، master آخرین نسخه پایدار را نشان می دهد که در تولید (یعنی روی سرور واقعی) استفاده می شود.
• توسعه: شاخه توسعه. ممکن است ناپایدار باشد.

توسعه با استفاده از سه شاخه موقت کمکی انجام می شود :

1. شاخه های ویژگی - برای توسعه عملکردهای جدید.
2. شاخه‌های انتشار - برای آماده‌سازی برای انتشار نسخه جدید پروژه.
3. شاخه های رفع فوری - برای رفع سریع اشکالی که توسط کاربران واقعی در یک سرور واقعی پیدا شده است.

شاخه های ویژه

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

شاخه ها را آزاد کنید

هنگامی که مجموعه مورد نیاز از ویژگی های جدید در شاخه توسعه آماده شد، می توانید برای انتشار نسخه جدید محصول آماده شوید. یک شاخه انتشار که بر اساس شاخه توسعه ایجاد شده است به ما در این امر کمک می کند. هنگام کار با شاخه انتشار، باید همه باگ ها را پیدا کرده و برطرف کنید. هر تغییر جدیدی که برای تثبیت شاخه انتشار لازم است نیز باید در شاخه توسعه ادغام شود. این کار به منظور تثبیت شاخه توسعه نیز انجام می شود. وقتی آزمایش‌کننده‌ها می‌گویند که شاخه به اندازه کافی برای نسخه جدید پایدار است، در شاخه اصلی ادغام می‌شود. بعداً یک تگ که یک شماره نسخه به آن اختصاص داده می شود برای این commit ایجاد می شود. برای مشاهده یک مثال، به تصویر ابتدای استراتژی نگاه کنید. در آنجا برچسب 1.0 را خواهید دید - این فقط یک برچسب است که نسخه 1.0 پروژه را نشان می دهد. و در نهایت، ما شاخه Hotfix را داریم.

شاخه های رفع فوری

شاخه های Hotfix همچنین برای انتشار یک نسخه جدید به شاخه اصلی در نظر گرفته شده است. تنها تفاوت این است که آن نسخه ها برنامه ریزی نشده اند. شرایطی وجود دارد که اشکالات وارد نسخه منتشر شده می شوند و در محیط تولید کشف می شوند. iOS را انتخاب کنید: به محض انتشار نسخه جدید، بلافاصله یک سری به روز رسانی با رفع اشکالاتی که پس از انتشار پیدا شده اند دریافت می کنید. بر این اساس، باید به سرعت یک باگ را برطرف کرده و نسخه جدیدی را منتشر کنیم. در تصویر ما، این مربوط به نسخه 1.0.1 است. ایده این است که کار بر روی عملکردهای جدید زمانی که نیاز به رفع اشکال در یک سرور واقعی (یا همانطور که می گوییم، "در تولید" یا "در حال تولید") ضروری است، متوقف شود. شاخه Hotfix باید از شاخه اصلی ایجاد شود، زیرا نشان دهنده چیزی است که در حال حاضر در حال تولید است. به محض اینکه رفع اشکال آماده شد، در Master ادغام می شود و یک برچسب جدید ایجاد می شود. درست مانند آماده‌سازی یک شاخه انتشار، یک شاخه Hotfix نیز باید اصلاح خود را در شاخه توسعه ادغام کند.

انشعاب گردش کار

در گردش کار فورکینگ، توسعه شامل دو مخزن است:

1. مخزن اصلی که همه تغییرات در آن ادغام خواهند شد.
2. یک مخزن چنگال این یک کپی از مخزن اصلی است که متعلق به توسعه دهنده دیگری است که می خواهد تغییراتی در نسخه اصلی ایجاد کند.

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

نمونه ای از گردش کار فورکینگ

هنگامی که کتابخانه ای وجود دارد که می خواهید از آن استفاده کنید، گردش کار فورکینگ در GitHub اعمال می شود. دارای یک اشکال است که شما را از استفاده کامل از آن باز می دارد. فرض کنید به اندازه کافی در مشکل فرو رفته اید و راه حل را می دانید. با استفاده از گردش کار فورکینگ، می‌توانید مشکل را بدون حقوق کار در مخزن اصلی کتابخانه برطرف کنید. برای شروع، باید مقداری مخزن، به عنوان مثال، Spring Framework را انتخاب کنید . دکمه "Fork" را در گوشه سمت راست بالا پیدا کنید و روی آن کلیک کنید: این کار کمی طول می کشد. سپس یک کپی از مخزن اصلی در حساب شخصی شما ظاهر می شود که نشان می دهد یک فورک است: اکنون می توانید طبق معمول با این مخزن کار کنید و تغییرات را به شاخه اصلی اضافه کنید و وقتی همه چیز آماده شد، می توانید یک درخواست را به مخزن اصلی بکشید. برای انجام این کار، روی دکمه New pull request کلیک کنید :

کدام استراتژی را انتخاب کنید

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

1. بهتر است ابتدا ساده ترین استراتژی را انتخاب کنید. فقط در صورت نیاز به سمت استراتژی های پیچیده تر حرکت کنید.
2. استراتژی هایی را در نظر بگیرید که تا آنجا که ممکن است انواع شاخه های کمتری برای توسعه دهندگان دارند.
3. به مزایا و معایب استراتژی های مختلف نگاه کنید و سپس استراتژی مورد نیاز خود را برای پروژه خود انتخاب کنید.

این تمام چیزی است که می خواستم در مورد استراتژی های شاخه بندی در Git بگویم. از توجه شما متشکرم :) من را در GitHub دنبال کنید .