کنترل نسخه با Git به طور پیش فرض در کمربند ابزار هر توسعه دهنده مدرن تبدیل شده است. دستوراتی مانند commit، push، و pull آن را به حافظه عضلانی انگشتان خود تبدیل کرده ایم. اما تعداد نسبتاً کمی از توسعه دهندگان در مورد ویژگی های “پیشرفته تر” در Git می دانند – و اینکه چقدر می توانند فوق العاده با ارزش باشند! در این مقاله ، ما قصد داریم “rebase interact” ، یکی از قدرتمندترین ابزارهای Git را بررسی کنیم.
به طور خلاصه و بدون اغراق ، rebase تعاملی با ایجاد یک سابقه متعهد تمیز و با ساختار مناسب در پروژه ها ، می تواند به شما در تبدیل شدن به یک توسعه دهنده بهتر کمک کند.
چرا یک سابقه متعهد با ساختار خوب مهم است؟ فقط عکس این را تصور کنید: یک تاریخچه متعهد که به سختی خوانده می شود ، جایی که شما نمی دانید از همکاران خود چه خبر است در حقیقت با تغییرات اخیر آنها هرچه بیشتر “گوشه های تاریک” مانند پروژه شروع به ظهور می کنند ، و شما فقط قسمت های کوچکی را که روی خود کار کرده اید درک می کنید.
این را با یک سابقه متعهد تمیز و دارای ساختار خوب مقایسه کنید: به ساختن کد برنامه یک پروژه کمک می کند خواندنی تر و فهم راحت تر. این یک ماده اساسی برای یک پروژه سالم و طولانی مدت است!
آنچه Rebase Interactive می تواند برای شما انجام دهد
Interactive Rebase به شما کمک می کند سابقه تعهد خود را بهینه و تمیز کنید. این موارد مختلف استفاده را پوشش می دهد ، برخی از آنها به شما اجازه می دهد موارد زیر را داشته باشید:
- پیام متعهد قدیمی را ویرایش کنید
- تعهد را حذف کنید
- اسکواش / ترکیب چندین تعهد
- مرتب کردن مجدد مرتکب می شود
- مرتکب تعهدات قدیمی
- تعهدات قدیمی را برای ویرایش تقسیم / دوباره باز کنید
چه زمانی باید از Rebase Interactive استفاده کرد (و چه زمانی نباید!)
مانند چند ابزار دیگر Git ، پایگاه تعاملی “تاریخ را بازنویسی می کند”. این بدان معنی است که ، وقتی یک سری تعهدات را با استفاده از rebase تعاملی دستکاری کنید ، این قسمت از تاریخچه تعهد شما خواهد بود بازنویسی شده: هش های انجام شده SHA-1 تغییر کرده است. اصطلاحاً آنها کاملاً جدید هستند.
این واقعیت یک قانون ساده اما مهم را می طلبد که براساس آن لازم است: در تعهداتی که قبلاً با همکاران خود در یک مخزن از راه دور به اشتراک گذاشته اید ، از پایگاه تعاملی (یا ابزارهای دیگری که تاریخ را بازنویسی می کنند) استفاده نکنید. در عوض ، قبل از ادغام آنها در شاخه های تیمی ، از آن برای پاکسازی تعهدات محلی خود – مانند یکی از شاخه های ویژگی خود – استفاده کنید.
مکانیسم اساسی یک عملیات پایگاه تعاملی
اگرچه چیزهای مختلفی وجود دارد که می توان از rebase تعاملی استفاده کرد ، گردش کار اساسی همیشه یکسان است. هنگامی که این مکانیسم اساسی را کاملاً درک کردید ، پایه تعاملی هوای “رمز و راز پیچیده” خود را از دست می دهد و به یک مورد با ارزش و قابل دسترسی در کمربند ابزار شما تبدیل می شود.
مرحله 1: جلسه را از کجا باید شروع کنید؟
اولین سوالی که باید به آن پاسخ دهید این است: “من می خواهم کدام قسمت از تاریخ ارتکاب خود را دستکاری کنم؟” این به شما می گوید که جلسه تعویض تعاملی خود را از کجا باید شروع کنید. بیایید یک مثال عملی بزنیم و بگوییم که ما می خواهیم یک پیام متعهد قدیمی را ویرایش کنیم (این همان کاری است که در یک لحظه در عمل انجام خواهیم داد).
وضعیت شروع ما در زیر نشان داده شده است ، جایی که ما در حال ویرایش یک پیام متعهد قدیمی از طریق پایگاه تعاملی هستیم.
برای اینکه بتوانید پیام متعهد را در تغییر دهید C2، ما باید جلسه تعامل مجدد خود را با تعهد والدین خود شروع کنیم (یا حتی اگر قبل از آن ، اگر بخواهید). در این مورد مثال ، ما استفاده خواهیم کرد C1 به عنوان نقطه شروع جلسه تعامل مجدد ما.
مرحله 2: شروع جلسه واقعی!
شروع جلسه واقعی بسیار ساده است:
$ git rebase -i HEAD~3
ما از git rebase فرمان با -i flag (برای نشان دادن اینکه ما واقعاً می خواهیم “تعاملی” باشد) و تعهد پایه را (که در اولین قدم بالا به آن رسیدیم) ارائه دهید. در این مثال ، من استفاده کردم HEAD~3 برای تعیین تعهدی که “3 پشت تعهد HEAD” است. همچنین می توانم یک هش خاص SHA-1 تهیه کنم.
مرحله 3: به Git بگویید چه کاری می خواهید انجام دهید
پس از شروع جلسه تعاملی rebase ، یک پنجره ویرایشگر به شما ارائه می شود که در آن Git مجموعه ای از تعهدات را لیست می کند – از آخرین متعهد ، تا تمام مواردی (که شامل آنها نیست) به عنوان تعهد پایه در مرحله 1.
در این مرحله باید دو نکته مهم را بخاطر بسپارید:
- کمیته ها به ترتیب معکوس لیست شده اند! جدیدترین تعهدی که انتظار داریم در آن ظاهر شود بالا، در نمایش داده خواهد شد پایین از لیست نگران نباشید: مخزن Git شما به عنوان کمانچه مناسب است! 🥳 بخاطر بسپارید که ما در حال انجام یک عملیات باز تعاملی هستیم و این به Git نیاز دارد تا در پایان عملیات تعهدات خود را از قدیمی ترین به جدیدترین مورد را اعمال کند.
- تغییرات واقعی خود را در این پنجره ویرایشگر ایجاد نکنید! اگرچه ممکن است خارش داشته باشید که به سادگی پیش بروید و پیام متعهد را در این پنجره ویرایشگر تغییر دهید (به هر حال ، این همان چیزی است که ما واقعاً می خواهیم انجام دهیم …) ، شما باید صبر و حوصله نشان دهید. در اینجا ، ما فقط می خواهیم به Git بگوییم چی ما می خواهیم انجام دهیم – اما تغییر واقعی را ایجاد نکنیم. من این نکته را به زودی در عمل نشان خواهم داد!
با این بررسی اجمالی نظری ، اجازه دهید با هم به برخی موارد عملی بپردازیم!
در حال ویرایش یک پیام قدیمی
یکی از موارد بسیار محبوب استفاده مجدد از تعاملی این است که می توانید پس از واقعیت یک پیام مرتکب قدیمی را ویرایش کنید. شاید از آن آگاه باشید git commit --amend همچنین به شما امکان می دهد پیام متعهد را تغییر دهید – اما فقط درصورت ارسال پیام خیلی جدیدترین مرتکب شدن. برای هر تعهدی بالاتر از آن ، ما باید از rebase تعاملی استفاده کنیم!
بیایید نگاهی بیندازیم به یک سناریوی مشخص. در زیر تصویری از پیام مرتکب بد آمده است که باید اصلاح شود.
توجه: برای یک نمای بهتر و تجسم واضح تر ، من از مشتری دسک تاپ Tower Git در برخی از عکسهای صفحه من برای پیگیری در این آموزش نیازی به Tower ندارید.
برای مثال ما ، بگذارید بگوییم که ما می خواهیم پیام متعهد را با عنوان “بهینه سازی ساختار نشانه گذاری در فهرست …” ویرایش کنیم
اولین قدم ما تعیین تعهد پایه برای شروع این جلسه تعامل مجدد است. از آنجا که ما مجبوریم (حداقل) به والدین تعهد “سیب بد” خود برگردیم ، جلسه خود را در HEAD ~ 3 شروع می کنیم (سه مرتبه پشت تعهد HEAD ، که یکی با عنوان “تغییر عناوین …” ):
$ git rebase -i HEAD~3
درست پس از اجرای این دستور ، ویرایشگر مورد علاقه شما لیست تعهداتی را که انتخاب کرده اید باز می کند و ارائه می دهد (با ارائه تعهد پایه).
برای یادآوری: اگرچه ممکن است برای انجام این کار وسوسه شوید ، ما این کار را می کنیم نه پیام متعهد را در اینجا تغییر دهید. فقط ما علامت گذاری کردن خط مربوطه با “کلمه کلیدی اقدام”. در مورد ما ، ما می خواهیم reword تعهد (که بدان معنی است که ما می خواهیم پیام تعهد را تغییر دهیم ، اما بقیه تعهد را همانطور که هست بگذاریم).
کاملاً عملی ، تمام کلمات کلیدی عملی موجود در پایین این پنجره ثبت شده اند – بنابراین نیازی به یادآوری چیزی نیست!
هنگامی که استاندارد را جایگزین کردید pick کلمه کلیدی (که به معنای “انجام تعهد همانطور که هست”) با کلمه کلیدی اقدام مورد نظر خود ، می توانید پنجره را ذخیره کرده و ببندید.
پس از انجام این کار ، یک پنجره ویرایشگر جدید باز می شود که شامل پیام فعلی متعهد است. سرانجام ، ما مجاز به انجام آنچه ما در وهله اول انجام می دهیم هستیم: پیام این مرتکب قدیمی را ویرایش کنید!
پس از ایجاد تغییر و سپس ذخیره و بستن پنجره ویرایشگر ، جلسه تعامل مجدد به پایان رسید – و پیام تعهد ما به روز می شود! 🎉
حذف تعهد ناخواسته
Rease Interactive همچنین به شما امکان می دهد حذف یک تعهد قدیمی از تاریخ خود که دیگر به آن نیازی ندارید (یا نمی خواهید). فقط تصور کنید که به طور تصادفی رمز عبور شخصی را در تعهد اخیر وارد کرده اید: اطلاعات حساس مانند این ، در اکثر موارد ، نباید در یک کد کد موجود باشد.
همچنین به یاد داشته باشید که با حذف ساده اطلاعات و مرتکب شدن مجدد ، واقعاً مشکل شما حل نمی شود: این بدان معناست که رمزعبور همچنان به عنوان تعهد قدیمی شما در مخزن ذخیره می شود. آنچه واقعاً می خواهید تمیز و کامل است حذف این قطعه داده از مخزن کلا!
بیایید با تعیین تعهد پایه برای جلسه تعاملی rebase شروع کنیم. از آنجایی که حداقل باید از والدین تعهد بد شروع کنیم ، ما از تعهد “Optimize markup ساختار…” به عنوان مبنای خود استفاده می کنیم:
$ git rebase -i 6bcf266b
توجه داشته باشید که ، این بار ، من از یک هش بتن SHA-1 استفاده کرده ام git rebase -i فرمان دادن به جای هش مرتکب ، البته ، من می توانستم استفاده کنم HEAD~2 برای رسیدگی به آن تعهد.
پس از اجرای این دستور ، دوباره لیستی از تعهدات به ما ارائه می شود.
این بار ، ما از drop کلید واژه اقدام برای خلاص شدن از شر تعهد ناخواسته. متناوباً ، در این حالت خاص ، می توانیم به راحتی کل خط را از ویرایشگر حذف کنیم. اگر در هنگام ذخیره و بستن پنجره دیگر یک خط (نشان دهنده یک تعهد) وجود نداشته باشد ، Git تعهد مربوطه را حذف می کند.
اگر بخواهید این کار را انجام دهید ، پس از ذخیره و بستن پنجره ویرایشگر ، متعهد از تاریخچه مخزن شما حذف می شود!
ترکیب چندین تعهد در یک
مورد استفاده دیگر برای rebase تعاملی ، زمانی است که شما می خواهید ترکیب کردن چندین جداگانه به یک واحد متعهد می شوند. قبل از اینکه به داخل شیرجه برویم چگونه این کار می کند ، بیایید چند لحظه راجع به آن صحبت کنیم چه زمانی یا چرا این می تواند ارزشمند باشد.
به طور کلی ، “بزرگتر کردن” تعهدات (با ترکیب چند در یک) یک امر مهم است نه یک استراتژی خوب در بیشتر موارد قاعده کلی این است که تعهدات را تا حد ممکن کوچک نگه دارید ، زیرا “کوچک” به معنای “آسان تر برای خواندن و درک” است. اما شرایطی وجود دارد که با این وجود این می تواند منطقی باشد. در اینجا دو مثال آورده شده است:
- تصور کنید که در انجام یک مرتکب قدیمی متوجه مشکلی شده اید. پس از آن ممکن است پیش بروید و تولید کنید جدید متعهدی که مشکل را برطرف می کند. در چنین شرایطی ، توانایی ترکیب این تعهدات به یک معنا کاملاً منطقی است: متعهد جدیدتر ، فقط یک “Band-Aid” برای رفع مشکلی بود که نباید در ابتدا وجود داشته باشد محل. با ترکیب این تعهدات ، به نظر می رسد از ابتدا مشکل خاصی وجود نداشته است!
- مثال دیگر این است که متوجه می شوید کمی کارها را درست کرده اید هم دانه ای. ساخت تعهدات کوچک همه خوب و خوب است ، اما پر کردن تاریخچه تعهدات خود با تعداد زیادی بی مورد کوچک است تعهدات به معنای پرتاب بیش از حد علامت است.
منطق در هر دو مثال یکسان است: با ترکیب دو تعهد (یا چند) که در وهله اول باید یک امر واحد باشند ، شما یک تاریخچه مرتکب تمیزتر و خواناتر را تولید می کنید!
بیایید با هم یک مثال عملی را مرور کنیم و وضعیت تصویر زیر را به عنوان وضعیت شروع خود در نظر بگیریم.
بیایید بگوییم که از نظر معنایی منطقی است که این دو تعهد واحد باشند. با استفاده از squash ابزار rebase تعاملی ، ما واقعاً می توانیم آنها را ترکیب کنیم:
$ git rebase -i HEAD~3
در حال حاضر ، شما قبلاً به اتفاقات بعدی عادت کرده اید: یک پنجره ویرایشگر با لیستی از تعهدات باز می شود.
من قبلاً اشاره کردم که ما قصد داریم از squash کلمه کلیدی اقدام در این مورد یک چیز مهم در مورد چگونگی دانستن وجود دارد squash آثار: خطی که با کلمه کلیدی مشخص می کنید با خطی که در بالا قرار دارد ترکیب خواهد شد! این توضیح می دهد که چرا من خط 2 را با علامت گذاری کردم squash کلمه کلیدی در مثال ما
پس از ذخیره و بستن این پنجره ، یک پنجره جدید باز می شود. این بدان دلیل است که ، ما با ترکیب چندین تعهد ، ما در حال ایجاد یک تعهد جدید هستیم. و این یکی نیز مانند سایر تعهدات به پیام متعهد نیاز دارد!
آنچه در تصویر بالا مشاهده می کنید همان چیزی است که Git برای ما آماده کرده است: پیام های متعهد مربوط به تعهدات اصلی مربوطه را همراه با برخی نظرات ترکیب کرده است. شما آزادید پیام های قدیمی را حذف کنید و تازه شروع کنید – یا آنها را نگه دارید و اطلاعات بیشتری اضافه کنید.
پس از ذخیره و بستن این پنجره ویرایشگر ، می توانیم با افتخار بیان کنیم: آنچه در گذشته دو کمیت جداگانه بود ، اکنون یکی است!
مهار قدرت Rebase تعاملی
امیدوارم موافقت کنید که ابزارهای تعاملی rebase Git می توانند بسیار ارزشمند باشند! به عنوان توسعه دهندگان ، برای ما مهم است که برای یک تاریخچه تعهد پاک و روشن تلاش کنیم. این یک ماده مهم در سالم نگه داشتن یک کد کد است و درک آن آسان است (بعد از گذشت مدتی هم برای هم تیمی هایتان و هم برای خودتان).
اگر می خواهید بیشتر بیاموزید ، من بسیار توصیه می کنم “جعبه کمک های اولیه برای Git” این یک مجموعه (رایگان) از فیلم های کوتاه است که به شما نشان می دهد چگونه در Git پاک سازی و خنثی سازی اشتباهات را انجام دهید.
خوش بگذره!
