نحوه استفاده از Git با اپلیکیشنی که با هوش مصنوعی ساخته شده

برای استفاده از Git با اپلیکیشنی که با هوش مصنوعی ساخته شده، پروژه را به یک مخزن Git وصل کنید، بعد از هر تغییر موفق commit بزنید، با یک خط توضیح دهید چه چیزی تغییر کرده و اطلاعات محرمانه را با یک .gitignore بیرون نگه دارید. برای هر کار پرریسک از یک branch استفاده کنید، اگر شخص دیگری کد را تغییر داده قبل از پرامپت دوباره pull بزنید، و وقتی هوش مصنوعی چیزی را خراب کرد، به آخرین commit خوب برگردید به جای اینکه روی همان به‌هم‌ریختگی پرامپت بدهید.

Git سیستم کنترل نسخه است: تاریخچه‌ای از هر نسخه ذخیره‌شدهٔ کدتان. GitHub وبسایتی است که مخازن Git را به‌صورت آنلاین نگه می‌دارد. اگر این‌ها برایتان تازه‌اند، با GitHub چیست شروع کنید. این راهنما درباره عادت‌هایی است که Git را وقتی هوش مصنوعی بیشتر کد را می‌نویسد مفید می‌کنند.

چرا Git با هوش مصنوعی مهم‌تر است

یک هوش مصنوعی می‌تواند در یک نوبت بیست فایل را تغییر دهد. این سریع است، و یعنی یک پرامپت می‌تواند بی‌سروصدا چیزی را خراب کند که دیروز آزمایش کرده بودید. Git به شما این امکان‌ها را می‌دهد:

• راه بازگشت. هر نسخهٔ commit‌شده را می‌توان بازیابی کرد.
• ثبت آنچه تغییر کرده. می‌توانید ببینید دقیقاً کدام فایل‌ها و خط‌ها توسط یک پرامپت لمس شده‌اند.
• یک کپی بیرون از ابزار ساخت. کدتان جایی است که شما کنترلش می‌کنید.
• تحویل استاندارد. هر توسعه‌دهنده، میزبان یا ابزاری می‌تواند از یک مخزن Git کار کند.

مرحلهٔ ۱: اتصال یک مخزن

یک مخزن (معمولاً خصوصی) در GitHub یا سرویس مشابه بسازید و پروژه‌تان را به آن وصل کنید. بیشتر ابزارهای ساخت اپلیکیشن با هوش مصنوعی که از Git پشتیبانی می‌کنند این کار را از طریق یک صفحهٔ تنظیمات با دکمهٔ «Connect GitHub» انجام می‌دهند. اگر ابزار شما این را ندارد، می‌توانید کد را خروجی بگیرید و خودتان push کنید، یا یک بار از یک توسعه‌دهنده بخواهید آن را تنظیم کند.

قبل از اولین push مطمئن شوید مخزن چیزهایی را که نباید در آن باشند نادیده می‌گیرد:

فایل .gitignore را بررسی کن. مطمئن شو که فایل‌های .env، node_modules، پوشه‌های خروجی build و هر فایلی که رمز یا کلید دارد را کنار می‌گذارد. بگو چه چیزی اضافه کردی.

مرحلهٔ ۲: بعد از هر تغییر موفق commit بزنید

commit یک نسخهٔ ذخیره‌شده از کد همراه با یک پیام است. عادتی که مهم است این است: وقتی چیزی کار می‌کند، قبل از اینکه چیز بعدی را بخواهید commit بزنید.

1. برای یک تغییر پرامپت بدهید.
2. آن را در پیش‌نمایش بررسی کنید.
3. اگر کار کرد، با یک پیام commit (یا sync) کنید.
4. سپس ادامه دهید.

commitهای کوچک یعنی وقتی چیزی خراب می‌شود می‌دانید کدام تغییر آن را خراب کرده، و برگرداندن آن کار دیگری را که انجام داده‌اید از بین نمی‌برد.

مرحلهٔ ۳: پیام‌هایی بنویسید که بعداً بخوانید

یک پیام خوب می‌گوید چه چیزی و چرا تغییر کرده، در یک خط:

• خوب: Add CSV export to the orders page
• خوب: Fix booking form rejecting times after 6pm
• بی‌فایده: update، changes، fix stuff

می‌توانید از هوش مصنوعی بخواهید آن‌ها را بنویسد:

تغییرات از آخرین commit را در یک خط خلاصه کن، با یک فعل شروع شود و کمتر از ۷۰ کاراکتر باشد.

مرحلهٔ ۴: برای کارهای پرریسک از branch استفاده کنید

branch یک خط کار جداگانه است. می‌توانید روی یک branch چیزی را امتحان کنید، و اگر نتیجه نداد، بدون دست زدن به نسخهٔ اصلی آن را کنار بگذارید.

از branch استفاده کنید وقتی:

• تغییر بزرگ است (بازطراحی، جریان پرداخت جدید، تغییر پایگاه داده).
• شخص دیگری روی همان اپلیکیشن کار می‌کند.
• می‌خواهید پیش از انتشار کسی تغییر را بازبینی کند.

وقتی کار انجام و آزمایش شد، به branch اصلی merge می‌شود. در GitHub این معمولاً از طریق یک pull request انجام می‌شود، یک صفحه که تغییرات را برای بازبینی نشان می‌دهد. اگر ابزارتان فقط یک branch را sync می‌کند، یک توسعه‌دهنده می‌تواند branchها را در سمت GitHub مدیریت کند.

