Git می تواند اشکال زدایی را سرعت بخشد. هنگامی که علیرغم بررسی CI/CD و سایر آزمایش‌ها، رگرسیون یا اشکالی در تولید دارید، شناسایی ارتکاب(های) بد بالقوه یک رویکرد خوب است.
این کد قبل از استقرار اخیر به خوبی کار می کرد، بنابراین یک شانس معقول برای رفع این وضعیت با بررسی تاریخچه Git وجود دارد.
گاهی اوقات، بسیار عمیق تر از آن است، اما اجازه دهید یک مورد ساده را در اینجا فرض کنیم.
رویکرد دستی
به سادگی مقداری sha یا برچسب را بررسی کنید:
git checkout {LAST_TAG}
git checkout {SOME_SHA}
خواهید دید که آیا این روی محیط تست شما کار می کند یا خیر.
توجه داشته باشید که بسیاری از تیم‌های توسعه‌دهنده دارای اسکریپت‌های خودکار برای بازگرداندن نسخه‌های بد هستند، اما اگر اینطور نیست، همچنان می‌توانید این کار را به صورت دستی انجام دهید.
blame آی تی!
روش دیگر شامل استفاده از git blame برای علامت گذاری هر فایل مشکوکی، به عنوان مثال:
git blame -C -L 111,156 myscript.py
توجه داشته باشید که حتی می توانید حاشیه نویسی خود را به خطوط خاصی محدود کنید و از آن استفاده کنید -C برای تجزیه و تحلیل بهتر (مخصوصا اگر قطعه کد را از فایل های دیگر منتقل می کنید).
bisect آی تی!
جستجوی دودویی به علامت گذاری وضعیت های خوب و بد اجازه می دهد تا تحقیقات شما را محدود کند و در نهایت ارتکاب بد را شناسایی کند:
git bisect start
git bisect bad # "broken state"
git bisect good {TAG} # last known "good state"
چرا این کار را می کند؟ هدف صرفه جویی در زمان است bisect برخی از بررسی‌ها را خودکار می‌کند (مخصوصاً در نیمه راه بین خوب و بد انجام می‌شود)، به شما این امکان را می‌دهد که به سرعت تعیین کنید که «کجا» (به جای آن احتمالاً باید بگویم «چه زمانی») احتمالاً مرتکب بد است.
زمانی که تعهدات زیادی برای بازرسی دارید، بسیار مفید است.
Git حتی می تواند اسکریپت های سفارشی را در حین بازرسی اجرا کند:
git bisect run test.sh
منبع: Git documentation
برای بستن حالت بازرسی اجرا کنید git bisect reset.
بسته شدن
چه استفاده کنید bisect یا نه، Git می تواند اشکال زدایی را سرعت بخشد، که در مواقع اضطراری در تولید مفید است.
