پیوست ۲ ـ قسمت ۴: تغییرات چطور ثبت می‌شوند و به گیت‌هاب می‌رسند؟
متنِ این قسمت
در قسمت قبل یاد گرفتیم چطور هوش مصنوعی را به گیت‌هاب وصل کنیم، روی یک برنچ جداگانه تغییراتی انجام بدهیم و بعد از بررسی نتیجه، آن‌ها را وارد مسیر اصلی کنیم.
اما گیت‌هاب فقط جایی برای نگهداری فایل‌ها نیست. یکی از مهم‌ترین امکاناتش این است که می‌تواند تاریخچهٔ تغییرات پروژه را نگه دارد.
این یعنی چه؟
فرض کنید دارید یک پاورپوینت آماده می‌کنید
قرار است در یک کنگرهٔ دندان‌پزشکی سخنرانی کنید و دارید اسلایدهای ارائه را می‌سازید.
ده اسلاید اول را آماده کرده‌اید و چند ساعت برایشان وقت گذاشته‌اید. حالا می‌خواهید ادامه بدهید، اما دلتان می‌خواهد اگر بعداً چیزی خراب شد، بتوانید به همین وضعیت برگردید.
احتمالاً یک کپی از پاورپوینت می‌گیرید و اسمش را می‌گذارید «نسخه اول».
ده اسلاید دیگر می‌سازید و دوباره یک کپی می‌گیرید: «نسخه دوم».
اگر این کار را ادامه بدهید، بعد از مدتی چندین فایل دارید و شاید حتی یادتان نباشد کدام نسخه چه تفاوتی با قبلی داشته است.
یکی از قابلیت‌های گیت‌هاب این است که می‌توانیم وضعیت پروژه را در مراحل مختلف ثبت کنیم و تاریخچهٔ آن را نگه داریم.
مثلاً بعد از آماده‌شدن ده اسلاید اول، یک وضعیت ثبت می‌کنیم. بعد از تکمیل بخش دوم، وضعیت دیگری ثبت می‌کنیم.
اگر بعداً متوجه شویم تغییرات جدید مناسب نبودند، می‌توانیم به نسخهٔ ثبت‌شدهٔ قبلی مراجعه کنیم.
در دندان‌پزشکی هم تصور کنید مشغول طراحی دیجیتال یک روکش هستید. طراحی اولیه را انجام داده‌اید، بعد کانتور را اصلاح کرده‌اید و سپس سراغ طراحی اکلوژن رفته‌اید.
چقدر خوب می‌شد اگر در هر مرحلهٔ مهم، وضعیت طراحی را نگه می‌داشتید تا اگر اصلاحات بعدی مناسب نبودند، بتوانید به مرحلهٔ قبلی برگردید.
البته این‌ها مثال‌هایی برای فهمیدن مفهوم نگهداری نسخه‌ها هستند. گیت‌هاب به‌خصوص برای فایل‌های متنی و پروژه‌های نرم‌افزاری مناسب است و فایل‌های پاورپوینت یا طراحی دندانی محدودیت‌های خودشان را دارند.
حالا ببینیم تغییرات چطور ثبت می‌شوند و به گیت‌هاب می‌رسند.
قبل از ادامه، یک نکته: قرار نیست دستورهای فنی را یاد بگیرید یا این مراحل را خودتان انجام بدهید. هوش مصنوعی می‌تواند کارهای اجرایی را انجام دهد. ما فقط می‌خواهیم با روند کار و چند اصطلاح آشنا شویم تا وقتی هوش مصنوعی گزارش می‌دهد، بدانیم چه اتفاقی افتاده و آیا تغییرات واقعاً به گیت‌هاب رسیده‌اند یا نه.
از مطب تا لابراتوار؛ سه مرحلهٔ ساده
فرض کنید امروز از چند بیمار قالب گرفته‌ایم و قرار است کارهایشان را برای لابراتوار بفرستیم.
قالب‌ها، بایت‌ها و اطلاعات مربوط به بیماران آماده‌اند. اما هنوز آن‌ها را تحویل لابراتوار نداده‌ایم.
حالا سه مرحله داریم.
۱. Stage؛ انتخاب و آماده‌کردن تغییرات
اول قالب‌ها و اطلاعات مربوط به سفارش‌هایی را که می‌خواهیم ارسال کنیم، از بین کارهای مطب انتخاب می‌کنیم و روی یک میز می‌گذاریم.
مثلاً قالب بیمار اول را همراه بایتش می‌آوریم. بعد قالب بیمار دوم را هم کنار آن قرار می‌دهیم.
حالا این‌ها کارهایی هستند که برای ارسال انتخاب کرده‌ایم.
اما هنوز چیزی را نهایی نکرده‌ایم. ممکن است متوجه شویم اطلاعات رنگ یکی از بیماران کامل نیست؛ پس فعلاً آن کار را از روی میز کنار می‌گذاریم.
در پروژه هم ممکن است چند فایل تغییر کرده باشند، اما بخواهیم فقط بعضی از آن تغییرات در ثبت بعدی قرار بگیرند.
به این انتخاب و آماده‌کردن تغییرات Stage یا استیج‌کردن می‌گویند.
در این مرحله فقط مشخص کرده‌ایم چه چیزهایی قرار است ثبت شوند؛ هنوز نسخهٔ جدیدی در تاریخچه ثبت نشده است.
۲. Commit؛ ثبت یک وضعیت مشخص از پروژه
حالا فرض کنید کارهایی را که روی میز گذاشته‌ایم بررسی می‌کنیم و مطمئن می‌شویم مجموعهٔ موردنظرمان کامل است.
در دفتر ثبت سفارش‌ها، تاریخ و محتویات این مجموعه را ثبت می‌کنیم؛ به‌طوری‌که اگر بعداً کار دیگری به میز اضافه شد، همچنان مشخص باشد در این مرحله چه کارهایی آماده شده بودند.
در پروژه هم به همین شکل، یک وضعیت مشخص از تغییرات انتخاب‌شده را در تاریخچه ثبت می‌کنیم.
به این کار Commit یا کامیت‌کردن می‌گویند.
هر کامیت معمولاً توضیح کوتاهی هم دارد؛ مثلاً «اصلاح دستور توصیه‌های بعد از جراحی».
تفاوتش با Stage این است که آنجا فقط تغییرات را انتخاب کرده بودیم، اما اینجا یک نسخهٔ مشخص از تغییرات واقعاً در تاریخچه ثبت شده است.
و نکتهٔ مهم اینکه هنوز لازم نیست چیزی به سایت گیت‌هاب فرستاده شده باشد.
گیت‌هاب از سیستمی به اسم Git استفاده می‌کند که می‌تواند روی کامپیوتر هم کار کند. اگر روی لپ‌تاپ خودمان کار کنیم، کامیت ممکن است فعلاً همان‌جا ثبت شده باشد. اگر هوش مصنوعی در محیط کاری ابری خودش کار کند، کامیت هم ممکن است در همان محیط باشد.
۳. Push؛ ارسال تغییرات به گیت‌هاب
برگردیم به لابراتوار.
کارها را انتخاب کردیم، مجموعهٔ موردنظر را آماده کردیم و در دفتر ثبتشان کردیم.
اما هنوز همهٔ آن‌ها روی میز مطب هستند!
حالا بسته را برای لابراتوار می‌فرستیم.
در کار با گیت‌هاب هم وقتی کامیت‌های ثبت‌شده در محیط کاری را به ریپوی آنلاین می‌فرستیم، به این کار Push یا پوش‌کردن می‌گویند.
پس اگر هوش مصنوعی بگوید «کامیت کردم»، یعنی تغییرات را در تاریخچه ثبت کرده، اما ممکن است هنوز به سایت گیت‌هاب نرسیده باشند.
وقتی پوش با موفقیت انجام شده باشد، کامیت‌های ارسال‌شده به ریپوی گیت‌هاب هم رسیده‌اند.
البته بعضی ابزارهای هوش مصنوعی مستقیماً در خود گیت‌هاب تغییر ایجاد می‌کنند. در این حالت، کامیت همان‌جا ثبت می‌شود و پوش جداگانه‌ای لازم نیست.
اگر هم تغییرات روی یک برنچ جداگانه ثبت شده باشند، رسیدن آن‌ها به گیت‌هاب به معنی مرج‌شدن با "main" نیست. می‌توانیم ابتدا تغییرات را بررسی کنیم و بعد تصمیم بگیریم که وارد مسیر اصلی شوند یا نه.
حالا امتحان کنیم
در Work (چت‌جی‌پی‌تی) بگویید:
«به دستور توصیه‌های بعد از جراحی در ریپوی "my-prompts" اضافه کن که متن نهایی باید قبل از تحویل به بیمار بررسی شود. روی برنچ جدا انجام بده، تغییرات رو در گیت‌هاب ثبت کن و فعلاً مرج نکن.»
بعد از انجام کار هم کافی است بپرسید:
«لینک تغییرات رو بده و بگو چه چیزی عوض شده.»
هوش مصنوعی می‌تواند مراحل لازم را انجام دهد و نتیجه را برای بررسی در اختیارمان بگذارد.
اگر بخواهیم به نسخهٔ قبلی برگردیم چه؟
برگردیم به همان مثال پاورپوینت.
فرض کنید بیست اسلاید آماده کرده‌اید. حالا تصمیم می‌گیرید ظاهر اسلایدها را تغییر بدهید؛ قالب جدیدی انتخاب می‌کنید، رنگ‌ها و فونت‌ها را عوض می‌کنید و بعضی جزئیات را جابه‌جا می‌کنید.
از نتیجه راضی هستید، پس این وضعیت جدید را هم ثبت می‌کنید (کامیت می‌کنید).
اما فردا که دوباره ارائه را می‌بینید، متوجه می‌شوید طراحی قبلی خیلی بهتر بوده است!
اگر وضعیت قبلی را ثبت کرده باشید (کامیت کرده باشید)، می‌توانید به آن مراجعه کنید و تغییرات جدید را برگردانید.
این هم یکی از قابلیت‌هایی است که می‌توانیم با کمک هوش مصنوعی از آن استفاده کنیم (ریورت‌کردن).
البته کاربردش فقط برگرداندن آخرین تغییر نیست.
فرض کنید طی چند ماه، بارها دستور توصیه‌های بعد از جراحی را اصلاح کرده‌اید و هر بار تغییرات را ثبت کرده‌اید (کامیت کرده‌اید).
حالا می‌توانید از هوش مصنوعی بپرسید:
«تاریخچهٔ تغییرات این دستور رو بررسی کن. بگو چه تاریخ‌هایی تغییرات ثبت شده و هر بار چه چیزهایی عوض شده.»
هوش مصنوعی می‌تواند تاریخ ثبت نسخه‌ها و تغییراتی را که در هر مرحله انجام شده‌اند برایتان گزارش کند.
بعد می‌توانید بگویید:
«تغییراتی که در فلان تاریخ انجام دادیم رو بررسی کن. می‌خوام ببینم قبل از اون چه وضعیتی داشتیم.»
یا حتی:
«از تغییراتی که اون روز انجام دادیم خوشم نیومده. می‌خوام همون تغییرات رو برگردونیم، بدون اینکه تغییرات دیگه از بین برن. اول بگو چه چیزهایی تحت تأثیر قرار می‌گیرن.»
به این ترتیب، لازم نیست تمام کار را از اول شروع کنیم یا بین فایل‌های قدیمی دنبال نسخهٔ موردنظر بگردیم.
کافی است تاریخچهٔ تغییرات را داشته باشیم و به هوش مصنوعی بگوییم چه چیزی را می‌خواهیم بررسی کنیم یا برگردانیم.
البته این امکان دربارهٔ تغییراتی است که واقعاً در تاریخچه ثبت شده‌اند؛ تغییرات ثبت‌نشده لزوماً قابل بازیابی نیستند.
در قسمت بعد با یکی دیگر از امکانات گیت‌هاب آشنا می‌شویم: Pull Request؛ جایی که می‌توانیم تغییرات یک برنچ را پیش از ورود به مسیر اصلی بررسی کنیم.