3.4 شاخه‌سازی در گیت - روند کاری شاخه‌سازی

از آنجایی که گیت از مرج سه طرفهٔ ساده‌ای استفاده می‌کند، مرج کردن متوالی برنچی به برنچ دیگر عموماً آسان است. این بدان معناست که می‌توانید چندین برنچ داشته باشید که همیشه باز هستند و از آنها برای بخش‌های مختلف چرخهٔ توسعه خود استفاده کنید؛ می‌توانید به طور منظم آنها را در یکدیگر ادغام کنید.

بسیاری از توسعه‌دهنگان روند کاری دارند که این رویکرد را در بر می‌گیرد، مثلاً در برنچ master خود فقط کدهای تماماً پایدار را نگه‌داری می‌کنند — که احتمالاً فقط کدی است که یا منتشر شده است یا منتشر خواهد شد. همچنین احتمالاً آنها برنچی موازی هم با نام develop یا next دارند که روی آن کار می‌کنند یا از آن برای تست ثبات استفاده می‌کنند — این برنچ لزوماً همیشه باثبات نیست لکن هرگاه که به وضعیت باثباتی برسد می‌تواند در master مرج شود. هنگام آماده شدن برنچ‌های موضوعی (برنچ‌های کوتاه عمری مانند iss53 قبل‌ترتان) این برنچ برای پول کردن آنها استفاده می‌شود تا از اینکه آنها همهٔ تست‌ها را پاس می‌شوند و باگی تولید نمی‌کنند اطمینان حاصل شود.

در حقیقت ما دربارهٔ نشانگرهایی که در خطوط کامیت‌های تولیدی شما حرکت می‌کنند حرف می‌زنیم. برنچ باثبات معمولاً بسیار پایین‌تر در خط تاریخچهٔ کامیت‌های شما هستند و برنچ‌های بروز (Bleeding-edge) بسیار بالاتر در تاریخچه قرار دارند.

به طور کل آسان‌تر است که به برنچ‌ها به عنوان سیلوهای کار نگاه کنیم. جایی که وقتی مجموعه‌ای از کامیت‌ها کاملاً تست شدند به سمت سیلویی باثبات‌تر انتقال داده می‌شوند.

شما می‌توانید این فرآیند را برای چند مرتبه از ثبات تکرار کنید. بعضی از پروژه‌های بزرگ‌تر همچنین برنچ pu یا proposed (بروزرسانی پیشنهادی) دارند که مجتمعی از برنچ‌هایی است که ممکن است هنوز برای راه یافتن به برنچ master یا next آماده نباشند. ایدهٔ کلی این است که برنچ‌های شما در مرتبه‌های مختلف ثبات هستند؛ وقتی به مرتبهٔ بالاتری از ثبات رسیدند، در برنچی که در مرتبهٔ بالاتر است مرج خواهند شد. مجدداً، داشتن چندین برنچ‌ها فعال همزمان لزومی ندارد، اما اغلب مفید است، به خصوص وقتی که با پروژه‌های خیلی بزرگ یا پیچیده سروکار دارید.

برنچ‌های موضوعی، از سوی دیگر، در پروژه‌هایی با هر اندازه مفید هستند. یک برنچ موضوعی، برنچی کم عمر است که مختص یک کار یا ویژگی خاص می‌سازید و استفاده می‌کنید. این کاری است که به احتمال خیلی زیاد، هرگز در هیچ VCS دیگر انجام نداده‌اید چرا که به طور کل هزینهٔ ساخت و ادغام برنچ‌ها زیاد است. لکن در گیت ساختن، ادغام، پاک‌کردن و کار کردن روزانهٔ برنچ‌ها رایج است.

در بخش قبل هنگام کار با برنچ‌های iss53 و hotfix که ساختید متوجه این شده‌اید. شما تعدادی کامیت روی آنها ساختید و آنها را به محض ادغام با برنچ اصلیتان پاک کردید. این روش به شما این امکان را می‌دهد که سریعاً و تماماً محتوای کاری را تغییر دهید — از آنجایی که کارهای شما به سیلوهایی مجزا تقسیم شده که تمام تغییراتی که در آن برنچ اعمال می‌شود باید مرتبط با آن موضوع باشد، اطلاع از اتفاقاتی که حین بازبینی کد و غیره افتاده بسیار آسان‌تر است. شما می‌توانید تغییرات خود را برای دقایق، روزها و یا ماه‌ها نگه‌داری کنید و وقتی آماده بودند آنها را بی‌توجه به ترتیب کاری یا پیدایش آنها ادغام کنید.

شرایطی را تصور کنید که در حال کار کردن (روی master) هستید، برای یک ایشو یک برنچ می‌سازید (iss91)، کمی روی آن کار می‌کنید، برنچ دومی را می‌سازید تا همان مسئله را به صورت دیگری حل کنید (iss91v2)، به برنچ master خود باز می‌گردید و آنجا کمی فعالیت می‌کنید و سپس یک برنچ دیگر می‌سازید تا کمی روی ایده‌ای که مطمئن نیستید خوب است یا خیر کار کنید (برنچ dumbidea). تایخچهٔ کامیت‌هایتان این شکلی به نظر خواهد رسید:

حال فرض کنیم که فکر می‌کنید راه حل دوم بهترین راه حل برای این مشکل است (iss91v2)؛ و برنچ dumbidea را نیز به همکارتان نشان داده‌اید و بسیار هوشمندانه به نظر رسیده است. شما می‌توانید برنچ iss91 را حذف کنید (کامیت‌های C5 و C6 را از دست می‌دهید) و دو برنچ دیگر را ادغام می‌کنید. پس از این تاریخچهٔ شما بدین شکل خواهد بود:

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

مهم است به خاطر داشته باشید که هنگامی که تمام این کارها انجام می‌شود، تمام برنچ‌ها تماماً محلی هستند. وقتی شاخه‌سازی یا مرج می‌کنید، همه چیز فقط در مخزن گیت شما اتفاق می‌افتد — ارتباطی با سرور برقرار نیست.