من در کامیت کردن یک اشتباهی را مرتکب شدم، حال چگونه آن را برطرف کنم؟
کامیت‌های من بهم ریخته هستند، چگونه آن‌ها را مرتب بکنم؟
اگر تا به حال شده که با چنین سوالاتی برخورد بکنید و بخواهید آن‌ها را رفع نمایید، بدانید که این مطلب برای شما نوشته شده است. در این مطلب قصد داریم به چند نکته و سوال در دنیای گیت بپردازیم که برای رفع کردن آن‌ها شاید نیاز باشد یکسری از تکنیک‌ها را بدانید. پیش به سوی حرفه‌ای شدن در دنیای گیت!
اگر در ارتباط با گیت آشنایی ندارید و می‌خواهید درک خوبی از آن را پیدا کنید، به شما پیشنهاد می‌کنم که دوره آموزشی رایگان «گیت و گیت هاب» را در وبسایت راکت دنبال بکنید.
در ادامه ما با یکسری سناریو و همچنین راه‌حل آن‌ها آشنا خواهیم شد.
من در کامیت کردن اشتباهی را مرتکب شدم، چکاری باید انجام دهم؟
سناریو شماره ۱:
بیایید تصور بکنیم که شما یکسری فایل را کامیت کرده‌اید و بعدا متوجه شده‌اید که پیغام مربوط به کامیت آنچنان باید و شاید واضح نیست. حال شما باید پیامی که برای کامیت انتخاب کرده‌اید را تغییر بدهید. برای انجام چنین کاری می‌توانید از دستور زیر استفاده بکنید:
git commit --amend -m “New commit message”
سناریو شماره ۲:
بیایید تصور کنیم که قصد دارید ۶ فایل را کامیت بکنید، اما در پایان شما تنها ۵ فایل را کامیت کرده‌اید و یک مورد را فراموش کرده‌اید. ممکن است که بخواهید یک کامیت جدید ایجاد بکنید و فایل ششم را در آن کامیت وارد نمایید.
به نظر نمی‌آید که مشکل منطقی وجود داشته باشد اما برای داشتن یک تاریخچه مرتب از کامیت‌ها چنین رویکردی نمی‌تواند به خوبی عمل بکند. بهتر است که فایل آخر را به کامیت جدیدی که کرده‌اید اضافه بکنید. برای اینکار می‌توانید به صورت زیر عمل نمایید:
git add file6
git commit --amend -–no-edit
آرگومان --no-edit به این منظور قرار گرفته که تغییری در پیام کامیت قبلی ایجاد نشود.
سناریو شماره ۳:
در هر جایی که شما یک کامیت را در گیت اجرا می‌کنید، کامیت شما یک نام نویسنده و یک ایمیل آدرس دارد. اساسا در ابتدای کار کردن با گیت شما مقدار مربوط به نام نویسنده و ایمیل آدرس را وارد می‌کنید. بنابراین با انجام چنین کاری به صورتی Global شما دیگر نیازی به نگرانی در ارتباط با نوشتن این اطلاعات در هر کامیت به صورت جداگانه ندارید.
اما شاید شما بخواهید که برای یک پروژه منحصر به فرد از اطلاعات متفاوت‌تری استفاده بکنید. برای چنین کاری نیاز است که در روند پروژه، دستور زیر را برای کانفیگ کردن گیت وارد کنید:
git config user.email “your email id”
حال بیایید حالتی را تصور بکنید که در آن شما اولین کامیت‌تان را انجام داده‌اید اما به صورت اشتباه یادتان رفته که نام نویسنده یک کامیت را وارد نمایید. برای اینکار نیاز است که نام نویسنده را براساس ایمیل وی تغییر دهید. برای اینکار دوباره به شکل زیر سراغ دستور Amend می‌رویم:
git commit --amend --author "Author Name "
نکته: بهتر است از دستور amend در پروژه‌های لوکال خود استفاده بکنید، زیرا ممکن است در حالت ریموت با مشکلات و سردرگمی‌های مختلفی مواجه شوید.
تاریخچه کامیت‌های من نامرتب است، چگونه آن را مرتب کنم؟
بیایید تصور کنیم که شما روی یک قطعه کد مشغول کار کردن هستید. شما می‌دانید که برای کامل کردن این پروژه تقریبا به ۱۰ روز زمان نیاز دارید. در طی این ۱۰ روز نیز توسعه دهندگان دیگری روی کدها در یک مخزن ریموت، کامیت می‌کنند.
همیشه باید در نظر داشته باشید که بروزرسانی کردن مخازن محلی با مخازن ریموت کار خوبی است و باید به صورت مرتب انجام شود. این کار باعث می‌شود که با زیاد شدن درخواست‌های pull مشکل Merge Conflict کمتری داشته باشید.
هر وقت که شما از مخازن ریموت کدهایی را به سمت مخازن محلی pull می‌کنید، یک کامیت ادغام شده جدید نیز در مخزن محلی‌تان ایجاد می‌شود. این بدان معناست که کامیت‌های مخزن محلی شما قرار است تاریخچه بسیار نامرتبی داشته باشد.
چگونه تاریخچه کامیت‌ها را تمیزتر بکنیم؟
اینجا جایی‌ست که rebase برای نجات ما وارد کار می‌شود.
Rebase چیست؟
بیایید در یک مثال با این موضوع بهتر آشنا شویم:
- برنچ Release شامل سه کامیت است: Rcommit1، Rcommit2 و Rcommit3.
- حال شما یک برنچ جدید با نام Feature را براساس برنچ Release درست می‌کنید.
- این برنچ خود شامل دو کامیت با عناوین Fcommit1 و Fcommit2 است.
- هدف شما در اینجا این است که کامیت‌هایی را از برنچ Release بگیرید و در برنچ Feature قرار دهید.
- برای اینکار شما نیاز دارید که از Rebase استفاده بکنید.
- برای اینکار می‌توانم به شیوه زیر از دستور rebase استفاده بکنم:
git checkout feature
git rebase release
Rebase کردن
در حالیکه عملیات Rebase کردن انجام می‌شود، شما باید مطمئن باشید که برنچ feature تمام کدهای مربوط به برنچ release را دریافت می‌کند.
Rebase سعی دارد تا هر کامیت را اضافه بکند و بعد از آن Conflictها را بررسی نماید.
می‌شود از طریق چارت زیر دقیقا متوجه شد که کار rebase به چه شکل است:
قدم ۱
- لحظه‌ای که شما دستور بالا را اجرا می‌کنید، برنچ Feature به head برنچ release اشاره می‌کند.
- حال برنچ Feature سه کامیت را در خود دارد: Rcommit1، Rcommit2 و Rcommit3
- شاید تعجب بکنید که چه بلایی سر Fcommit1 و Fcommit2 آمده است.
- کامیت‌ها هنوز آنجا هستند اما در قدم‌های پایین استفاده می‌شوند.
قدم ۲
- حال گیت سعی دارد تا Fcommit1 را به برنچ feature اضافه بکند.
- اگر هیچ Conflictی پیش نیاید Fcommit1 با موفقیت بعد از Rcommit3 اضافه می‌شود.
- اگر Conflict به وجود بیاید گیت متوجه آن می‌شود و بعد از آن نیاز هست که آن را به صورت دستی حل کنید. بعد از حل این موضوع می‌توانید روند rebasing را ادامه دهید:
git checkout feature
git rebase release
قدم ۳
- بعد از آنکه Fcommit1 اضافه شد، گیت سعی می‌کند تا Fcommit2 را نیز اضافه کند.
- قدم‌های بعدی شبیه به قدم ۲ خواهند بود.
نکات مهم
- هر دو دستور Merge و Rebase در دنیای گیت کاربردی هستند. هیچکدام بهتر از دیگری نیست.
- در حالت Merge کردن شما یک کامیت Merge را در اختیار دارید اما در حالت rebase چیزی به عنوان کامیت اضافه در اختیار ندارید.
- بهترین رویکرد برای استفاده از این دستورات، درک کردن زمان لازم برای استفاده از آن‌هاست. برای مثال بهتر است که از Rebase در زمانی استفاده شود که مخزن محلی گیت شما با آخرین داده‌های مخزن ریموت بروزرسانی شده باشد. از merge نیز بهتر است زمانی استفاده کنید که با درخواست‌های pullی طرف هستید که قرار است در آن دو برنچ ادغام شود.
- استفاده کردن از rebase معمولا باعث می‌شود که تاریخچه کامیت مرتب‌تری داشته باشید اما این موضوع همیشگی نیست.
در پایان
تبریک می‌گویم، حال شما یک متخصص در حوزه گیت و کار با با دستورات amend و rebase هستید. هر دو این دستورات واقعا می‌توانند نقش مفیدی داشته باشند و به خوبی برای شما کار بکنند.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید