این در ابتدا در وبلاگ من ارسال شده بود و برای دسترسی مجدد در اینجا ارسال می شود. لطفاً آن را به اشتراک بگذارید و اگر دوست داشتید یا سؤالی دارید به من بگویید!
هنگام توسعه یک ویژگی نرم افزاری جدید یا رفع اشکالی که در آن همه چیز کدگذاری، آزمایش و بررسی شده است، به نقطه ای می رسد. اگر git با شاخه‌های رفع اشکال/ویژگی استفاده می‌شود، گام بعدی چالش دلهره‌آور ادغام کدهای جدید نوشته شده با شاخه‌ای است که از آن جدا شده‌ایم. چندین استراتژی رایج برای مدیریت ادغام در git وجود دارد. موارد مورد علاقه در این پست عبارتند از: فوروارد سریع، سه راه و اسکواش. چیزی که در نهایت باید از خود بپرسید این است:
استراتژی ادغامی که انتخاب می‌کنید در واقع به این سؤال منتهی می‌شود: آیا می‌خواهید تاریخچه تعهد را حفظ کنید یا بازگشت این ادغام را آسان کنید؟ در هر سازمان نرم افزاری، پاسخ به این سوال به این بستگی دارد که در ساختار شعبه خود کجا هستید و چه چیزی را ادغام می کنید. برای درک اینکه چه تفاوت هایی در این استراتژی ها وجود دارد، ابتدا باید با توصیف آنچه که باید هنگام ادغام اتفاق بیفتد شروع کنیم. از آنجا می توانیم نحوه عملکرد این استراتژی ها را مورد بحث قرار دهیم. با این درک ما سپس به پاسخ به این سؤال خواهیم پرداخت.
Git هنگام ادغام شاخه ها چه کاری باید انجام دهد؟
بیایید تصور کنیم که یک توسعه دهنده یک شاخه جدید (ویژگی/تست) از یک شاخه دیگر (توسعه) ایجاد می کند تا روی آن کار کند. آنها تغییری ایجاد می کنند که به شعبه خود متعهد می شوند تا رفع اشکال یا ویژگی خود را پیاده سازی کنند. پس از اتمام آنها باید دوباره در شاخه ای که از آن جدا شده اند ادغام شوند. اگر در این مدت تغییرات دیگری در شاخه اصلی ایجاد شود، نتیجه ممکن است چیزی شبیه به این باشد:
اگر به دنبال ادغام تغییرات از شاخه ویژگی در git شاخه توسعه هستیم، باید مطمئن شویم که هر commit از هر دو شاخه پس از ادغام در شاخه توسعه وجود دارد. Git چندین استراتژی ادغام دارد که می تواند از آن استفاده کند تا مطمئن شود که تمام commit ها به صورت فعلی، سریع، سه طرفه و اسکواش به پایان می رسند.
Git چگونه شاخه های واگرا را مدیریت می کند؟ یک تعهد ادغام / ادغام سه راه
اگر پس از جدا شدن شاخه ویژگی/تست، تغییراتی در شاخه توسعه ایجاد شود، لازم است هنگام ادغام یک ادغام جداگانه ایجاد شود. این کار را انجام می دهد تا مشخص کند که یک ادغام باید اتفاق بیفتد (خواه درگیری های ادغام وجود داشته باشد یا نه). اگر بین کدهایی که در دو شاخه اضافه شده تضاد وجود داشته باشد، مانند تغییر در خطوط مشابه در همان فایل، git نسخه ای از فایل را با مقداری متن اضافه شده ذخیره می کند تا تغییر را مشخص کند. توسعه دهنده باید تغییرات را حل کند و سپس تغییرات را به عنوان یک ادغام commit انجام دهد. اگر گیت تداخلی وجود نداشته باشد، به سادگی یک commit ادغام ایجاد می کند. این در نهایت به شکل زیر می شود:
Git Fast Forward Merge چیست؟
اکنون که می دانیم در حین ادغام وقتی شاخه ها از هم جدا شده اند چه اتفاقی می افتد، بیایید در مورد استراتژی ادغام سریع به جلو صحبت کنیم. نام استراتژی در این مورد بسیار توصیفی است. استراتژی فوروارد سریع سعی می کند هر commit را از شاخه ویژگی در شاخه توسعه اعمال کند. هنگامی که پس از جدا شدن شاخه‌ها هیچ تعهدی روی شاخه توسعه وجود ندارد، می‌توان این کار را با به‌روزرسانی نشانگر سر شاخه توسعه به آخرین commit که در شاخه جدید است انجام داد و آن را یک روز نامید. مزیت ادغام سریع به جلو این است که تاریخچه commit را در شاخه بدون افزودن هیچ گونه تعهد اضافی حفظ می کند. چیزی شبیه این به نظر می رسد:
ادغام کدو حلوایی چیست؟
commit اسکواش نیز زمانی که بدانید چه کاری انجام می دهد به درستی نامگذاری می شود. تمام کامیت هایی که روی یک شاخه اتفاق افتاده را می گیرد و آنها را به یک کامیت تبدیل می کند. بیایید بگوییم که ما با یک دسته از commit ها در شاخه feature/test2 به شرح زیر شروع می کنیم:
ادغام اسکواش از نظر فنی دو عمل است: اسکواش و ادغام. از خط فرمان، این هر دو در دستور واحد git merge –squash feature/test2 مدیریت می شوند. با این حال، GitKraken تأکید می کند که این اقدامات جداگانه هستند. در اینجا می توانید ببینید که من تمام commit ها را از بالا در یک commit در feature/test2 له کرده ام.
زیرا هیچ تعهد دیگری در توسعه وجود ندارد زیرا git دو شاخه واگرا می تواند به سرعت به commit فعلی در feature/test2 توسعه یابد.
چه زمانی می خواهیم از این استراتژی های مختلف ادغام استفاده کنیم؟
اکنون که این استراتژی‌های ادغام را در عمل دیدیم، می‌توانیم درباره زمان و چرایی استفاده از هر کدام صحبت کنیم. طبق معمول، بستگی دارد. هر یک از استراتژی ها در موقعیت های مختلف مفید است. نسخه کوتاه این است که فوروارد سریع یا ادغام سه طرفه در شاخه‌ای مفید است که می‌خواهید تاریخچه commitها را حفظ کنید و در جایی که نمی‌خواهید اسکواش کنید. بحث بیشتر از اینجا فرض می‌کند که یک شاخه توسعه وجود دارد که با آنچه توسعه‌دهندگان روی آن کار می‌کنند مطابقت دارد و سلسله مراتبی از شاخه‌های بالا توسعه می‌یابد که نشان‌دهنده وضعیت فعلی محیط‌هایی است که به آنها (QA، UAT، تولید، و غیره) منتشر می‌شوند.
کاندیدای احتمالی برای ادغام اسکواش زمانی است که یک توسعه‌دهنده در حال ادغام کدهایی است که روی آن کار می‌کرده است، در شاخه‌ای از ویژگی یا رفع اشکال که از شاخه توسعه جدا شده و به توسعه باز می‌گردد. شاخه ویژگی/رفع اشکال احتمالاً دارای تعهدات زیادی است که نشان دهنده کار روزانه توسعه دهنده است. این تاریخچه ارتکاب لزوماً در نمای سطح بالاتر پروژه مهم نیست و به همین ترتیب، برای شاخه های سطح بالاتر نیز مهم نیست. برعکس، خود ویژگی به عنوان یک کل مهم است. با توجه به اینکه ادغام اسکواش کل ویژگی را به یک commit فشرده می‌کند، نه تنها تاریخچه commit را که ممکن است نویز در نظر گرفته شود حذف می‌کند، بلکه امکان بازگشت آسان ویژگی را با برگرداندن یک commit می‌دهد.
اگر ویژگی‌ها در شاخه توسعه ادغام شوند، در نهایت با مجموعه‌ای از commitها مواجه می‌شویم که نشان‌دهنده اضافه شدن کل ویژگی‌ها یا رفع اشکال هستند. این سابقه تعهد است که برای نمای سطح بالای پروژه اهمیت دارد. این باعث می شود که استفاده از ادغام سریع به جلو هنگام ادغام از شاخه های توسعه تا QA/UAT/Prod بسیار منطقی باشد. اگر بتوانیم بدون معرفی commit های ادغام در این شاخه ها سریع جلو برویم، حتی بهتر است.
نتیجه – ویژگی اسکواش متعهد می شود و بعد از آن سریع به جلو می رود
برای هر نوع تعهد زمانی و مکانی وجود دارد. تنها توصیه اضافی که من به این اضافه می کنم این است: قبل از اینکه ادغام را حل کنید، در شاخه ویژگی خود ادغام کنید. با انجام این کار، ادغام اسکواش در توسعه می تواند سریعاً ارسال شود و از داشتن یک ادغام اضافی اجتناب شود. پس از توسعه، می توانید ویژگی های خود را به راحتی از طریق محیط خود به بالا منتقل کنید.
برای خواندن جالب دیگر، پست من در مورد نحوه برخورد من با نرم افزار نوشتن را بررسی کنید. اگر به موضوعات git بیشتر علاقه دارید، پرایمر من را در git stash بخوانید.
