یکی از چیزهایی که با دیدن حیاط خانه آینده خود عاشقش شدیم درخت بود. بلوط دره بزرگترین بلوط آمریکای شمالی است. می تواند تا 600 سال عمر و 100 فوت قد رشد کند. به خاطر شاخه های نامنظم و پراکنده اش معروف است.

صحبت از شاخه ها شد…یکی از ویژگی های کلیدی Git انشعاب است. به تنه درخت به عنوان پروژه اصلی خود فکر کنید. ما شاخه هایی ایجاد می کنیم تا کار خود را برای هر کار جدا کنیم. این به ما کمک می کند تا زمانی که آماده ادغام مجدد آن نباشیم، یک قسمت از پروژه را بدون تأثیر مستقیم روی پروژه اصلی جدا کرده و کار کنیم.

بیایید مفاهیم را بررسی کنیم و نحوه کار با شاخه Git را بیاموزیم. چه از خط فرمان یا ابزاری مانند دسکتاپ GitHub یا یکپارچه سازی Git VS Code استفاده کنید، می توانید این دانش را به کار ببرید.

یک آموزش جداگانه از طریق دستورات کار با شاخه ها می گذرد. همچنین می توانید ویدیوی مرتبط را در اینجا مشاهده کنید که شامل نمایش هایی با استفاده از کد VS است.

چرا از انشعاب استفاده کنیم؟

به‌طور پیش‌فرض، زمانی که مخزن Git را مقداردهی اولیه می‌کنیم، Git یک شاخه را ایجاد می‌کند که اغلب به آن «main» می‌گویند، اگرچه ممکن است آن را با نام‌های دیگری ببینید. ما در سراسر این مقاله به شاخه اولیه به عنوان “اصلی” اشاره خواهیم کرد.

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

مثلاً، ما انتظار داریم که یک هفته روی ویژگی «افزودن بازخورد» کار کنیم که به کاربران اجازه می‌دهد درباره یک دستور غذا نظر بدهند. همانطور که کار می کنیم، ویرایش های خود را به شاخه “افزودن بازخورد” متعهد می کنیم.

شخص دیگری در تیم در حال به روز رسانی اعلامیه حق چاپ در تمام صفحات سایت ما است. آن‌ها ویرایش‌های خود را به شاخه «افزودن حق چاپ» انجام می‌دهند.

ناگهان، اعلانی از کاربرانمان دریافت می کنیم که ورود به سیستم کار نمی کند. ما یک شعبه جدید ایجاد می کنیم تا آن مشکل را بدون تأثیرگذاری بر کار نیمه کامل برطرف کنیم.

هنگامی که کد شاخه “مشکل ورود” کامل شد، شعبه را دوباره به شاخه اصلی ادغام می کنیم. و به صورت اختیاری، می توانیم شاخه ادغام شده را حذف کنیم.

درخت بلوط بزرگ با "اصلی" روی تنه و وظایف روی شاخه ها.
شکل 1. نسخه کاری در شاخه اصلی، کار در حال انجام در شاخه های ویژگی یا شماره

ما از شاخه‌بندی برای نگه‌داشتن نسخه‌ای از کد خود در شعبه اصلی و کد نیمه تکمیل‌شده در شاخه‌های ویژگی یا شماره استفاده می‌کنیم. به این ترتیب شعبه اصلی ما همیشه یک نسخه فعال از کد خواهد داشت.

پیشنهاد می‌کنیم بخوانید:  سرویس فایل‌های استاتیک با Node و Express.jsدر این مقاله، ما قصد داریم یک اپلیکیشن ساده برای ارائه فایل‌های استاتیک مانند فایل‌های HTML، فایل‌های CSS و تصاویر با استفاده از Node.js و Express بسازیم. پیکربندی پروژه و نصب Express برای شروع، بیایید با اجرای دستور init در یک پروژه Node.js جدید ایجاد کنیم.

اما Git این را اجرا نمی‌کند – بلکه این به شما و تیم شما بستگی دارد که تعیین کنید آیا و چگونه از شاخه‌بندی استفاده می‌کنید.

نحوه ایجاد و تغییر شاخه ها در Git

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

پوشه کار در سمت چپ.  مخزن Git با شاخه اصلی در سمت راست.
شکل 2. شاخه اصلی با یک commit.

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

ما پروژه ای را برای به روز رسانی سبک وب سایت شروع می کنیم. ما می‌خواهیم مطمئن شویم که کار ما روی این وظیفه از کد موجود ما جدا شده است، بنابراین یک شاخه از شاخه اصلی ایجاد می‌کنیم.

قبل از شروع کار روی شاخه، به آن شاخه سوئیچ می کنیم. سپس برای وظیفه خود تغییراتی ایجاد می کنیم. ما یک فایل را اصلاح می کنیم، سپس مرحله بندی و به شاخه commit می کنیم. نتیجه در شکل 3 نشان داده شده است.

پوشه کار در سمت چپ.  مخزن Git در سمت راست شاخه "تغییر سبک" را نشان می دهد.
شکل 3. شاخه “تغییر سبک” با اولین کامیت آن.

هر زمان که می خواهید روی یک شعبه کار کنید، به آن شعبه بروید. تغییر به یک شعبه آن شعبه را بررسی می کند. و کد موجود در پوشه کاری ما به طور خودکار به کد آخرین commit در آن شاخه تغییر می کند. سپس تمام commit ها در آن شاخه بررسی شده رخ می دهند.

