با خیال راحت کار رو به ایجنت بسپار: گیت برای وایب‌کدینگ

تا حالا براتون پیش اومده با هوش مصنوعی یه پروژه بسازین، همه‌چیز درست کار کنه… بعد فقط یه درخواست کوچیک دیگه بدین، و یهو نصف پروژه به هم بریزه؟ و بدتر از اون، اصلاً ندونین چی عوض شده و چطوری برگردین؟

این ویدیو قراره این مشکل رو برای همیشه حل کنه. امروز Git و گیت هاب (GitHub) رو از پایه و کامل یاد می‌گیریم: اینکه دقیقاً چی هستن، پشت پرده چطوری کار می‌کنن، دستورهای اصلی‌شون، کار تیمی، و مهم‌تر از همه، اینکه وقتی با ایجنت‌هایی (Agent) مثل کلاد کد (Claude Code) و کدکس (Codex) کار می‌کنیم، چطوری ازشون استفاده کنیم که هیچ‌وقت کارمون از دست نره. و آخر ویدیو هم چند تا اشتباه رایج رو می‌گم که برای خیلی‌ها گرون تموم شده. بیاین از خود مشکل شروع کنیم. احتمالاً شما هم این صحنه رو دیدین: یه پوشه پر از فایل‌هایی با اسم «نهایی»، «نهایی دو»، «نهایی واقعی»، «این دیگه آخریه».

این ساده‌ترین شکل کنترل نسخه‌ست، و تا وقتی پروژه کوچیکه کار می‌کنه. ولی پروژهٔ نرم‌افزاری صدها فایل داره. یه تغییر ممکنه همزمان ده تا فایل رو عوض کنه. و وقتی چند نفر روی یه پروژه کار می‌کنن، این روش کاملاً از هم می‌پاشه: کی چی رو عوض کرد؟ کدوم نسخه درسته؟ تغییر من با تغییر همکارم چطوری یکی بشه؟ برای همین ابزارهایی به اسم «سیستم کنترل نسخه» ساخته شدن. نسل‌های قبلی، مثل SVN، یه سرور مرکزی داشتن: همه کدشون رو اونجا می‌فرستادن و از اونجا می‌گرفتن. اگه سرور از کار می‌افتاد، کار کل تیم متوقف می‌شد.

سال ۲۰۰۵، Linus Torvalds، همون کسی که Linux رو ساخت، برای مدیریت کد خود Linux یه ابزار جدید نوشت: Git. و فرق اصلیش این بود که «توزیع‌شده»‌ست؛ یعنی هر کسی یه نسخهٔ کامل از کل پروژه و کل تاریخچه‌ش رو روی کامپیوتر خودش داره. نه به سرور وابسته‌ست، نه به اینترنت. امروز Git عملاً استاندارد جهانیه و تقریباً همهٔ تیم‌های نرم‌افزاری دنیا ازش استفاده می‌کنن. برای اینکه Git رو واقعاً بفهمیم، باید بدونیم کد ما توی Git از سه جا رد می‌شه. اول، «پوشهٔ کاری»؛ همون فایل‌هایی که الان دارین روشون کار می‌کنین.

دوم، staging؛ یه جور اتاق انتظار. اینجا انتخاب می‌کنین کدوم تغییرها قراره توی عکس بعدی ثبت بشن. این خیلی مهمه، چون شاید ده تا فایل رو عوض کرده باشین، ولی بخواین فقط سه تاش رو الان ثبت کنین. و سوم، repository یا مخزن؛ جایی که همهٔ عکس‌های ثبت‌شده، یعنی کل تاریخچهٔ پروژه، نگه داشته می‌شه. به هر کدوم از این عکس‌ها می‌گن commit. ولی commit فقط یه کپی ساده نیست. هر commit سه تا چیز داره: یه عکس کامل از وضعیت پروژه، یه پیام که توضیح می‌ده چی عوض شده و چرا، و یه شناسهٔ یکتا؛ یه رشته از حرف و عدد که هیچ commit دیگه‌ای توی دنیا عین اون رو نداره.

هر commit هم می‌دونه commit قبل از خودش کدوم بوده، و همین زنجیره، تاریخچهٔ پروژه رو می‌سازه. یه نکتهٔ حرفه‌ای: پیام commit رو جدی بگیرین. «تغییرات» پیام خوبی نیست. «رفع خطای ورود کاربر با ایمیل خالی» پیام خوبیه. شش ماه بعد، خودتون از خودتون تشکر می‌کنین. حالا ببینیم توی عمل چطوری کار می‌کنه. لازم نیست همهٔ دستورها رو حفظ کنین، ولی باید بدونین هر کدوم چیکار می‌کنه، چون ایجنت‌ها هم دقیقاً همین‌ها رو اجرا می‌کنن. با git init یه پوشه رو تبدیل به پروژهٔ Git می‌کنین.

با git status می‌بینین چه فایل‌هایی عوض شدن. با git add تغییرها رو می‌فرستین توی staging. با git commit عکس رو ثبت می‌کنین. با git log تاریخچه رو می‌بینین. و با git diff دقیقاً می‌بینین چه خط‌هایی اضافه یا حذف شدن. و یه فایل خیلی مهم هم هست به اسم .gitignore. هر چیزی که اسمش اینجا باشه، Git اصلاً نگاهش نمی‌کنه. مثلاً فایل‌های موقت، پوشه‌های سنگین، و از همه مهم‌تر، فایل .env که کلیدهای ای‌پی‌آی (API: راه وصل شدن برنامه‌ها) توشه. این رو یادتون بمونه، چون آخر ویدیو دوباره بهش برمی‌گردیم.

اصل ماجرا همینه: برگشتن. Git چند تا راه برای برگشت داره و فرقشون مهمه. اگه هنوز commit نکردین و فقط می‌خواین تغییرهای یه فایل رو دور بریزین، با git restore برمی‌گرده به آخرین commit. اگه یه commit اشتباه ثبت شده، git revert یه commit جدید می‌سازه که اون اشتباه رو خنثی می‌کنه؛ یعنی تاریخچه پاک نمی‌شه، فقط اصلاح می‌شه. این امن‌ترین راهه، مخصوصاً وقتی با تیم کار می‌کنین. و git reset، که واقعاً تاریخچه رو به عقب برمی‌گردونه. قدرتمنده، ولی اگه ندونین دارین چیکار می‌کنین، می‌تونه کار رو از دست بده.

قانون ساده: تا مطمئن نیستین، از revert استفاده کنین. حالا قشنگ‌ترین بخش Git: branch. branch یه مسیر جداست برای کار کردن. شاخهٔ اصلی پروژه معمولاً اسمش main ـه، و قرار نیست روش آزمایش کنین. وقتی می‌خواین یه قابلیت جدید بسازین، یه branch جدید می‌سازین، مثلاً به اسم «صفحهٔ پرداخت»، و همهٔ کار رو اونجا انجام می‌دین. شاخهٔ اصلی دست‌نخورده می‌مونه. نکتهٔ جالب اینه که branch ساختن توی Git تقریباً هیچ هزینه‌ای نداره. branch در واقع فقط یه برچسبه که به یه commit اشاره می‌کنه.

برای همین تیم‌های حرفه‌ای برای هر کار کوچیک یه branch جدا می‌سازن. وقتی کارتون روی branch تموم شد، اون رو با شاخهٔ اصلی یکی می‌کنین؛ به این کار می‌گن merge. بیشتر وقت‌ها Git خودش این کار رو بی‌دردسر انجام می‌ده. ولی اگه همزمان روی شاخهٔ اصلی هم همون خط‌ها عوض شده باشن، Git نمی‌تونه حدس بزنه کدوم درسته. به این می‌گن conflict. نترسین. conflict یعنی Git داره ازتون می‌پرسه کدوم نسخه رو نگه داره. هر دو نسخه رو کنار هم نشون می‌ده، شما انتخاب می‌کنین، و commit می‌کنین.

و الان ایجنت‌ها توی حل conflict خیلی خوبن؛ کافیه بهشون بگین بررسیش کنن و قبل از تأیید، نتیجه رو بهتون نشون بدن.

خب، تا اینجا همه‌چیز روی کامپیوتر خودتون بود. حالا سؤال اینه: اگه بخواین با کسی همکاری کنین؟ اگه بخواین از کامپیوتر دیگه‌ای کار کنین؟ یا اگه هارد کامپیوترتون بسوزه؟ اینجاست که گیت هاب میاد وسط. یه اشتباه خیلی رایج اینه که فکر کنیم Git و گیت هاب یکی‌ان. نه. Git ابزاریه که روی کامپیوتر شما کار می‌کنه. گیت هاب یه سرویس آنلاینه که پروژه‌های Git رو نگه می‌داره، و کلی ابزار برای همکاری روش ساخته. گیت هاب سال ۲۰۰۸ راه افتاد و سال ۲۰۱۸ Microsoft خریدش. امروز بزرگ‌ترین خونهٔ کد دنیاست، و می‌تونین هم پروژهٔ عمومی داشته باشین، هم خصوصی، رایگان.

توی گیت هاب، به نسخهٔ آنلاین پروژه می‌گن ریموت، و به نسخهٔ روی کامپیوترتون local. با git clone یه پروژه رو از گیت هاب روی کامپیوترتون کپی می‌کنین. با git push commit‌هاتون رو می‌فرستین بالا. و با git pull آخرین تغییرهای بقیه رو می‌گیرین. هر چیزی که push نکردین، فقط روی کامپیوتر خودتونه؛ پس عادت کنین هر روز آخر کار، push کنین. مهم‌ترین قابلیت گیت هاب، pull request ـه. روال کار تیم‌های حرفه‌ای این‌طوریه: یه branch می‌سازین، کارتون رو می‌کنین، push می‌کنین، و بعد یه pull request باز می‌کنین؛ یعنی درخواست می‌دین که branch تون با شاخهٔ اصلی merge بشه.

حالا بقیهٔ تیم تغییرها رو خط به خط می‌بینن، نظر می‌دن، اصلاح می‌خوان، و آخر سر تأیید می‌کنن. تازه اون موقع کد وارد شاخهٔ اصلی می‌شه. این همون جاییه که کیفیت کد حفظ می‌شه. و حتی اگه تنها کار می‌کنین، pull request یه راه عالیه برای اینکه قبل از merge، یه بار دیگه کار ایجنت رو با دقت ببینین. چند تا قابلیت دیگه هم هست که خوبه بشناسین. ایشو‌ها (Issue: مشکل) برای ثبت باگ‌ها (Bug: خطای برنامه) و کارهایی که باید انجام بشه. fork برای کپی کردن پروژهٔ یه نفر دیگه توی حساب خودتون، و مشارکت توی پروژه‌های open source.

و GitHub Actions، که کارهای تکراری رو خودکار می‌کنه: مثلاً هر بار که کد push می‌شه، خودش تست‌ها رو اجرا می‌کنه یا پروژه رو منتشر می‌کنه. گیت هاب تنها گزینه نیست. هر سه سرویس اصلی با همون Git کار می‌کنن، پس یاد گرفتن یکی یعنی یاد گرفتن همه. GitLab خیلی شبیه گیت هاب ـه، ولی ابزارهای تست و انتشار خودکار رو کامل توی خودش داره، و می‌شه روی سرور شخصی نصبش کرد. برای شرکت‌هایی که می‌خوان کد هیچ‌وقت از سرور خودشون بیرون نره، انتخاب محبوبیه. Bitbucket مال شرکت Atlassian ـه، سازندهٔ Jira.

برای تیم‌هایی که کارهاشون رو با Jira مدیریت می‌کنن، اتصالش خیلی راحته. و پیشنهاد من برای شروع؟ گیت هاب. چون بزرگ‌ترین جامعه رو داره، و تقریباً همهٔ ابزارهای هوش مصنوعی مستقیم بهش وصل می‌شن.

