'\" t .\" Title: git-bisect .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author] .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 2026-06-29 .\" Manual: Git Manual .\" Source: Git 2.55.0 .\" Language: English .\" .TH "GIT\-BISECT" "1" "2026\-06\-29" "Git 2\&.55\&.0" "Git Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "نام (NAME)" git-bisect \- استفاده از جستجوی دودویی برای یافتن کامیتی که یک باگ را ایجاد کرده است .SH "خلاصه دستور (SYNOPSIS)" .sp .nf \fBgit\fR \fBbisect\fR \fBstart\fR [\fB\-\-term\-\fR(\fBbad\fR|\fBnew\fR)\fB=\fR\fI\fR \fB\-\-term\-\fR(\fBgood\fR|\fBold\fR)\fB=\fR\fI\fR] [\fB\-\-no\-checkout\fR] [\fB\-\-first\-parent\fR] [\fI\fR [\fI\fR\&...]] [\fB\-\-\fR] [\fI\fR\&...] \fBgit\fR \fBbisect\fR (\fBbad\fR|\fBnew\fR|\fI\fR) [\fI\fR] \fBgit\fR \fBbisect\fR (\fBgood\fR|\fBold\fR|\fI\fR) [\fI\fR\&...] \fBgit\fR \fBbisect\fR \fBterms\fR [\fB\-\-term\-\fR(\fBgood\fR|\fBold\fR) | \fB\-\-term\-\fR(\fBbad\fR|\fBnew\fR)] \fBgit\fR \fBbisect\fR \fBskip\fR [(\fI\fR|\fI\fR)\&...] \fBgit\fR \fBbisect\fR \fBnext\fR \fBgit\fR \fBbisect\fR \fBreset\fR [\fI\fR] \fBgit\fR \fBbisect\fR (\fBvisualize\fR|\fBview\fR) \fBgit\fR \fBbisect\fR \fBreplay\fR \fI\fR \fBgit\fR \fBbisect\fR \fBlog\fR \fBgit\fR \fBbisect\fR \fBrun\fR \fI\fR [\fI\fR\&...] \fBgit\fR \fBbisect\fR \fBhelp\fR .fi .sp .SH "توضیحات (DESCRIPTION)" .sp این دستور از الگوریتم جستجوی دودویی برای یافتن اینکه کدام کامیت در تاریخچه پروژه شما یک باگ را ایجاد کرده است، استفاده می‌کند\&. روش استفاده از آن به این صورت است که ابتدا یک کامیت "خراب" (bad) که مشخص است حاوی باگ است، و یک کامیت "سالم" (good) که پیش از ایجاد باگ بوده است را به آن معرفی می‌کنید\&. سپس \fBgit\fR \fBbisect\fR کامیتی را بین این دو نقطه پایانی انتخاب کرده و از شما می‌پرسد که آیا کامیت انتخاب‌شده "سالم" (good) است یا "خراب" (bad)\&. این دستور دامنه را محدودتر و محدودتر می‌کند تا زمانی که دقیقاً همان کامیتی را که تغییر را ایجاد کرده پیدا کند\&. .sp در واقع، \fBgit\fR \fBbisect\fR می‌تواند برای یافتن کامیتی استفاده شود که \fBهر\fR ویژگی پروژه شما را تغییر داده است؛ به عنوان مثال، کامیتی که یک باگ را رفع کرده، یا کامیتی که باعث بهبود کارایی یک بنچمارک شده است\&. برای پشتیبانی از این کاربرد عمومی‌تر، می‌توان از اصطلاحات "قدیمی" (old) و "جدید" (new) به جای "سالم" (good) و "خراب" (bad) استفاده کرد، یا می‌توانید اصطلاحات دلخواه خود را برگزینید\&. برای اطلاعات بیشتر بخش «اصطلاحات جایگزین» را در زیر ببینید\&. .SS "دستورات پایه bisect: start، bad، good" .sp به عنوان مثال، فرض کنید در تلاش هستید تا کامیتی را پیدا کنید که ویژگی خاصی را که در نسخه \fBv2\&.6\&.13\-rc2\fR پروژه به درستی کار می‌کرد، خراب کرده است\&. شما یک نشست bisect را به صورت زیر آغاز می‌کنید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect start $ git bisect bad # نسخه فعلی خراب است $ git bisect good v2\&.6\&.13\-rc2 # مشخص است که نسخه v2\&.6\&.13\-rc2 سالم است .fi .if n \{\ .RE .\} .sp .sp پس از مشخص کردن حداقل یک کامیت خراب و یک کامیت سالم، \fBgit\fR \fBbisect\fR کامیتی را در میانه آن بازه از تاریخچه انتخاب می‌کند، آن را چک‌اوت می‌نماید و خروجی مشابه زیر را نمایش می‌دهد: .sp .if n \{\ .RS 4 .\} .nf Bisecting: 675 revisions left to test after this (roughly 10 steps) .fi .if n \{\ .RE .\} .sp .sp اکنون باید نسخه چک‌اوت‌شده را کامپایل کرده و آن را آزمایش کنید\&. اگر آن نسخه به درستی کار کرد، دستور زیر را وارد کنید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect good .fi .if n \{\ .RE .\} .sp .sp اگر آن نسخه خراب بود، دستور زیر را وارد کنید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect bad .fi .if n \{\ .RE .\} .sp .sp سپس \fBgit\fR \fBbisect\fR با پیامی مشابه زیر پاسخ خواهد داد: .sp .if n \{\ .RS 4 .\} .nf Bisecting: 337 revisions left to test after this (roughly 9 steps) .fi .if n \{\ .RE .\} .sp .sp فرآیند را تکرار کنید: درخت را کامپایل کرده، آن را آزمایش نمایید، و بسته به اینکه نسخه سالم است یا خراب، دستور \fBgit\fR \fBbisect\fR \fBgood\fR یا \fBgit\fR \fBbisect\fR \fBbad\fR را اجرا کنید تا کامیت بعدی که نیاز به آزمایش دارد مشخص شود\&. .sp در نهایت هیچ ویرایش دیگری برای بررسی باقی نخواهد ماند، و دستور توضیحی درباره اولین کامیت خراب چاپ خواهد کرد\&. ارجاع \fBrefs/bisect/bad\fR روی آن کامیت باقی خواهد ماند\&. .SS "بازنشانی bisect (دستور Bisect reset)" .sp پس از یک نشست bisect، برای پاک‌سازی وضعیت جستجوی دودویی و بازگشت به \fBHEAD\fR اصلی، دستور زیر را صادر کنید: .sp .if n \{\ .RS 4 .\} .nf \fBgit\fR \fBbisect\fR \fBreset\fR .fi .if n \{\ .RE .\} .sp .sp به طور پیش‌فرض، این دستور درخت شما را به کامیتی که قبل از \fBgit\fR \fBbisect\fR \fBstart\fR چک‌اوت شده بود بازمی‌گرداند\&. (یک دستور جدید \fBgit\fR \fBbisect\fR \fBstart\fR نیز این کار را انجام می‌دهد، زیرا وضعیت قدیمی bisect را پاک‌سازی می‌کند)\&. .sp با یک آرگومان اختیاری، می‌توانید در عوض به کامیت متفاوتی بازگردید: .sp .if n \{\ .RS 4 .\} .nf \fBgit\fR \fBbisect\fR \fBreset\fR \fI\fR .fi .if n \{\ .RE .\} .sp .sp به عنوان مثال، \fBgit\fR \fBbisect\fR \fBreset\fR \fBbisect/bad\fR اولین ویرایش خراب را چک‌اوت خواهد کرد، در حالی که \fBgit\fR \fBbisect\fR \fBreset\fR \fBHEAD\fR شما را روی کامیت فعلی جستجوی دودویی باقی می‌گذارد و از هرگونه جابجایی بین کامیت‌ها جلوگیری می‌کند\&. .SS "اصطلاحات جایگزین (Alternate terms)" .sp گاهی اوقات شما به دنبال کامیتی که خرابی ایجاد کرده نیستید، بلکه به دنبال کامیتی هستید که باعث تغییری بین یک وضعیت "قدیمی" (old) و وضعیت "جدید" (new) دیگر شده است\&. برای مثال، ممکن است به دنبال کامیتی باشید که یک اصلاح خاص را اضافه کرده است\&. یا ممکن است به دنبال اولین کامیتی باشید که در آن نام فایل‌های کد منبع در نهایت با استاندارد نام‌گذاری شرکت شما مطابقت پیدا کرده است\&. یا هر مورد دیگر\&. .sp در چنین مواردی استفاده از اصطلاحات "سالم" (good) و "خراب" (bad) برای اشاره به «وضعیت قبل از تغییر» و «وضعیت بعد از تغییر» می‌تواند بسیار گیج‌کننده باشد\&. بنابراین در عوض، می‌توانید به ترتیب از اصطلاحات "قدیمی" (old) و "جدید" (new) به جای "سالم" و "خراب" استفاده کنید\&. (اما توجه داشته باشید که نمی‌توانید در یک نشست واحد "good" و "bad" را با "old" و "new" ترکیب کنید)\&. .sp در این کاربرد کلی‌تر، شما به \fBgit\fR \fBbisect\fR یک کامیت "جدید" که دارای یک ویژگی خاص است و یک کامیت "قدیمی" که آن ویژگی را ندارد ارائه می‌دهید\&. هر بار که \fBgit\fR \fBbisect\fR یک کامیت را چک‌اوت می‌کند، شما بررسی می‌کنید که آیا آن کامیت دارای آن ویژگی هست یا خیر\&. اگر بود، کامیت را به عنوان "جدید" (new) علامت‌گذاری کنید؛ در غیر این صورت، آن را به عنوان "قدیمی" (old) علامت بزنید\&. پس از اتمام جستجوی دودویی، \fBgit\fR \fBbisect\fR گزارش خواهد داد که کدام کامیت آن ویژگی را معرفی کرده است\&. .sp برای استفاده از "old" و "new" به جای "good" و "bad"، باید دستور \fBgit\fR \fBbisect\fR \fBstart\fR را بدون کامیت به عنوان آرگومان اجرا کنید و سپس دستورات زیر را برای افزودن کامیت‌ها صادر نمایید: .sp .if n \{\ .RS 4 .\} .nf \fBgit\fR \fBbisect\fR \fBold\fR [\fI\fR] .fi .if n \{\ .RE .\} .sp .sp تا مشخص شود که یک کامیت قبل از تغییر مورد نظر بوده است، یا .sp .if n \{\ .RS 4 .\} .nf \fBgit\fR \fBbisect\fR \fBnew\fR [\fI\fR\&...] .fi .if n \{\ .RE .\} .sp .sp تا مشخص شود که بعد از آن بوده است\&. .sp برای یادآوری اصطلاحات مورد استفاده فعلی، دستور زیر را به کار ببرید: .sp .if n \{\ .RS 4 .\} .nf \fBgit\fR \fBbisect\fR \fBterms\fR .fi .if n \{\ .RE .\} .sp .sp می‌توانید تنها اصطلاح قدیمی را با \fBgit\fR \fBbisect\fR \fBterms\fR \fB\-\-term\-old\fR یا \fBgit\fR \fBbisect\fR \fBterms\fR \fB\-\-term\-good\fR دریافت کنید؛ همچنین \fBgit\fR \fBbisect\fR \fBterms\fR \fB\-\-term\-new\fR و \fBgit\fR \fBbisect\fR \fBterms\fR \fB\-\-term\-bad\fR می‌توانند برای دانستن نحوه نام‌گذاری کامیت‌های تازه‌تر از تغییر مورد نظر استفاده شوند\&. .sp اگر مایلید به جای "bad"/"good" یا "new"/"old" از اصطلاحات دلخواه خود استفاده کنید، می‌توانید با آغاز جستجوی دودویی با دستور زیر هر نامی را که می‌پسندید انتخاب کنید (به جز زیردستورهای موجود bisect مانند \fBreset\fR، \fBstart\fR و غیره): .sp .if n \{\ .RS 4 .\} .nf \fBgit\fR \fBbisect\fR \fBstart\fR \fB\-\-term\-old\fR \fI\fR \fB\-\-term\-new\fR \fI\fR .fi .if n \{\ .RE .\} .sp .sp به عنوان مثال، اگر به دنبال کامیتی هستید که افت کارایی (performance regression) ایجاد کرده است، می‌توانید از دستور زیر استفاده کنید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect start \-\-term\-old fast \-\-term\-new slow .fi .if n \{\ .RE .\} .sp .sp یا اگر به دنبال کامیتی هستید که یک باگ را رفع کرده است، می‌توانید از دستور زیر استفاده کنید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect start \-\-term\-new fixed \-\-term\-old broken .fi .if n \{\ .RE .\} .sp .sp سپس، به جای \fBgit\fR \fBbisect\fR \fBgood\fR و \fBgit\fR \fBbisect\fR \fBbad\fR از \fBgit\fR \fBbisect\fR \fI\fR و \fBgit\fR \fBbisect\fR \fI\fR برای علامت‌گذاری کامیت‌ها استفاده نمایید\&. .SS "مصورسازی/مشاهده bisect (دستور Bisect visualize/view)" .sp برای مشاهده مظنونین باقی‌مانده فعلی در \fBgitk\fR، دستور زیر را در طول فرآیند جستجوی دودویی صادر کنید (زیردستور \fBview\fR می‌تواند به عنوان جایگزینی برای \fBvisualize\fR استفاده شود): .sp .if n \{\ .RS 4 .\} .nf $ git bisect visualize .fi .if n \{\ .RE .\} .sp .sp گیت یک محیط گرافیکی را از طریق متغیرهای محیطی مختلف تشخیص می‌دهد: .PP \fBDISPLAY\fR .RS 4 که در محیط‌های X Window System در سیستم‌های یونیکس تنظیم می‌شود\&. .RE .PP \fBSESSIONNAME\fR .RS 4 که تحت Cygwin در نشست‌های تعاملی دسکتاپ تنظیم می‌شود\&. .RE .PP \fBMSYSTEM\fR .RS 4 که تحت Msys2 و Git for Windows تنظیم می‌شود\&. .RE .PP \fBSECURITYSESSIONID\fR .RS 4 که ممکن است در macOS در نشست‌های تعاملی دسکتاپ تنظیم شود\&. .RE .sp اگر هیچ‌یک از این متغیرهای محیطی تنظیم نشده باشند، در عوض از \fBgit\fR \fBlog\fR استفاده می‌شود\&. همچنین می‌توانید گزینه‌های خط فرمان مانند \fB\-p\fR و \fB\-\-stat\fR را ارسال کنید\&. .sp .if n \{\ .RS 4 .\} .nf $ git bisect visualize \-\-stat .fi .if n \{\ .RE .\} .sp .SS "لاگ و بازپخش bisect (دستورات Bisect log و bisect replay)" .sp پس از علامت‌گذاری ویرایش‌ها به عنوان سالم یا خراب، دستور زیر را صادر کنید تا نشان دهد تا کنون چه کارهایی انجام شده است: .sp .if n \{\ .RS 4 .\} .nf $ git bisect log .fi .if n \{\ .RE .\} .sp .sp اگر متوجه شدید که در تعیین وضعیت یک ویرایش اشتباه کرده‌اید، می‌توانید خروجی این دستور را در یک فایل ذخیره کنید، آن را برای حذف مدخل‌های نادرست ویرایش نمایید، و سپس دستورات زیر را برای بازگشت به وضعیت اصلاح‌شده صادر کنید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect reset $ git bisect replay that\-file .fi .if n \{\ .RE .\} .sp .SS "اجتناب از تست یک کامیت" .sp اگر در میانه یک نشست bisect می‌دانید که ویرایش پیشنهادی مورد مناسبی برای آزمایش نیست (برای مثال در بیلد با شکست مواجه می‌شود و می‌دانید که این خطا ارتباطی با باگی که دنبال می‌کنید ندارد)، می‌توانید به صورت دستی یک کامیت نزدیک را انتخاب کرده و در عوض آن را آزمایش کنید\&. .sp برای مثال: .sp .if n \{\ .RS 4 .\} .nf $ git bisect good/bad # دور قبلی سالم (good) یا خراب (bad) بود\&. Bisecting: 337 revisions left to test after this (roughly 9 steps) $ git bisect visualize # اوه، این مورد جالب نیست\&. $ git reset \-\-hard HEAD~3 # امتحان ۳ ویرایش قبل از آنچه # پیشنهاد شد .fi .if n \{\ .RE .\} .sp .sp سپس ویرایش انتخاب‌شده را کامپایل و آزمایش کنید و پس از آن، ویرایش را به شیوه معمول به عنوان سالم یا خراب علامت‌گذاری نمایید\&. .SS "نادیده گرفتن کامیت در bisect (دستور Bisect skip)" .sp به جای اینکه خودتان یک کامیت نزدیک را انتخاب کنید، می‌توانید با صدور این دستور از گیت بخواهید که این کار را برای شما انجام دهد: .sp .if n \{\ .RS 4 .\} .nf $ git bisect skip # نسخه فعلی قابل آزمایش نیست .fi .if n \{\ .RE .\} .sp .sp با این حال، اگر کامیتی مجاور کامیتی که به دنبال آن هستید را نادیده بگیرید (skip کنید)، گیت قادر نخواهد بود به طور دقیق تشخیص دهد کدام‌یک از آن کامیت‌ها اولین کامیت خراب بوده است\&. .sp همچنین می‌توانید به جای یک کامیت، با استفاده از نماد بازه (range)، بازه‌ای از کامیت‌ها را نادیده بگیرید\&. به عنوان مثال: .sp .if n \{\ .RS 4 .\} .nf $ git bisect skip v2\&.5\&.\&.v2\&.6 .fi .if n \{\ .RE .\} .sp .sp این دستور به فرآیند bisect می‌گوید که هیچ کامیتی پس از \fBv2\&.5\fR، تا و شامل \fBv2\&.6\fR نباید آزمایش شود\&. .sp توجه داشته باشید اگر می‌خواهید اولین کامیت این بازه را نیز نادیده بگیرید، باید دستور زیر را صادر کنید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect skip v2\&.5 v2\&.5\&.\&.v2\&.6 .fi .if n \{\ .RE .\} .sp .sp این به فرآیند bisect می‌گوید که کامیت‌های بین \fBv2\&.5\fR و \fBv2\&.6\fR (شامل هر دو) باید نادیده گرفته شوند\&. .SS "کامیت بعدی در bisect (دستور Bisect next)" .sp به طور معمول، پس از علامت‌گذاری یک ویرایش به عنوان سالم یا خراب، گیت به طور خودکار ویرایش بعدی را برای آزمایش محاسبه و چک‌اوت می‌کند\&. با این حال، اگر نیاز دارید که مرحله بعدی جستجوی دودویی را به صورت صریح درخواست کنید، می‌توانید از دستور زیر استفاده نمایید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect next .fi .if n \{\ .RE .\} .sp .sp ممکن است از این دستور برای از سرگیری فرآیند جستجوی دودویی پس از قطع کردن آن با چک‌اوت یک ویرایش دیگر استفاده کنید\&. .SS "کاهش دامنه جستجوی دودویی با دادن پارامترهای بیشتر به bisect start" .sp اگر بدانید کدام بخش از درخت درگیر مشکلی است که آن را ردیابی می‌کنید، می‌توانید با مشخص کردن پارامترهای pathspec هنگام صدور دستور \fBbisect\fR \fBstart\fR، تعداد مراحل آزمایش را حتی بیشتر کاهش دهید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect start \-\- arch/i386 include/asm\-i386 .fi .if n \{\ .RE .\} .sp .sp اگر از قبل بیش از یک کامیت سالم را می‌شناسید، می‌توانید با مشخص کردن تمام کامیت‌های سالم بلافاصله پس از کامیت خراب در هنگام اجرای دستور \fBbisect\fR \fBstart\fR، فضای bisect را محدودتر کنید: .sp .if n \{\ .RS 4 .\} .nf $ git bisect start v2\&.6\&.20\-rc6 v2\&.6\&.20\-rc4 v2\&.6\&.20\-rc1 \-\- # نسخه v2\&.6\&.20\-rc6 خراب است # نسخه‌های v2\&.6\&.20\-rc4 و v2\&.6\&.20\-rc1 سالم هستند .fi .if n \{\ .RE .\} .sp .SS "اجرای خودکار bisect (دستور Bisect run)" .sp اگر اسکریپتی دارید که می‌تواند تشخیص دهد کد منبع فعلی سالم است یا خراب، می‌توانید با صدور دستور زیر جستجوی دودویی را به صورت خودکار انجام دهید: .sp .if n \{\ .RS 4 .\} .nf \fBgit\fR \fBbisect\fR \fBrun\fR \fI\fR [\fI\fR\&...] .fi .if n \{\ .RE .\} .sp .sp توجه داشته باشید که \fI\fR همراه با \fI\fR در صورتی که کد منبع فعلی سالم/قدیمی (good/old) باشد باید با کد خروج 0 خارج شود، و اگر کد منبع فعلی خراب/جدید (bad/new) باشد باید با کدی بین 1 تا 127 (شامل هر دو)، به جز 125، خارج شود\&. .sp هر کد خروج دیگری فرآیند bisect را متوقف و لغو خواهد کرد\&. باید توجه داشت برنامه‌ای که از طریق \fBexit\fR(\fB\-1\fR) پایان می‌یابد، مقدار 255 = \fB$\fR? را بر جای می‌گذارد (صفحه راهنمای \fBexit\fR(3) را ببینید)، زیرا مقدار با & \fB0377\fR بریده می‌شود\&. .sp کد خروج ویژه 125 باید زمانی استفاده شود که کد منبع فعلی قابل آزمایش نباشد\&. اگر اسکریپت با این کد خارج شود، ویرایش فعلی نادیده گرفته خواهد شد (بخش \fBgit\fR \fBbisect\fR \fBskip\fR را در بالا ببینید)\&. مقدار 125 به عنوان بالاترین مقدار منطقی برای این منظور انتخاب شد، زیرا کدهای 126 و 127 توسط پوسته‌های POSIX برای اعلام وضعیت خطای خاص استفاده می‌شوند (127 برای پیدا نشدن دستور، 126 برای پیدا شدن دستور اما عدم دسترسی اجرایی \(em تا جایی که به \fBbisect\fR \fBrun\fR مربوط می‌شود، این جزئیات اهمیتی ندارند، زیرا آن‌ها خطاهای معمول در اسکریپت هستند)\&. .sp ممکن است اغلب متوجه شوید در طول یک نشست bisect می‌خواهید تغییرات موقتی (مانند \fBs/\fR#define \fBDEBUG\fR \fB0/\fR#define \fBDEBUG\fR \fB1/\fR در یک فایل هدر، یا «ویرایشی که فاقد این کامیت است برای دور زدن مشکل دیگری که این bisect به آن علاقه‌ای ندارد به این وصله نیاز دارد») روی ویرایش تحت آزمایش اعمال کنید\&. .sp برای مقابله با چنین وضعیتی، پس از اینکه \fBgit\fR \fBbisect\fR داخلی ویرایش بعدی را برای آزمایش پیدا کرد، اسکریپت می‌تواند وصله را قبل از کامپایل اعمال کند، آزمایش واقعی را اجرا نماید و سپس تصمیم بگیرد که آیا ویرایش (احتمالاً همراه با وصله لازم) آزمایش را پشت سر گذاشته است یا خیر و سپس درخت را به وضعیت اولیه بازگرداند\&. در نهایت، اسکریپت باید با وضعیت آزمایش واقعی خارج شود تا به حلقه دستور \fBgit\fR \fBbisect\fR \fBrun\fR اجازه دهد نتیجه نهایی نشست bisect را تعیین کند\&. .SH "گزینه‌ها (OPTIONS)" .PP \fB\-\-no\-checkout\fR .RS 4 در هر تکرار از فرآیند جستجوی دودویی، درخت کاری جدید را چک‌اوت نکنید\&. در عوض فقط ارجاعی با نام \fBBISECT_HEAD\fR را به‌روزرسانی کنید تا به کامیتی که باید آزمایش شود اشاره نماید\&. .sp این گزینه ممکن است زمانی مفید باشد که آزمایشی که در هر مرحله انجام می‌دهید نیازی به یک درخت چک‌اوت‌شده نداشته باشد\&. .sp اگر مخزن از نوع bare باشد، \fB\-\-no\-checkout\fR به صورت پیش‌فرض در نظر گرفته می‌شود\&. .RE .PP \fB\-\-first\-parent\fR .RS 4 هنگام مواجهه با یک کامیت ادغام (merge commit)، تنها اولین کامیت والد را دنبال کنید\&. .sp در تشخیص اشکالاتی که از طریق ادغام یک شاخه ایجاد شده‌اند، کامیت ادغام به عنوان منشأ ایجاد باگ شناسایی می‌شود و اجداد آن نادیده گرفته خواهند شد\&. .sp این گزینه به ویژه برای جلوگیری از نتایج مثبت کاذب زمانی که یک شاخه ادغام‌شده شامل کامیت‌های خراب یا غیرقابل بیلد بود اما خود ادغام مشکلی نداشت، بسیار مفید است\&. .RE .SH "مثال‌ها (EXAMPLES)" .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} جستجوی دودویی خودکار برای یک بیلد خراب بین v1\&.2 و \fBHEAD\fR: .sp .if n \{\ .RS 4 .\} .nf $ git bisect start HEAD v1\&.2 \-\- # نسخه HEAD خراب و v1\&.2 سالم است $ git bisect run make # دستور make برنامه را بیلد می‌کند $ git bisect reset # خروج از نشست bisect .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} جستجوی دودویی خودکار برای شکست تست بین origin و \fBHEAD\fR: .sp .if n \{\ .RS 4 .\} .nf $ git bisect start HEAD origin \-\- # نسخه HEAD خراب و origin سالم است $ git bisect run make test # دستور make test بیلد و تست می‌کند $ git bisect reset # خروج از نشست bisect .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} جستجوی دودویی خودکار برای یک مورد آزمایشی (test case) خراب: .sp .if n \{\ .RS 4 .\} .nf $ cat ~/test\&.sh #!/bin/sh make || exit 125 # این بیلد‌های خراب را نادیده می‌گیرد ~/check_test_case\&.sh # آیا تست پاس می‌شود؟ $ git bisect start HEAD HEAD~10 \-\- # مقصر در میان ۱۰ کامیت آخر است $ git bisect run ~/test\&.sh $ git bisect reset # خروج از نشست bisect .fi .if n \{\ .RE .\} .sp در اینجا ما از یک اسکریپت سفارشی \fBtest\&.sh\fR استفاده می‌کنیم\&. در این اسکریپت، اگر \fBmake\fR با شکست مواجه شود، از کامیت فعلی صرف‌نظر می‌کنیم\&. \fBcheck_test_case\&.sh\fR در صورت موفقیت مورد آزمایشی باید با \fBexit\fR \fB0\fR و در غیر این صورت با \fBexit\fR \fB1\fR خارج شود\&. .sp امن‌تر است که هر دو فایل \fBtest\&.sh\fR و \fBcheck_test_case\&.sh\fR در خارج از مخزن قرار داشته باشند تا از تداخل بین فرآیندهای bisect، \fBmake\fR و تست با اسکریپت‌ها جلوگیری شود\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} جستجوی دودویی خودکار با اصلاحات موقت (hot\-fix): .sp .if n \{\ .RS 4 .\} .nf $ cat ~/test\&.sh #!/bin/sh # تغییر درخت کاری با ادغام شاخه hot-fix # و سپس تلاش برای ساخت (build) if git merge \-\-no\-commit \-\-no\-ff hot\-fix && make then # اجرای تست اختصاصی پروژه و گزارش وضعیت آن ~/check_test_case\&.sh status=$? else # به فراخواننده اطلاع دهید این نسخه غیرقابل آزمایش است status=125 fi # لغو تغییر اعمال‌شده تا امکان انتقال تمیز به کامیت بعدی فراهم شود git reset \-\-hard # بازگرداندن کنترل exit $status .fi .if n \{\ .RE .\} .sp این اسکریپت اصلاحات یک شاخه hot\-fix را قبل از اجرای هر آزمون اعمال می‌کند، به عنوان مثال در صورتی که محیط ساخت یا آزمون شما تغییر کرده باشد به طوری که ویرایش‌های قدیمی‌تر به اصلاحی نیاز داشته باشند که ویرایش‌های جدیدتر از قبل آن را دارند\&. (اطمینان حاصل کنید شاخه hot\-fix بر اساس کامیتی ساخته شده باشد که در تمام ویرایش‌های مورد بررسی در جستجوی دودویی وجود دارد، تا ادغام موارد اضافی زیادی را وارد نکند، یا از \fBgit\fR \fBcherry\-pick\fR به جای \fBgit\fR \fBmerge\fR استفاده کنید)\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} جستجوی دودویی خودکار برای یک مورد آزمایشی خراب: .sp .if n \{\ .RS 4 .\} .nf $ git bisect start HEAD HEAD~10 \-\- # مقصر در میان ۱۰ کامیت آخر است $ git bisect run sh \-c "make || exit 125; ~/check_test_case\&.sh" $ git bisect reset # خروج از نشست bisect .fi .if n \{\ .RE .\} .sp این نشان می‌دهد که اگر آزمون را در یک خط بنویسید، می‌توانید بدون اسکریپت اجرا کار را پیش ببرید\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} مکان‌یابی یک ناحیه سالم از گراف اشیاء در یک مخزن آسیب‌دیده .sp .if n \{\ .RS 4 .\} .nf $ git bisect start HEAD [ \&.\&.\&. ] \-\-no\-checkout $ git bisect run sh \-c \*(Aq GOOD=$(git for\-each\-ref "\-\-format=%(objectname)" refs/bisect/good\-*) && git rev\-list \-\-objects BISECT_HEAD \-\-not $GOOD >tmp\&.$$ && git pack\-objects \-\-stdout >/dev/null