git-revert -
برگرداندن
تغییرات
برخی
کامیت‌های
موجود
git revert [--[no-]edit] [-n] [-m <parent-number>] [-s] [-S[<keyid>]] <commit>...
git revert (--continue | --skip | --abort | --quit)
با دریافت
یک یا چند
کامیت
موجود،
تغییراتی
را که
وصله‌های
مربوطه
ایجاد
کرده‌اند
بازمی‌گرداند
و چند کامیت
جدید برای
ثبت این
بازگردانی
ایجاد
می‌کند. این
کار
نیازمند آن
است که درخت
کاری شما
تمیز باشد
(هیچ تغییری
نسبت به
کامیت HEAD
وجود
نداشته
باشد).
نکته:
دستور git revert
برای ثبت
کامیت‌های
جدید جهت
خنثی کردن
اثر برخی
کامیت‌های
قبلی (اغلب
فقط یک
کامیت
معیوب)
استفاده
می‌شود. اگر
می‌خواهید
تمام
تغییرات
کامیت‌نشده
در
دایرکتوری
کاری خود را
دور
بیندازید،
باید به git-reset(1)
و به‌ویژه
گزینه --hard
مراجعه
کنید. اگر
می‌خواهید
فایل‌های
خاصی را
همان‌طور
که در کامیت
دیگری
بودند
استخراج
کنید، باید
به git-restore(1) و
به‌ویژه
گزینه --source
مراجعه
کنید. هنگام
استفاده از
این
جایگزین‌ها
دقت کنید،
زیرا هر دوی
آن‌ها
تغییرات
کامیت‌نشده
در
دایرکتوری
کاری شما را
نادیده
گرفته و حذف
می‌کنند.
برای
آشنایی با
تفاوت‌های
میان این سه
دستور، بخش
"Reset, restore and revert" را در
git(1) ببینید.
<commit>...
کامیت‌هایی
که باید
تغییراتشان
برگردانده
شود. برای
فهرست
کامل‌تری
از روش‌های
نگارش نام
کامیت‌ها،
به
gitrevisions(7)
مراجعه
کنید.
مجموعه‌ای
از
کامیت‌ها
را نیز
می‌توان
مشخص کرد،
اما به‌طور
پیش‌فرض
هیچ
پیمایشی
انجام
نمی‌شود؛
به
git-rev-list(1) و
گزینه
--no-walk آن
مراجعه
کنید.
-e, --edit
با این
گزینه، git revert
به شما
امکان
می‌دهد
پیام کامیت
را پیش از
ثبت کامیتِ
بازگردانی
ویرایش
کنید. اگر
دستور را از
یک ترمینال
اجرا کنید،
این رفتار
پیش‌فرض
است.
-m parent-number, --mainline parent-number
معمولاً
نمی‌توانید
یک کامیت
ادغام (merge) را
برگردانید
زیرا مشخص
نیست کدام
شاخه ادغام
باید به
عنوان خط
اصلی (mainline) در
نظر گرفته
شود. این
گزینه
شماره والد
(شروع از ۱) خط
اصلی را
مشخص کرده و
به revert اجازه
می‌دهد تا
تغییرات را
نسبت به
والد
مشخص‌شده
خنثی کند.
برگرداندن
یک کامیت
ادغام
اعلام
می‌کند که
شما هرگز
تغییرات
درختی
واردشده
توسط آن
ادغام را
نخواهید
خواست. در
نتیجه،
ادغام‌های
بعدی تنها
تغییرات
درختی را
وارد
می‌کنند که
توسط
کامیت‌هایی
ایجاد
شده‌اند که
از نیاکان
ادغامِ
بازگردانده‌شده
قبلی
نیستند. این
ممکن است
چیزی باشد
یا نباشد که
شما
می‌خواهید.
برای
جزئیات
بیشتر،
راهنمای
revert-a-faulty-merge How-To[1] را
ببینید.
--no-edit
با این
گزینه، git revert
ویرایشگر
پیام کامیت
را باز
نخواهد
کرد.
--cleanup=<mode>
این
گزینه
تعیین
می‌کند که
پیام کامیت
پیش از
ارسال به
سازوکار
کامیت،
چگونه
پاک‌سازی
شود. برای
جزئیات
بیشتر به
git-commit(1)
مراجعه
کنید.
به‌ویژه،
اگر مقدار
<mode> برابر با
scissors باشد، در
صورت بروز
تعارض، خط
برش (قیچی) به
MERGE_MSG اضافه
می‌شود.
-n, --no-commit
معمولاً
این دستور
به‌طور
خودکار
کامیت‌هایی
با
پیام‌های
گزارش ثبت
می‌کند که
نشان
می‌دهند
کدام
کامیت‌ها
برگردانده
شده‌اند.
این فلگ
تغییرات
لازم برای
بازگرداندن
کامیت‌های
نام‌برده
را بر روی
درخت کاری و
ایندکس شما
اعمال
می‌کند،
اما
کامیت‌ها
را ثبت
نمی‌کند.
علاوه بر
این،
هنگامی که
از این
گزینه
استفاده
می‌شود،
نیازی نیست
ایندکس شما
با کامیت HEAD
مطابقت
داشته
باشد؛
عملیات
بازگردانی
نسبت به
وضعیت
ابتدایی
ایندکس شما
انجام
می‌شود.
این گزینه
هنگامی
مفید است که
می‌خواهید
اثر بیش از
یک کامیت را
به‌صورت
پشت سر هم بر
روی ایندکس
خود
بازگردانید.
-S[<keyid>], --gpg-sign[=<keyid>], --no-gpg-sign
امضای
کامیت‌ها
با GPG. آرگومان
keyid اختیاری
است و
به‌طور
پیش‌فرض از
شناسه
کامیت‌کننده
استفاده
می‌کند؛ در
صورت مشخص
شدن، باید
بدون فاصله
به گزینه
بچسبد.
گزینه --no-gpg-sign
برای لغو
متغیر
پیکربندی
commit.gpgSign و
همچنین
گزینه
پیشین --gpg-sign
مفید است.
-s, --signoff
یک خط
پایانی
Signed-off-by
به انتهای
پیام کامیت
اضافه
می‌کند.
برای
اطلاعات
بیشتر
گزینه signoff را
در
git-commit(1)
ببینید.
--strategy=<strategy>
استفاده
از
استراتژی
ادغام
داده‌شده.
تنها باید
یک‌بار
استفاده
شود. برای
جزئیات،
بخش MERGE STRATEGIES را در
git-merge(1) ببینید.
-X<option>, --strategy-option=<option>
ارسال
گزینه ویژه
استراتژی
ادغام به
استراتژی
مربوطه.
برای
جزئیات به
git-merge(1) مراجعه
کنید.
--rerere-autoupdate, --no-rerere-autoupdate
پس از
آنکه
سازوکار rerere
از یک حل
تعارض
ثبت‌شده
برای
به‌روزرسانی
فایل‌ها در
درخت کاری
استفاده
کرد، به آن
اجازه
می‌دهد تا
ایندکس را
نیز با
نتیجه حل
تعارض
به‌روز کند.
--no-rerere-autoupdate راه
خوبی است
برای بررسی
دوباره
آنچه
git-rerere(1)
انجام داده
و شناسایی
ادغام‌های
اشتباه
احتمالی،
پیش از ثبت
نتیجه در
ایندکس با
دستور
جداگانه
git-add(1).
--reference
به جای
شروع بدنه
پیام لاگ با
"This reverts
<full-object-name-of-the-commit-being-reverted>."،
با استفاده
از فرمت
"
--pretty=reference" به
کامیت
ارجاع
می‌دهد
(مقایسه
کنید با
git-log(1)).
متغیر
پیکربندی
revert.reference را
می‌توان
برای
فعال‌سازی
این گزینه
به‌طور
پیش‌فرض
استفاده
کرد.
--continue
عملیات
در حال
انجام را با
استفاده از
اطلاعات
موجود در
.git/sequencer ادامه
می‌دهد.
می‌توان پس
از حل
تعارض‌ها
در یک cherry-pick یا revert
ناموفق، از
آن برای
ادامه کار
استفاده
کرد.
--skip
از کامیت
فعلی
صرف‌نظر
کرده و
توالی
باقی‌مانده
را ادامه
می‌دهد.
--quit
عملیات
در حال
انجام فعلی
را فراموش
می‌کند.
می‌توان
برای
پاک‌سازی
وضعیت
توالی‌ساز
(sequencer) پس از یک cherry-pick
یا revert ناموفق
از آن
استفاده
کرد.
--abort
عملیات
را لغو کرده
و به وضعیت
پیش از شروع
توالی
بازمی‌گردد.
git revert HEAD~3
تغییرات
مشخص‌شده
توسط
چهارمین
کامیت
مانده به
آخر در HEAD را
برمی‌گرداند
و یک کامیت
جدید با
تغییرات
بازگردانده‌شده
ایجاد
می‌کند.
git revert -n
master~5..master~2
تغییرات
ایجادشده
توسط
کامیت‌های
پنجمین
کامیت
مانده به
آخر در master
(شامل آن) تا
سومین
کامیت
مانده به
آخر در master
(شامل آن) را
برمی‌گرداند،
اما هیچ
کمیتی با
تغییرات
بازگردانده‌شده
ایجاد
نمی‌کند.
بازگردانی
تنها درخت
کاری و
ایندکس را
اصلاح
می‌کند.
اگرچه git
به‌طور
خودکار یک
پیام کامیت
پایه‌ای
می‌سازد،
اما
اکیداً
توصیه
می‌شود
دلیل
بازگردانی
کامیت اصلی
را توضیح
دهید. علاوه
بر این،
بازگردانی‌های
مکررِ
کامیت‌های
revert منجر به
خطوط عنوان
به طور
فزاینده‌ای
دست‌وپاگیر
می‌شود،
مانند Reapply "Reapply
"<original-subject>"".
لطفاً برای
کوتاه‌تر و
متمایزتر
شدن،
بازنویسی
این عناوین
را مد نظر
قرار دهید.
تمام
موارد زیر
در این بخش
به‌طور
گزینشی از
مستندات
git-config(1)
گنجانده
شده‌اند.
محتوا همان
چیزی است که
در آنجا
یافت
می‌شود:
revert.reference
تنظیم
این متغیر
روی true باعث
می‌شود git revert
طوری رفتار
کند که گویی
گزینه --reference
داده شده
است.
- 1.
- راهنمای
کاربردی
revert-a-faulty-merge
file:///usr/share/doc/git-doc/howto/revert-a-faulty-merge.html
