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 را از دست می‌دهید) و دو برنچ دیگر را ادغام می‌کنید. پس از این تاریخچهٔ شما بدین شکل خواهد بود:

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

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