حالا می‌رسیم به جایی که این ویدیو رو از بقیه جدا می‌کنه: Git وقتی با ایجنت کار می‌کنیم. قانون اول: قبل از هر درخواست بزرگ، commit. ایجنت‌ها سریع کار می‌کنن، و گاهی سریع هم خراب می‌کنن. اگه قبلش یه commit داشته باشین، بدترین حالت اینه که با یه دستور برمی‌گردین عقب. قانون دوم: برای هر قابلیت جدید، یه branch جدا. اگه ایجنت مسیر رو اشتباه رفت، کل branch رو کنار می‌ذارین و شاخهٔ اصلی سالم می‌مونه. قانون سوم: قبل از اینکه کار ایجنت رو قبول کنین، diff رو ببینین.

یعنی دقیق ببینین چه خط‌هایی عوض شده. ایجنت‌ها گاهی فایل‌هایی رو هم عوض می‌کنن که اصلاً ازشون نخواسته بودین. و خبر خوب اینکه لازم نیست هیچ‌کدوم از این دستورها رو خودتون تایپ کنین. کلاد کد و کدکس و آنتی‌گرویتی (Antigravity: ابزار گوگل)، Git رو کامل بلدن. کافیه بهشون بگین: «قبل از شروع یه commit بزن»، «یه branch جدید بساز برای این کار»، «تغییرهات رو بهم نشون بده»، یا «برگرد به commit قبلی». حتی می‌تونین چند تا ایجنت رو همزمان، هر کدوم روی یه branch جدا، کار بدین، بدون اینکه کار همدیگه رو خراب کنن.

و اگه با ترمینال (Terminal) راحت نیستین، برنامه‌هایی مثل GitHub Desktop، یا بخش Git توی VS Code، همهٔ این کارها رو با چند تا کلیک انجام می‌دن. و قول داده بودم چند تا اشتباه رایج رو بگم. اشتباه اول، و خطرناک‌ترینش: commit کردن کلیدهای ای‌پی‌آی. اگه فایل .env رو توی .gitignore نذارین و پروژه رو روی گیت هاب عمومی push کنین، ربات‌هایی هستن که ظرف چند دقیقه کلیدها رو پیدا می‌کنن و ازشون سوءاستفاده می‌کنن. و پاک کردن فایل هم کافی نیست، چون توی تاریخچه می‌مونه.

اگه این اتفاق افتاد، کلید رو همون لحظه باطل کنین و یه کلید جدید بسازین. اشتباه دوم: کار کردن مستقیم روی شاخهٔ اصلی. همیشه branch. اشتباه سوم: commit‌های غول‌پیکر. یه commit با صد تا تغییر نامرتبط، برگشتن رو تقریباً غیرممکن می‌کنه. commit‌های کوچیک و با پیام واضح. و اشتباه چهارم: push --force روی شاخه‌ای که بقیه هم روش کار می‌کنن. این دستور می‌تونه کار بقیه رو پاک کنه. اگه مطمئن نیستین، اصلاً سراغش نرین. پس بیاین مرور کنیم. Git، کنترل کامل تاریخچهٔ پروژه‌تونه، روی کامپیوتر خودتون: commit برای ثبت، branch برای آزمایش بی‌خطر، merge برای یکی کردن، و revert برای برگشتن.

گیت هاب، خونهٔ آنلاین پروژه‌ست: برای پشتیبان، همکاری، pull request، و اتصال به ابزارها. و توی وایب کدینگ (Vibe Coding)، این دوتا همون چیزی‌ان که بهتون اجازه می‌دن با خیال راحت کار رو به ایجنت بسپارین. اگه این ویدیو به کارتون اومد، لایک کن تا یادت نرفته. سؤالی داری؟ همین الان توی کامنت‌ها بپرس؛ خودم جواب می‌دم. یادت نره سابسکرایب کنی، و برای دوستات هم بفرست که اونا هم یاد بگیرن. توی قسمت بعدی مفاهیم پایه، می‌ریم سراغ ترمینال. می‌بینمتون.