در این مرحله، یکی از کاربران ما یک مشکل ورود را گزارش می کند. ما تغییر سبک خود را تا حدی کامل کرده ایم، بنابراین نمی خواهیم اصلاح خود را در آن شاخه انجام دهیم.

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

وقتی به آن شاخه سوئیچ می کنیم، پوشه کاری ما کد آن شاخه را منعکس می کند. ما اساساً پوشه کاری خود را به کد شاخه جدید بازنشانی کرده ایم.

پوشه کار در سمت چپ.  مخزن Git در سمت راست شاخه "مشکل ورود" را نشان می دهد.
شکل 4. تغییر به شاخه “مشکل ورود” پوشه کار را بازنشانی می کند

سپس مشکل ورود به سیستم را در این شاخه جدید حل می کنیم، یک فایل را اصلاح کرده و مرحله بندی و تغییر را مطابق شکل 5 انجام می دهیم.

پوشه کار در سمت چپ.  مخزن Git در سمت راست با شاخه "مشکل ورود" است
شکل 5. شاخه “مشکل ورود” با اولین کامیت آن.

آیا این روند در این مرحله مشخص است؟ از آنجایی که ما از شاخه‌ها استفاده کرده‌ایم، می‌توانیم روی مسائل دیگر در حین مطرح شدن بدون تأثیرگذاری بر وظایفی که در حال انجام هستند، کار کنیم.

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

نحوه ادغام شاخه ها در Git

هنگامی که تعمیر ورود ما کامل شد، شاخه “مشکل ورود” را دوباره در شاخه اصلی ادغام می کنیم. همانطور که در شکل 6 نشان داده شده است، پس از ادغام شاخه، می‌توانیم آن را حذف کنیم.

پوشه کار در سمت چپ.  مخزن Git که ادغام شاخه "مشکل ورود" را در main نشان می دهد
شکل 6. ادغام شاخه “مشکل ورود” به اصلی

اکنون به شاخه “تغییر سبک” برمی گردیم تا تغییرات خود را به پایان برسانیم. کد موجود در پوشه کاری ما به طور خودکار به کد آخرین commit در آن شاخه تغییر سبک تغییر می کند.

تغییرات سبک بیشتری ایجاد می کنیم و صحنه می کنیم و آن تغییرات را به شاخه «تغییر سبک» متعهد می کنیم. نتیجه شکل 7 است.

پوشه کار در سمت چپ.  مخزن Git که تعهدات شاخه "تغییر سبک" را نشان می دهد
شکل 7. شاخه “تغییر سبک” با چندین commit

اما صبر کنید…شاخه کد اصلی ما اکنون اصلاحات ورود ما را دارد، اما شاخه “تغییر سبک” ما اینطور نیست.

در برخی موارد، قبل از اینکه شاخه “تغییر سبک” در main ادغام شود، باید تغییر ورود را از main بکشیم.

ما آخرین تغییرات را از شاخه اصلی خود در شاخه “تغییر سبک” ادغام می کنیم و هرگونه تضاد ادغام را حل می کنیم. این یک commit دیگر را همانطور که در شکل 8 نشان داده شده است ایجاد می کند. توجه کنید که پوشه کاری ما اکنون هر دو مجموعه تغییرات را منعکس می کند.

پوشه کار در سمت چپ.  مخزن Git که ادغام را از اصلی به شاخه "تغییر سبک" نشان می دهد
شکل 8. ادغام تغییرات از اصلی به شاخه “تغییر سبک”.

هنگامی که تغییر سبک کامل شد، شاخه “تغییر سبک” را دوباره در شاخه اصلی ادغام می کنیم.

اکنون شاخه اصلی ما همه تغییرات ما را دارد که در شکل 9 نشان داده شده است. و ما می توانیم شاخه “تغییر سبک” خود را حذف کنیم.

پوشه کار در سمت چپ.  مخزن Git در سمت راست نشان دهنده ادغام شاخه "تغییر سبک" به main است
شکل 9. ادغام شاخه “تغییر سبک” به اصلی

توجه داشته باشید که اکثر پروژه ها فرآیند، الزامات و اولویت های خاص خود را برای استفاده از شاخه ها، تعریف commit ها و ادغام تغییرات دارند. قبل از ایجاد شعبه حتماً اسناد پروژه یا با همکاران خود را بررسی کنید.

بسته بندی

ما از یک شاخه برای جداسازی کار روی یک کار، مانند یک ویژگی، تغییر یا مشکل استفاده می‌کنیم. با این کار شاخه اصلی ما از کدهای نیمه کامل یا تست نشده پاک می شود.

ما می توانیم هر تعداد شاخه ویژگی را در هر نقطه از زمان تعریف کنیم. حتما قبل از استیج و تعهد به شاخه مناسب سوئیچ کنید. و در صورت نیاز هر تغییری را از شاخه اصلی ادغام کنید.

وقتی کار کامل شد، شاخه مربوط به آن کار را در main ادغام کنید. شاخه ها کوتاه مدت هستند و اغلب پس از ادغام حذف می شوند

برای اطلاعات بیشتر در مورد Git و GitHub، دوره من را بررسی کنید: “معرفی ملایم GitHub برای مبتدیان”. و برای اطلاعات در مورد توسعه وب، از جمله Angular، در کانال YouTube من مشترک شوید.

حالا چرت خوب زیر آن شاخه های پهن شده چطور؟