مرحلهٔ ۵: امن برگردید

وقتی یک پرامپت اپلیکیشن را خراب می‌کند، در برابر وسوسهٔ پنج پرامپت دیگر روی همان خرابی مقاومت کنید. به آخرین نسخهٔ خوب برگردید و یک پرامپت روشن‌تر امتحان کنید.

• در ابزار ساخت: اگر دارد، از قابلیت checkpoint یا بازیابی آن استفاده کنید.
• در Git: git revert یک commit جدید می‌سازد که یک commit قدیمی را خنثی می‌کند و تاریخچه را سالم نگه می‌دارد. این انتخاب امن برای کدی است که دیگران ممکن است pull کرده باشند.
• از git push --force روی یک branch مشترک پرهیز کنید، مگر اینکه دقیقاً بدانید چرا. تاریخچه را برای همه بازنویسی می‌کند.

اگر مطمئن نیستید، بپرسید:

تغییر آخر صفحهٔ ورود را خراب کرده. نشان بده نسبت به commit قبلی کدام فایل‌ها عوض شده‌اند و هر تغییر چه کاری کرده. هنوز چیزی را تغییر نده.

مرحلهٔ ۶: قبل از پرامپت، pull بزنید

اگر یک توسعه‌دهنده یا ابزار دیگری کد را در GitHub تغییر دهد، ابزار ساخت با هوش مصنوعی تا وقتی شما آن تغییرات را pull نکنید از آن خبر ندارد. پرامپت دادن روی کد قدیمی باعث تعارض و از دست رفتن کار می‌شود.

• در ابتدای هر جلسه pull بزنید.
• توافق کنید چه کسی چه چیزی را ویرایش می‌کند، و از ویرایش همزمان یک فایل توسط هر دو طرف پرهیز کنید.
• اگر به merge conflict (دو تغییر روی همان خط‌ها) برخوردید، از توسعه‌دهنده یا هوش مصنوعی بخواهید آن را حل کند و انتخابش را توضیح دهد.

نمونه پرامپت‌ها

پیش از شروع: از آخرین جلسه‌ام چه چیزی در مخزن تغییر کرده؟ commitها را خلاصه کن.

تغییر بعدی را به‌تنهایی انجام بده: یک دکمهٔ «Duplicate» به هر فاکتور اضافه کن. چیز دیگری را تغییر نده تا بتوانم آن را جداگانه commit کنم.

بررسی کن که هیچ کلید API، رمز عبور یا فایل .env در Git ردیابی نمی‌شود، از جمله در commitهای گذشته. فقط نام فایل‌ها را گزارش بده، نه مقدارها.

اشتباهات رایج

• commit کردن اطلاعات محرمانه. وقتی کلیدی در تاریخچهٔ Git باشد، حتی بعد از حذف فایل، افشا شده است. آن را عوض کنید.
• یک commit غول‌پیکر در هفته. نمی‌توانید یک تغییر را برگردانید بدون اینکه همه را برگردانید.
• پیام‌هایی مثل «update». تاریخچه برای پیدا کردن چیزی که خراب کرده بی‌فایده می‌شود.
• پرامپت دادن روی کد قدیمی. وقتی شخص دیگری ویرایش می‌کند، اول pull بزنید.
• force-push برای اصلاح یک اشتباه. می‌تواند کار دیگران را پاک کند. به جای آن revert کنید.
• commit کردن node_modules. خیلی حجیم است و در هر حال از فایل lock دوباره ساخته می‌شود.

چک‌لیست

• پروژه به یک مخزن خصوصی وصل است.
• .gitignore مربوط به .env، node_modules، خروجی build و اطلاعات محرمانه را کنار می‌گذارد.
• بعد از هر تغییر موفق commit می‌زنم.
• پیام‌های commit در یک خط می‌گویند چه چیزی تغییر کرده.
• تغییرات بزرگ یا پرریسک روی یک branch هستند و بازبینی می‌شوند.
• وقتی شخص دیگری کد را ویرایش می‌کند، قبل از پرامپت pull می‌زنم.
• با checkpoint یا git revert برمی‌گردم، نه با force-push.
• هر کلیدی که یک بار commit شده، عوض شده است.

Git در Mythex

Mythex بعد از هر نوبت موفق عامل یک checkpoint از Git ذخیره می‌کند، و Revert to this point پروژه را به همان نقطه برمی‌گرداند — همان undo سمت ابزار که در مرحلهٔ ۵ توضیح داده شد. ببینید Iterate without rebuilding.

در Pro، GitHub sync یک مخزن را از تنظیمات پروژه وصل می‌کند تا بتوانید با آن push و pull کنید، و export پروژه را دانلود می‌کند بدون اطلاعات محرمانه و node_modules. ببینید GitHub, export, and import. اتصال GitHub پیش از تحویل پروژه به یک توسعه‌دهنده، این تحویل را خیلی ساده‌تر می‌کند — ببینید نحوه کار با یک توسعه‌دهنده روی اپلیکیشنی که با هوش مصنوعی ساخته شده و نحوه خروجی گرفتن و self-host اپلیکیشنی که با هوش مصنوعی ساخته شده.

پرسش‌ها