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

معرفی

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

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

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

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

بنابراین، در زیر سه استراتژی آورده شده است. برو!

استراتژی GitHub Flow

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

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

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

استراتژی GitFlow

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

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

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

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

شاخه های ویژه

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

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

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

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

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

استراتژی گردش کار فورکینگ

به عنوان بخشی از استراتژی Forking Workflow، توسعه به گونه ای انجام می شود که دو مخزن وجود دارد:

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

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

مثال گردش کار Forking

Forking Flow در GitHub زمانی استفاده می شود که کتابخانه ای وجود دارد که می خواهید از آن استفاده کنید. ایرادی دارد که از استفاده کامل آن جلوگیری می کند. بیایید بگوییم که شما به اندازه کافی به مشکل پرداخته اید و راه حل را می دانید. با استفاده از استراتژی Forking Workflow، می توانید این مشکل را بدون اعطای حقوق کار در مخزن اصلی کتابخانه حل کنید. برای شروع، باید یک مخزن، به عنوان مثال، هسته Spring Framework را انتخاب کنید . دکمه Fork را در گوشه سمت راست بالا پیدا کنید و روی آن کلیک کنید: این کار مدتی طول می کشد و پس از آن یک کپی از این مخزن اصلی در شما ظاهر می شود. حساب شخصی که نشان می دهد فورک است: سپس می توانید طبق معمول با این مخزن کار کنید، تغییرات را به شاخه اصلی اضافه کنید و وقتی همه چیز آماده شد، یک Pull-Request به مخزن اصلی ایجاد کنید. برای انجام این کار، روی دکمه درخواست کشش جدید کلیک کنید :

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

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

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

این تمام چیزی است که می خواستم در مورد استراتژی انشعاب در git به شما بگویم. از توجه شما متشکرم :) در حساب GitHub من مشترک شوید ، من اغلب کارهایم را در فناوری ها و ابزارهای مختلفی که در کارم استفاده می کنم در آنجا پست می کنم

لینک های مفید

• جریان GitHub: بهترین راه برای استفاده از Git و GitHub
• درخواست ها را در GitHub یا چگونه می توانم تغییراتی در پروژه شخص دیگری ایجاد کنم
• GitHub: درباره Pull-Requests
• ادغام مداوم، تحویل، و استقرار متفاوت
• مبانی Git: کار با برچسب ها
• Habr: مدل انشعاب موفق برای Git