یک تغییر CSS همراه با اصلاح داده و ویرایش مستندات در یک commit بزرگ ثبت شده است. حالا تیم فقط اصلاح CSS را برای نسخه جاری می‌خواهد. مسئله از حفظ نکردن مرز تغییرها شروع شده، نه از ندانستن یک فرمان پیچیده. Git ابزارهایی برای انتقال، بازنویسی و پیدا کردن علت تغییر فراهم می‌کند؛ استفاده مناسب از آن‌ها به شناخت تاریخچه و رابطه کار افراد وابسته است.
مهارت Git را نباید معیار ساده تقسیم توسعه‌دهنده به تازه‌کار و ارشد دانست. فرد باید بتواند وضعیت مخزن را بفهمد، تغییر را قابل مرور نگه دارد و اثر فرمان را پیش‌بینی کند. Rebase همیشه بهتر از merge نیست و تاریخچه خطی همیشه معنای روشن‌تری ندارد. قرارداد تیم، شاخه‌های مشترک و نیاز پیگیری تصمیم‌ها در انتخاب روش اثر دارند.
پیش از تغییر، وضعیت را بخوانید
git status --short نمای کوتاهی از فایل‌های تغییرکرده می‌دهد. git diff تغییرهای ثبت‌نشده در index و git diff --cached بخش staged را نشان می‌دهد. این دو مجموعه ممکن است متفاوت باشند. پیش از commit، هر دو را با هدف کار مقایسه کنید. فایل تولیدشده، تغییر فرمت گسترده یا تنظیم محلی ممکن است به‌اشتباه وارد همان change شود و مرور را دشوار کند.
برای تاریخچه، git log --oneline --decorate --graph تصویر خلاصه‌ای از رابطه commitها می‌دهد. نام شاخه، HEAD و نقطه مشترک با مقصد باید معلوم باشد. پیش از عملیات تاریخچه، داده تغییرکرده و وضعیت عملیات نیمه‌تمام را تشخیص دهید. اگر conflict وجود دارد، شروع فرمان تازه بدون فهم وضعیت می‌تواند کار را پیچیده‌تر کند. خروجی Git درباره مرحله جاری را بخوانید و تصمیم را بر همان وضعیت بگیرید.
Commit مرز تغییر قابل توضیح است
یک commit بهتر است مشکلی مشخص را حل کند و در مرور، علت آن روشن باشد. جدا کردن تغییر فرمت از اصلاح رفتار، پیدا کردن regression را آسان‌تر می‌کند. با git add -p می‌توان بخش‌های یک فایل را جدا stage کرد، اما هر بخش باید به تنهایی قرارداد منطقی داشته باشد. شکستن تغییر به چند تکه وابسته و نامفهوم لزوماً تاریخچه بهتری نمی‌سازد.
پیام commit باید بگوید چه مسئله‌ای تغییر کرده است. نام‌هایی مانند «fix» یا «update» بدون زمینه بعداً کمک کمی می‌کنند. Conventional Commits یک قرارداد ممکن برای ابزار و تیم است، نه شرط درستی همه مخزن‌ها. اگر پروژه از آن استفاده می‌کند، نوع و scope را با تغییر واقعی هماهنگ کنید. گزارش مبالغه‌آمیز یا عنوانی که فقط بخشی از تغییر را می‌گوید، پیگیری بعدی را سخت می‌کند.
Rebase رابطه والدها را عوض می‌کند
مستندات rebase نحوه بازاعمال commitها را توضیح می‌دهد. وقتی commit روی پایه تازه بازساخته می‌شود، شناسه آن تغییر می‌کند. این موضوع فقط مرتب شدن نمایش نیست؛ تاریخچه جدید ساخته می‌شود. روی شاخه‌ای که افراد دیگر از آن ادامه داده‌اند، این تغییر نیاز به هماهنگی دارد. برای کار محلی منتشرنشده، شرایط معمولاً ساده‌تر است ولی باز هم پایه و محدوده باید معلوم باشند.
در rebase تعاملی، انتخاب pick، squash یا edit باید هدف مشخص داشته باشد. squash می‌تواند تغییرهای خرد یک کار را جمع کند، اما نباید چند مسئله مستقل را بی‌دلیل یکی کند. اگر conflict رخ داد، نتیجه فایل‌ها را بر اساس رفتار نهایی حل کنید، سپس مرحله را ادامه دهید. حذف علامت‌های conflict بدون فهم دو تغییر، مسئله را حل نمی‌کند. مسیر abort برای کنار گذاشتن عملیات جاری وجود دارد و باید با وضعیت همان عملیات استفاده شود.
Merge می‌تواند سابقه همکاری را حفظ کند
در برخی جریان‌ها، merge commit نشان می‌دهد یک شاخه چگونه وارد تاریخچه شده است. این رابطه برای پیگیری همکاری می‌تواند مفید باشد. تاریخچه خطی نیز در بعضی تیم‌ها مرور را ساده‌تر می‌کند. انتخاب باید قرارداد یکسان داشته باشد تا افراد از اثر pull یا ادغام غافلگیر نشوند. یک روش را بدون توجه به نیاز تیم به عنوان «حرفه‌ای‌تر» معرفی نکنید.
پس از حل conflict، فقط build شدن ظاهری را معیار نگذارید؛ ارتباط متن، CSS و markup باید با هدف تغییر هماهنگ باشد. در فرانت‌اند، دو شاخه ممکن است هر دو classها را تغییر داده باشند و ترکیب نادرست همچنان syntax معتبر داشته باشد. مرور diff نهایی و توضیح رفتار لازم است. قرارداد ساختار کارت نمونه‌ای است که اختلاف CSS و HTML می‌تواند بدون خطای ساده پنهان بماند.
Cherry-pick به وابستگی تغییر حساس است
مرجع cherry-pick اعمال تغییر یک commit روی شاخه جاری را توضیح می‌دهد. انتقال اصلاح کوچک می‌تواند مفید باشد، اما commit ممکن است به تغییر قبلی وابسته باشد. قبل از انتقال، فایل‌ها و قراردادهایی را که استفاده می‌کند بررسی کنید. حل شدن conflict یا نبودن آن ثابت نمی‌کند تغییر در شاخه مقصد رفتار درستی دارد.
برای اصلاحی که میان شاخه‌ها منتقل می‌شود، منشأ را در قرارداد تیم حفظ کنید. پیام و اشاره به commit اصلی می‌تواند پیگیری را کمک کند. اگر تغییر در مقصد باید متفاوت باشد، آن تفاوت را در توضیح نهایی بیان کنید. Cherry-pick جای شناخت نسخه مقصد را نمی‌گیرد. در وابستگی‌های JavaScript، API تازه ممکن است در شاخه قدیمی وجود نداشته باشد؛ راهنمای سازگاری قابلیت زبان این مرز را توضیح می‌دهد.
Stash فضای موقت است
مستندات stash رفتار ذخیره تغییرهای موقت و گزینه‌های پوشش فایل‌ها را بیان می‌کند. فایل untracked یا ignored در حالت عادی همان قرارداد فایل tracked را ندارد. قبل از اعتماد به stash، معلوم کنید چه چیزهایی در آن قرار می‌گیرند. نام واضح برای مورد ذخیره‌شده کمک می‌کند بعداً تشخیص دهید به کدام کار مربوط بوده است.
apply و pop نیز نتیجه یکسانی از نظر نگهداری مورد ذخیره‌شده ندارند. در بازگرداندن، conflict ممکن است رخ دهد و باید وضعیت بعدی خوانده شود. فهرست stash محل نگهداری بلندمدت کار نیست؛ commit یا شاخه‌ای با هدف روشن برای ادامه طولانی قابل پیگیری‌تر است. اطلاعات محرمانه را هم صرفاً به دلیل موقت بودن در Git قرار ندهید؛ ناپدید شدن آن از working tree به معنی محو شدن از تاریخچه نیست.
Worktree برای کار همزمان
گاهی لازم است یک اصلاح فوری را کنار کار جاری بررسی کنید. Worktree امکان checkout جدا برای همان مخزن می‌دهد و می‌تواند نیاز به جابه‌جایی مکرر فایل‌ها را کم کند. مسیرها، شاخه و وضعیت هر checkout باید روشن بمانند. وابستگی‌های نصب‌شده یا تنظیم‌های محلی ممکن است بین آن‌ها خودکار مشترک نباشند. این ابزار هم به قرارداد نگهداری و پایان کار نیاز دارد.
اگر چند نفر یا ابزار در یک workspace کار می‌کنند، فایل‌های مشترک و مرز مسئولیت را مشخص کنید. عملیات تغییر شاخه در محل کار دیگری می‌تواند ادامه کار او را مختل کند. برای فایل‌های تولیدی و نسخه پروژه نیز قرارداد وجود داشته باشد. اشتراک مخزن به معنی مجوز بازنویسی بی‌خبر تغییرهای دیگران نیست. شناخت وضعیت جاری بخشی از همکاری است و نباید فقط به خروجی یک فرمان تکیه کند.
Bisect به معیار خوب و بد نیاز دارد
راهنمای bisect جستجوی میان commitها برای محدود کردن محل معرفی مشکل را شرح می‌دهد. ابتدا یک نقطه شناخته‌شده خوب و یک نقطه بد لازم است. معیار باید قابل تکرار باشد: رفتار مشخص، نه حس کلی درباره سرعت یا ظاهر. اگر یک نسخه قابل بررسی نیست، skip می‌تواند آن محدودیت را نشان دهد، ولی تعداد زیاد موردهای نامعلوم نتیجه را مبهم می‌کند.
اجرای خودکار bisect نیاز به فرمانی دارد که وضعیت نتیجه را درست گزارش کند. وابستگی، داده و شرایط محیط باید با نسخه‌های بررسی‌شده سازگار باشند. اگر ابزار سنجش بین نسخه‌ها تغییر کند، نتیجه ممکن است به جای bug هدف، همان تفاوت محیط را پیدا کند. آزمون رفتار مؤلفه نمونه‌ای از تعریف معیار قابل مشاهده است، ولی دامنه آن باید با مشکل واقعی تناسب داشته باشد.
بازگردانی و بررسی نتیجه
برای تغییر منتشرشده، revert معمولاً یک commit تازه برای معکوس کردن اثر می‌سازد و تاریخچه موجود را حذف نمی‌کند. معکوس کردن یک تغییر ممکن است با تغییرهای بعدی تعارض معنایی داشته باشد؛ diff و رفتار مقصد باید مرور شوند. بازنویسی تاریخچه مشترک تصمیم جداگانه‌ای است و نباید با نام عمومی «برگشت» مخلوط شود. فرمان را با مسئله و قرارداد تیم انتخاب کنید.
در پایان کار، شاخه، diff و پیام توضیح باید حول نتیجه نهایی نوشته شوند. ابزارهای Git زمانی مفیدند که مرز تغییرها روشن باشد و تیم بتواند علت را دنبال کند. تعداد فرمان‌های پیچیده معیار مهارت نیست؛ پیش‌بینی اثر عملیات، حفظ کار دیگران و ارائه تغییر قابل مرور ارزش عملی دارد. این رویکرد هم برای CSS کوچک و هم برای اصلاح گسترده یک قابلیت فرانت‌اند قابل استفاده است.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!