| GIT-REPLAY(1) | Git Manual | GIT-REPLAY(1) |
نام (NAME)
git-replay - بازپخش کامیت‌ها بر روی پایه‌ای جدید (آزمایشی و سازگار با مخازن bare)
خلاصه دستور (SYNOPSIS)
(آزمایشی!) git replay ([--ontained] --<ewbase> | --dvance=<branch> | --evert=<branch>)
[--ef=<ref>] [--ef-action=<mode>] <revision-range>
توضیحات (DESCRIPTION)
محدوده‌ای از کامیت‌ها را گرفته و آن‌ها را در مکانی جدید بازپخش (replay) می‌کند. درخت کاری (working tree) و نمایه (index) را دست‌نخورده باقی می‌گذارد. به طور پیش‌فرض، مراجع مربوطه را با استفاده از یک تراکنش اتمیک به‌روزرسانی می‌کند (یا همه مراجع به‌روزرسانی می‌شوند یا هیچ‌کدام). برای جلوگیری از به‌روزرسانی خودکار مراجع و در عوض دریافت دستورات به‌روزرسانی که بتوان آن‌ها را به git update-ref --din لوله‌کشی کرد، از --ef-action=print استفاده کنید (بخش خروجی (OUTPUT) در زیر را ببینید).
این دستور آزمایشی است. رفتار آن ممکن است در آینده تغییر کند.
گزینه‌ها (OPTIONS)
--<ewbase>
هنگامی که -- مشخص شود، شاخه(های) موجود در محدوده بازنگری به‌روزرسانی می‌شوند تا به کامیت‌های جدید اشاره کنند، مشابه روشی که git rebase --pdate-refs چندین شاخه را در محدوده تحت تأثیر به‌روزرسانی می‌کند.
--dvance=<branch>
تاریخچه بر روی <branch> بازپخش می‌شود و <branch> به‌روزرسانی می‌گردد تا به نوک تاریخچه حاصل اشاره کند. این با -- متفاوت است که تنها از هدف به عنوان نقطه شروع استفاده می‌کند بدون اینکه آن را به‌روزرسانی کند.
--evert=<branch>
هنگامی که --evert مشخص شود، کامیت‌های موجود در محدوده بازنگری بازگردانی می‌شوند (تغییرات آن‌ها باطل می‌شود) و کامیت‌های بازگردانی‌شده بر روی <branch> ایجاد می‌گردند. سپس <branch> به‌روزرسانی می‌شود تا به کامیت‌های جدید اشاره کند. این کار مشابه اجرای دستور git revert <revision-range> است، اما درخت کاری را به‌روزرسانی نمی‌کند.
پیام‌های کامیت از قراردادهای git revert پیروی می‌کنند: آن‌ها با پیشوند "Revert" آغاز شده و عبارت "This reverts commit <hash>." را در بر دارند. هنگام بازگردانی کامیتی که پیام آن با "Revert" شروع شده است، پیام جدید در عوض از "Reapply" استفاده می‌کند. برخلاف cherry-pick که نویسنده اصلی را حفظ می‌کند، کامیت‌های بازگردانی از کاربر جاری به عنوان نویسنده استفاده می‌کنند که با رفتار git revert مطابقت دارد.
این گزینه با -- و --dvance مانعة‌الجمع است. همچنین با --ontained (که تنها اصلاح‌کننده‌ای برای -- است) ناسازگار می‌باشد.
--ontained
--ef=<ref>
--ef-action[=<mode>]
حالت پیش‌فرض را می‌توان از طریق متغیر پیکربندی replay.refAction تنظیم نمود.
<revision-range>
محدود کردن کامیت‌ها (Commit Limiting)
علاوه بر مشخص کردن محدوده‌ای از کامیت‌ها که باید با استفاده از نمادگذاری‌های ویژه توضیح داده‌شده در بخش توضیحات فهرست شوند، محدودسازی‌های بیشتری نیز روی کامیت‌ها قابل اعمال است.
استفاده از گزینه‌های بیشتر عموماً خروجی را بیشتر محدود می‌کند (برای نمونه --since=<date1> نتایج را به کامیت‌های جدیدتر از <date1> محدود می‌سازد، و استفاده از آن همراه با --grep=<pattern> نتایج را به کامیت‌هایی محدود می‌کند که پیام لاگ آن‌ها شامل خطی منطبق با <pattern> باشد)، مگر اینکه خلاف آن ذکر شده باشد.
توجه داشته باشید که این محدودیت‌ها پیش از گزینه‌های مرتب‌سازی و قالب‌بندی کامیت، مانند --reverse اعمال می‌شوند.
-<number>, -n <number>, --max-count=<number>
--max-count-oldest=<number>
--skip=<number>
--since=<date>, --after=<date>
--since-as-filter=<date>
--until=<date>, --before=<date>
--author=<pattern>, --committer=<pattern>
--grep-reflog=<pattern>
--grep=<pattern>
هنگامی که --notes فعال باشد، پیام موجود در یادداشت‌ها به‌گونه‌ای تطبیق داده می‌شود که گویی بخشی از پیام لاگ است.
--all-match
--invert-grep
-i, --regexp-ignore-case
--basic-regexp
-E, --extended-regexp
-F, --fixed-strings
-P, --perl-regexp
پشتیبانی از این نوع عبارات باقاعده یک وابستگی اختیاری در زمان کامپایل است. اگر گیت بدون پشتیبانی از آن‌ها کامپایل شده باشد، ارائه این گزینه باعث خاتمه همراه با خطای برنامه می‌شود.
--remove-empty
--merges
--no-merges
--min-parents=<number>, --max-parents=<number>, --no-min-parents, --no-max-parents
گزینه‌های --no-min-parents و --no-max-parents این محدودیت‌ها را دوباره (به حالت بدون محدودیت) بازنشانی می‌کنند. شکل‌های معادل عبارتند از --min-parents=0 (هر کامیتی دارای ۰ یا چند والد است) و --max-parents=-1 (اعداد منفی نشان‌دهنده نبود حد بالاست).
--first-parent
--exclude-first-parent-only
--maximal-only
--not
--all
--branches[=<pattern>]
--tags[=<pattern>]
--remotes[=<pattern>]
--glob=<glob-pattern>
--exclude=<glob-pattern>
الگوهای داده‌شده هنگام اعمال روی --branches, --tags, یا --remotes نباید با refs/heads, refs/tags, یا refs/remotes آغاز شوند، و هنگام اعمال روی --glob یا --all باید حتماً با refs/ شروع شوند. اگر یک /* پایانی مد نظر باشد، باید صریحاً قید شود.
--exclude-hidden=(fetch|receive|uploadpack)
--reflog
--alternate-refs
--single-worktree
--ignore-missing
--bisect
--stdin
--cherry-mark
--cherry-pick
برای نمونه، اگر دو شاخه A و B داشته باشید، روش معمول برای فهرست کردن تمام کامیت‌های موجود در یک طرف آن‌ها استفاده از --left-right است (مثال زیر در توضیحات گزینه --left-right را ببینید). با این حال، کامیت‌هایی را که از شاخه دیگر دست‌چین (cherry-pick) شده‌اند نشان می‌دهد (برای مثال «سومین در b» ممکن است از شاخه A دست‌چین شده باشد). با این گزینه، چنین جفت کامیت‌هایی از خروجی مستثنی می‌شوند.
--left-only, --right-only
برای نمونه، --cherry-pick --right-only A...B آن دسته از کامیت‌های موجود در B را که در A هستند یا معادل وصله‌ای با یک کامیت در A می‌باشند حذف می‌کند. به عبارت دیگر، این دستور کامیت‌های + را از git cherry A B فهرست می‌کند. به‌طور دقیق‌تر، --cherry-pick --right-only --no-merges فهرست دقیق را ارائه می‌دهد.
--cherry
-g, --walk-reflogs
با قالبی از --pretty به‌جز oneline و reference (به دلایل واضح)، این گزینه باعث می‌شود خروجی دارای دو خط اطلاعات اضافی برگرفته از رِف‌لاگ باشد. نشان‌دهنده رِف‌لاگ در خروجی ممکن است به‌صورت ref@{<Nth>} (که در آن <Nth> اندیس معکوس زمانی در رِف‌لاگ است) یا به‌صورت ref@{<timestamp>} (همراه با <timestamp> آن مدخل) بسته به چند قانون نمایش داده شود:
تحت --pretty=oneline, پیام کامیت با این اطلاعات در همان خط پیشوند می‌گیرد. این گزینه با --reverse قابل ترکیب نیست. همچنین به git-reflog(1) مراجعه کنید.
تحت --pretty=reference, این اطلاعات اصلاً نمایش داده نخواهند شد.
--merge
--boundary
ساده‌سازی تاریخچه (History Simplification)
گاهی اوقات شما تنها به بخش‌هایی از تاریخچه علاقه‌مندید، برای نمونه کامیت‌هایی که یک <path> خاص را تغییر می‌دهند. اما ساده‌سازی تاریخچه دو بخش دارد: یک بخش انتخاب کامیت‌ها است و بخش دیگر چگونگی انجام آن، چرا که راهبردهای گوناگونی برای ساده‌سازی تاریخچه وجود دارد.
گزینه‌های زیر کامیت‌های نمایش‌داده‌شده را انتخاب می‌کنند:
<paths>
--simplify-by-decoration
توجه داشته باشید که ممکن است کامیت‌های اضافی نیز برای ارائه یک تاریخچه معنادار نمایش داده شوند.
گزینه‌های زیر بر نحوه انجام ساده‌سازی تأثیر می‌گذارند:
حالت پیش‌فرض (Default mode)
--show-pulls
--full-history
--dense
--sparse
--simplify-merges
--ancestry-path[=<commit>]
توضیحات دقیق‌تر در ادامه می‌آید.
فرض کنید شما foo را به‌عنوان <paths> مشخص کرده‌اید. ما کامیت‌هایی را که foo را تغییر می‌دهند !TREESAME (نایکسان از نظر درخت) و بقیه را TREESAME (یکسان از نظر درخت) می‌نامیم. (در یک diff فیلترشده برای foo، آن‌ها به ترتیب متفاوت و برابر به نظر می‌رسند.)
در ادامه، ما همواره به همین تاریخچه نمونه برای نشان دادن تفاوت‌های بین تنظیمات ساده‌سازی ارجاع خواهیم داد. فرض می‌کنیم شما در حال فیلتر کردن برای فایل foo در این گراف کامیت هستید:
.-A---M---N---O---P---Q / / / / / / I B C D E Y \ / / / / / `-------------' X
خط افقی تاریخچه A---Q به‌عنوان والد نخست هر ادغام در نظر گرفته می‌شود. کامیت‌ها عبارتند از:
دستور rev-list در تاریخچه به سمت عقب پیمایش می‌کند، و بر اساس اینکه آیا --full-history و/یا بازنویسی والدین (از طریق --parents یا --children) استفاده شده باشد، کامیت‌ها را شامل یا مستثنی می‌سازد. تنظیمات زیر در دسترس هستند.
حالت پیش‌فرض (Default mode)
این منجر به نتیجه زیر می‌شود:
.-A---N---O / / / I---------D
توجه کنید چگونه قاعده دنبال کردن تنها والد TREESAME (در صورت وجود)، B را کاملاً از بررسی حذف کرد. C از طریق N بررسی شد، اما وضعیت TREESAME داشت. کامیت‌های ریشه با یک درخت خالی مقایسه می‌شوند، بنابراین I دارای وضعیت !TREESAME است.
روابط والد/فرزند تنها با --parents قابل مشاهده هستند، اما این موضوع بر کامیت‌های انتخاب‌شده در حالت پیش‌فرض تأثیری ندارد، بنابراین ما خطوط والدین را نمایش داده‌ایم.
--full-history بدون بازنویسی والدین
I A B N D O P Q
M حذف شد زیرا نسبت به هر دو والد وضعیت TREESAME داشت. E, C و B همگی پیمایش شدند، اما تنها B دارای وضعیت !TREESAME بود، بنابراین بقیه ظاهر نمی‌شوند.
توجه داشته باشید که بدون بازنویسی والدین، عملاً امکان صحبت در مورد روابط والد/فرزند میان کامیت‌ها وجود ندارد، از این رو آن‌ها را به صورت گسسته نشان می‌دهیم.
--full-history با بازنویسی والدین
ادغام‌ها همیشه گنجانده می‌شوند. با این حال، فهرست والدین آن‌ها بازنویسی می‌شود: در امتداد هر والد، کامیت‌هایی را که خودشان گنجانده نشده‌اند هرس می‌کند. این به نتیجه زیر می‌انجامد:
.-A---M---N---O---P---Q / / / / / I B / D / \ / / / / `-------------'
با --full-history بدون بازنویسی در بالا مقایسه کنید. توجه داشته باشید که E هرس شد زیرا TREESAME بود، اما فهرست والدین P بازنویسی شد تا شامل والد E یعنی I باشد. همین اتفاق برای C و N, و برای X, Y و Q نیز رخ داد.
علاوه بر تنظیمات فوق، می‌توانید تغییر دهید که آیا وضعیت TREESAME بر گنجاندن تأثیر بگذارد یا خیر:
--dense
--sparse
توجه داشته باشید که بدون --full-history, این گزینه همچنان ادغام‌ها را ساده‌سازی می‌کند: اگر یکی از والدین TREESAME باشد، ما تنها همان یکی را دنبال می‌کنیم، بنابراین سمت‌های دیگر ادغام هرگز پیمایش نمی‌شوند.
--simplify-merges
سپس هر کامیت C را به جایگزین آن C' در تاریخچه نهایی بر اساس قوانین زیر ساده می‌کند:
تأثیر این کار به بهترین شکل با مقایسه آن با --full-history همراه با بازنویسی والدین نشان داده می‌شود. مثال به صورت زیر درمی‌آید:
.-A---M---N---O / / / I B D \ / / `---------'
تفاوت‌های عمده در N, P, و Q را نسبت به --full-history ملاحظه فرمایید:
حالت ساده‌سازی دیگری نیز در دسترس است:
--ancestry-path[=<commit>]
به‌عنوان یک نمونه کاربرد، تاریخچه کامیت زیر را در نظر بگیرید:
D---E-------F / \ \ B---C---G---H---I---J / \ A-------K---------------L--M
یک عبارت معمولی D..M مجموعه کامیت‌هایی را محاسبه می‌کند که نیاکان M هستند، اما مواردی را که نیاکان D می‌باشند مستثنی می‌سازد. این برای مشاهده آنچه برای تاریخچه منتهی به M از زمان D رخ داده مفید است، به این معنی که « M چه چیزی دارد که در D وجود نداشت». نتیجه در این مثال تمام کامیت‌ها خواهد بود، به جز A و B (و البته خود D).
اما هنگامی که بخواهیم بدانیم چه کامیت‌هایی در M به باگ معرفی‌شده توسط D آلوده شده‌اند و نیاز به رفع دارند، ممکن است بخواهیم تنها زیرمجموعه‌ای از D..M را مشاهده کنیم که واقعاً از نوادگان D هستند، یعنی مستثنی کردن C و K. این دقیقاً همان کاری است که گزینه --ancestry-path انجام می‌دهد. اعمال آن روی محدوده D..M به نتیجه زیر می‌انجامد:
E-------F
\ \
G---H---I---J
\
L--M
ما همچنین می‌توانیم از --ancestry-path=D به‌جای --ancestry-path استفاده کنیم که هنگام اعمال روی محدوده D..M معنای یکسانی دارد اما صریح‌تر است.
اگر در عوض به یک موضوع خاص در این محدوده و تمام کامیت‌های متأثر از آن موضوع علاقه‌مند باشیم، ممکن است تنها بخواهیم زیرمجموعه‌ای از D..M را مشاهده کنیم که آن موضوع را در مسیر نیاکان خود دارند. بنابراین، برای مثال استفاده از --ancestry-path=H D..M به نتیجه زیر می‌انجامد:
E
\
C---G---H---I---J
\
L--M
در حالی که --ancestry-path=K D..M به این نتیجه منجر می‌شود:
K---------------L--M
پیش از بحث درباره گزینه دیگر، یعنی --show-pulls, لازم است یک تاریخچه نمونه جدید بسازیم.
یک مشکل رایج که کاربران هنگام مشاهده تاریخچه ساده‌سازی‌شده با آن مواجه می‌شوند این است که کامیتی که می‌دانند فایلی را تغییر داده است به نوعی در تاریخچه ساده‌شده فایل ظاهر نمی‌شود. بیایید یک مثال جدید را نشان دهیم و بررسی کنیم که گزینه‌هایی مانند --full-history و --simplify-merges در چنین حالتی چگونه کار می‌کنند:
.-A---M-----C--N---O---P / / \ \ \/ / / I B \ R-'`-Z' / \ / \/ / \ / /\ / `---X--' `---Y--'
برای این مثال، فرض کنید I فایل file.txt را ایجاد کرد که توسط A, B, و X به روش‌های متفاوتی اصلاح شد. کامیت‌های تک‌والدی C, Z, و Y تغییری در file.txt ایجاد نمی‌کنند. کامیت ادغام M با حل تعارض ادغام برای گنجاندن هر دو تغییر از A و B ایجاد شد و بنابراین نسبت به هیچ‌کدام TREESAME نیست. اما کامیت ادغام R با نادیده گرفتن محتویات file.txt در M و گرفتن تنها محتویات file.txt در X ایجاد گردید. از این رو، R نسبت به X دارای وضعیت TREESAME است اما نسبت به M نیست. در نهایت، تفکیک طبیعی ادغام برای ایجاد N گرفتن محتویات file.txt در R است، بنابراین N نسبت به R وضعیت TREESAME دارد اما نسبت به C ندارد. کامیت‌های ادغام O و P نسبت به والدین اول خود وضعیت TREESAME دارند، اما به ترتیب نسبت به والدین دوم خود یعنی Z و Y وضعیت TREESAME ندارند.
هنگام استفاده از حالت پیش‌فرض، N و R هر دو دارای یک والد TREESAME هستند، بنابراین آن یال‌ها پیمایش شده و بقیه نادیده گرفته می‌شوند. گراف تاریخچه حاصل به صورت زیر است:
I---X
هنگام استفاده از --full-history, گیت تمام یال‌ها را پیمایش می‌کند. این کار کامیت‌های A و B و ادغام M را آشکار می‌سازد، اما کامیت‌های ادغام O و P را نیز نمایان می‌کند. با بازنویسی والدین، گراف حاصل به شکل زیر خواهد بود:
.-A---M--------N---O---P / / \ \ \/ / / I B \ R-'`--' / \ / \/ / \ / /\ / `---X--' `------'
در اینجا، کامیت‌های ادغام O و P نویز اضافی ایجاد می‌کنند، زیرا در واقع تغییری در file.txt ایجاد نکرده‌اند. آن‌ها تنها موضوعی را ادغام کرده‌اند که بر پایه نسخه قدیمی‌تری از file.txt بنا شده بود. این یک مسئله رایج در مخازنی است که از گردش کاری با مشارکت‌کنندگان موازی زیاد استفاده می‌کنند که شاخه‌های موضوعی خود را در طول یک تنه اصلی ادغام می‌نمایند: ادغام‌های نامرتبط زیادی در نتایج --full-history ظاهر می‌شوند.
هنگام استفاده از گزینه --simplify-merges, کامیت‌های O و P از نتایج ناپدید می‌شوند. دلیل آن این است که والدین دوم بازنویسی‌شده O و P از والدین اول آن‌ها قابل دسترسی هستند. آن یال‌ها حذف می‌شوند و سپس کامیت‌ها مانند کامیت‌های تک‌والدی به نظر می‌رسند که نسبت به والد خود TREESAME هستند. این اتفاق برای کامیت N نیز رخ می‌دهد و نمایی از تاریخچه به صورت زیر ایجاد می‌کند:
.-A---M--. / / \ I B R \ / / \ / / `---X--'
در این نما، ما تمام تغییرات تک‌والدی مهم از A, B, و X را می‌بینیم. همچنین ادغام با دقت حل‌شده M و ادغام نه‌چندان با دقت حل‌شده R را مشاهده می‌کنیم. این معمولاً اطلاعات کافی برای تعیین اینکه چرا کامیت‌های A و B در نمای پیش‌فرض از تاریخچه «ناپدید شدند» را فراهم می‌سازد. با این حال، چند مشکل در این رویکرد وجود دارد.
مشکل نخست کارایی است. برخلاف هر گزینه قبلی، گزینه --simplify-merges مستلزم پیمایش کل تاریخچه کامیت پیش از بازگرداندن حتی یک نتیجه است. این می‌تواند استفاده از این گزینه را برای مخازن بسیار بزرگ دشوار سازد.
مشکل دوم موضوع حسابرسی (auditing) است. هنگامی که مشارکت‌کنندگان زیادی روی یک مخزن کار می‌کنند، مهم است که کدام کامیت‌های ادغام تغییری را وارد یک شاخه مهم کرده‌اند. ادغام مشکل‌ساز R در بالا احتمالاً آن کامیت ادغامی نبوده است که برای ادغام در یک شاخه مهم استفاده شده است. در عوض، ادغام N برای ادغام R و X در شاخه مهم به کار رفته است. این کامیت ممکن است اطلاعاتی درباره اینکه چرا تغییر X جایگزین تغییرات A و B شد در پیام کامیت خود داشته باشد.
--show-pulls
هنگامی که یک کامیت ادغام توسط --show-pulls گنجانده می‌شود، با ادغام به‌گونه‌ای رفتار می‌شود که گویی تغییر را از شاخه دیگری «کشیده» (pull) است. هنگام استفاده از --show-pulls در این مثال (و بدون گزینه‌های دیگر) گراف حاصل عبارت است از:
I---X---R---N
در اینجا، کامیت‌های ادغام R و N گنجانده شده‌اند زیرا آن‌ها به ترتیب کامیت‌های X و R را به شاخه پایه وارد کردند. این ادغام‌ها دلیلی هستند که کامیت‌های A و B در تاریخچه پیش‌فرض ظاهر نمی‌شوند.
هنگامی که --show-pulls همراه با --simplify-merges استفاده شود، گراف شامل تمام اطلاعات لازم خواهد بود:
.-A---M--. N / / \ / I B R \ / / \ / / `---X--'
توجه داشته باشید از آنجا که M از R قابل دسترسی است، یال از N به M با ساده‌سازی حذف شد. با این حال، N همچنان به‌عنوان یک کامیت مهم در تاریخچه ظاهر می‌شود زیرا تغییر R را به شاخه اصلی «کشیده» است.
گزینه --simplify-by-decoration به شما امکان می‌دهد تنها نمای کلی از توپولوژی تاریخچه را با حذف کامیت‌هایی که توسط برچسب‌ها ارجاع داده نشده‌اند مشاهده کنید. کامیت‌ها در صورتی به‌عنوان !TREESAME علامت‌گذاری می‌شوند (به عبارت دیگر، پس از قوانین ساده‌سازی تاریخچه توضیح داده‌شده در بالا حفظ می‌شوند) که (۱) توسط برچسب‌ها ارجاع داده شده باشند، یا (۲) محتویات مسیرهای داده‌شده در خط فرمان را تغییر دهند. تمام کامیت‌های دیگر به‌عنوان TREESAME علامت‌گذاری می‌شوند (مشمول حذف از طریق ساده‌سازی).
ترتیب کامیت‌ها (Commit Ordering)
به‌طور پیش‌فرض، کامیت‌ها به ترتیب معکوس زمانی نمایش داده می‌شوند.
--date-order
--author-date-order
--topo-order
برای نمونه، در یک تاریخچه کامیت مانند این:
---1----2----4----7
\ \
3----5----6----8---
که در آن اعداد نشان‌دهنده ترتیب برچسب‌های زمان کامیت هستند، دستور git rev-list و دستورات مشابه همراه با --date-order کامیت‌ها را به ترتیب برچسب زمان نمایش می‌دهند: 8 7 6 5 4 3 2 1.
با --topo-order, آن‌ها به صورت 8 6 5 3 7 4 2 1 (یا 8 7 4 2 6 5 3 1) نمایش داده می‌شوند؛ برخی از کامیت‌های قدیمی‌تر قبل از کامیت‌های جدیدتر نشان داده می‌شوند تا از مخلوط شدن کامیت‌های دو مسیر توسعه موازی جلوگیری شود.
--reverse
پیمایش شیء (Object Traversal)
این گزینه‌ها بیشتر برای بسته‌بندی مخازن گیت هدف‌گذاری شده‌اند.
--no-walk[=(sorted|unsorted)]
--do-walk
خروجی (OUTPUT)
به طور پیش‌فرض، یا با --ef-action=update، این دستور در صورت موفقیت هیچ خروجی‌ای تولید نمی‌کند، زیرا مراجع مستقیماً با استفاده از یک تراکنش اتمیک به‌روزرسانی می‌شوند.
هنگام استفاده از --ef-action=print، خروجی به عنوان ورودی برای git update-ref --din قابل استفاده است. خروجی به شکل زیر خواهد بود:
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
که در آن تعداد مراجع به‌روزرسانی‌شده به آرگومان‌های ارائه‌شده و ساختار تاریخچه‌ای که بازپخش می‌شود بستگی دارد. هنگام استفاده از --dvance یا --evert، تعداد مراجع به‌روزرسانی‌شده همواره یکی است، اما برای --
در صورت بروز تداخل هیچ خروجی خطایی روی stderr وجود ندارد؛ بخش وضعیت خروج را در زیر ببینید.
وضعیت خروج (EXIT STATUS)
برای یک بازپخش موفقیت‌آمیز و بدون تداخل، وضعیت خروج 0 است. هنگامی که بازپخش با تداخل مواجه شود، وضعیت خروج 1 خواهد بود. اگر بازپخش به دلیل نوعی خطا نتواند شروع شده یا به پایان برسد، وضعیت خروج مقداری غیر از 0 یا 1 خواهد بود.
مثال‌ها (EXAMPLES)
برای بازپایه (rebase) کردن ساده شاخه mybranch بر روی target:
$ git replay --i/main..mybranch
مراجع به صورت اتمیک به‌روزرسانی می‌شوند و در صورت موفقیت هیچ خروجی‌ای تولید نمی‌شود.
برای مشاهده آنچه به‌روزرسانی خواهد شد بدون انجام به‌روزرسانی واقعی:
$ git replay --ef-action=print --i/main..mybranch
update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}
برای چری‌پیک (cherry-pick) کردن کامیت‌ها از mybranch بر روی target:
$ git replay --dvance=target origin/main..mybranch
توجه داشته باشید که دو مثال نخست دقیقاً همان کامیت‌ها را و بر روی دقیقاً همان پایه جدید بازپخش می‌کنند؛ تفاوت آن‌ها تنها در این است که مثال نخست mybranch را به‌روزرسانی می‌کند تا به کامیت‌های جدید اشاره کند و مثال دوم target را به‌روزرسانی می‌کند تا به آن‌ها اشاره نماید.
اگر پشته‌ای از شاخه‌ها داشته باشید که یکی به دیگری وابسته است و بخواهید کل مجموعه را بازپایه کنید چه باید کرد؟
$ git replay --ontained --i/main origin/main..tipbranch
هر سه شاخه (branch1، branch2 و tipbranch) به صورت اتمیک به‌روزرسانی می‌شوند.
هنگام فراخوانی git replay نیازی نیست محدوده کامیت‌ها برای بازپخش را با استفاده از نحو A..B مشخص کنید؛ هر عبارت تعیین محدوده‌ای پذیرفته می‌شود:
$ git replay --i/main ^base branch1 branch2 branch3
این دستور هم‌زمان شاخه‌های branch1، branch2 و branch3 (تمام کامیت‌هایی که پس از base دارند) را بر روی origin/main بازپایه و بازپخش می‌کند. این سه شاخه ممکن است کامیت‌های مشترکی پس از base داشته باشند، اما این امر الزامی نیست.
برای بازگردانی (revert) کامیت‌ها در یک شاخه:
$ git replay --evert=main topic~2..topic
این دستور دو کامیت آخر از topic را بازگردانی کرده و کامیت‌های بازگردانی را بر روی main ایجاد می‌کند، و main را به‌روزرسانی می‌نماید تا به نتیجه اشاره کند. این کار زمانی سودمند است که کامیت‌های topic پیش‌تر در main ادغام یا چری‌پیک شده باشند و نیاز به باطل کردن آن‌ها باشد.
نکته
برای بازگردانی یک درخواست ادغام (merge request) به طور کامل در قالب یک کامیت واحد (به جای بازگردانی کامیت‌به‌کامیت)، استفاده از git merge-tree --rge-base $TIP HEAD $BASE را در نظر بگیرید که می‌تواند از تداخل‌های ادغام غیرضروری جلوگیری کند.
برای بازپخش بر روی یک کامیت خاص و هم‌زمان به‌روزرسانی مرجعی متفاوت:
$ git replay --ach aabbcc..ddeeff
این دستور محدوده aabbcc..ddeeff را بر روی کامیت 112233 بازپخش کرده و refs/heads/mybranch را به‌روزرسانی می‌کند تا به نتیجه اشاره کند. این روش زمانی سودمند است که بخواهید از شناسه‌های هش کامیت خام به جای نام شاخه‌ها استفاده نمایید.
گیت (GIT)
بخشی از مجموعه git(1)
| 2026-06-29 | Git 2.55.0 |