گیت‌هاب چیست؟ کنترل نسخه برای غیربرنامه‌نویس‌ها
گیت‌هاب یک وب‌سایت است که کد پروژه‌های نرم‌افزاری را همراه با کل تاریخچه‌شان نگه می‌دارد، تا هر تغییر را ببینید، اشتباه‌ها را برگردانید و روی همان پروژه با دیگران کار کنید. این سرویس بر پایه Git ساخته شده است؛ نرم‌افزار رایگانی که در طول زمان از فایل‌های پروژه «عکس فوری» ثبت می‌کند. Git تاریخچه را نگه می‌دارد و گیت‌هاب خانه آنلاینی است که این تاریخچه در آن به اشتراک گذاشته، پشتیبان‌گیری و درباره‌اش بحث می‌شود.
اگر با هوش مصنوعی می‌سازید، گیت‌هاب بیشتر برای دو کار به کار می‌آید: داشتن یک کپی از کدتان بیرون از ابزاری که با آن ساخته‌اید، و سپردن آن به یک توسعه‌دهنده در قالبی که او از قبل با آن کار می‌کند.
چرا وقتی با هوش مصنوعی می‌سازید اهمیت دارد
یک ابزار ساخت اپ با هوش مصنوعی خیلی سریع کد می‌نویسد و تغییر می‌دهد، و هر تغییری بهبود نیست. کنترل نسخه راهی است که این کار را امن نگه می‌دارد.
- با اطمینان برگردید. هر تغییر ذخیره‌شده یک عکس فوری است. اگر هوش مصنوعی چیزی را خراب کرد، به آخرین نسخه خوب برمی‌گردید.
- مالکیت. کدی که در حساب گیت‌هاب خودتان است، اگر ابزارتان را عوض کنید، دیگر پولی برای آن ندهید، یا نظر دوم بخواهید، همچنان مال خودتان می‌ماند.
- کار با توسعه‌دهنده‌ها. تقریباً هر توسعه‌دهنده‌ای هر روز از Git استفاده می‌کند. یک مخزن به آن‌ها امکان می‌دهد کاری را که هوش مصنوعی نوشته بررسی کنند، اصلاح کنند و تغییرات را برگردانند.
- استقرار جای دیگر. بسیاری از سرویس‌های میزبانی می‌توانند مستقیم از یک مخزن گیت‌هاب منتشر کنند.
یک مثال روزمره: ردیابی تغییرات به‌علاوه یک درایو مشترک
یک سند را تصور کنید که حالت «track changes» آن روشن است و روی یک درایو مشترک ذخیره شده.
- Git همان track changes است: هر ویرایش ثبت می‌شود، همراه با اینکه چه کسی، کی و چرا آن را انجام داده، و می‌توانید به هر نسخه‌ای برگردید.
- گیت‌هاب همان درایو مشترک است: سند آنلاین است، دیگران می‌توانند کپی بگیرند، و جایی برای نظر دادن و تأیید وجود دارد.
- branch مثل ذخیره کردن یک کپی با نام «پیش‌نویس — بخش جدید قیمت‌ها» است، تا بتوانید آزمایش کنید بدون اینکه به نسخه‌ای که همه به آن تکیه دارند دست بزنید. اگر آزمایش موفق بود، آن را دوباره به نسخه اصلی وصل (merge) می‌کنید.
تفاوتش با یک سند در مقیاس است. یک اپ صدها فایل دارد و Git همه را با هم دنبال می‌کند، پس هر عکس فوری وضعیت کل پروژه در همان لحظه است.
اصطلاحات Git و گیت‌هاب که با آن‌ها روبه‌رو می‌شوید
| اصطلاح | معنی ساده |
|---|---|
| Repository (repo) | پوشه یک پروژه همراه با کل تاریخچه‌اش |
| Commit | یک عکس فوری ذخیره‌شده از تغییرات، همراه با پیام کوتاهی که آن را توضیح می‌دهد |
| Branch | یک خط کاری جداگانه، تا آزمایش‌ها نسخه اصلی را به‌هم نریزند |
| main | نام معمول شاخه اصلی؛ نسخه‌ای که زنده می‌شود |
| Merge | آوردن تغییرات یک branch به branch دیگر |
| Merge conflict | دو تغییر به یک خط‌ها دست زده‌اند؛ یک نفر باید انتخاب کند کدام را نگه دارد |
| Clone | دانلود یک کپی کامل از یک مخزن، همراه با تاریخچه |
| Push / pull | فرستادن commitهای شما به گیت‌هاب / آوردن commitهای دیگران به سیستم شما |
| Pull request (PR) | صفحه‌ای در گیت‌هاب که پیشنهاد ادغام یک branch را می‌دهد تا افراد تغییرات را بررسی و درباره‌شان بحث کنند |
| Fork | کپی شخصی شما از مخزن کس دیگری در گیت‌هاب |
| Issue | کار مانده یا گزارش باگی که به مخزن وصل است |
.gitignore | فهرستی از فایل‌هایی که Git هرگز ثبت نمی‌کند، مثل فایل‌های رمز .env و وابستگی‌های دانلودشده |
| GitHub Actions | اتوماسیونی که روی گیت‌هاب اجرا می‌شود، مثلاً تست‌ها در هر pull request |
دو نکته را باید زیر آن خط کشید. اول، تاریخچه Git به‌طور ذاتی دائمی است: اگر یک رمز عبور commit و push شود، حذفش در commit بعدی آن را از تاریخچه پاک نمی‌کند. دوم، ارزش یک commit به پیام آن است. «رفع دوبار رزرو شدن نوبت وقتی دو نفر هم‌زمان رزرو می‌کنند» بعداً به کارتان می‌آید؛ «update» نه.
یک مثال کامل: سپردن یک اپ ساخته‌شده با هوش مصنوعی به یک فریلنسر
یک پورتال مشتری را با یک ابزار ساخت اپ با هوش مصنوعی ساخته‌اید. کار می‌کند، اما می‌خواهید یک توسعه‌دهنده فریلنسر یک یکپارچه‌سازی سخت با نرم‌افزار حسابداری‌تان اضافه کند.
- پروژه را به یک مخزن خصوصی جدید در گیت‌هاب وصل کنید و push کنید. حالا مخزن کد و تاریخچه‌اش را دارد.
- بررسی کنید چه چیزی در آن است. مخزن را در گیت‌هاب باز کنید. نباید فایل
.envیا کلید API در کد باشد. رمزها در تنظیمات سرویس شما می‌مانند و اگر لازم باشد، جداگانه با فریلنسر در میان گذاشته می‌شوند؛ ببینید متغیرهای محیطی و رمزها. - فریلنسر را فقط برای همان مخزن به‌عنوان همکار دعوت کنید.
- او روی یک branch با نامی مثل
accounting-syncکار می‌کند، همان‌طور که پیش می‌رود commit می‌کند، و وقتی تمام شد یک pull request باز می‌کند. - شما pull request را بررسی می‌کنید. حتی بدون خواندن کد، می‌توانید توضیحات را بخوانید، ببینید کدام فایل‌ها تغییر کرده‌اند و در نظرها سؤال بپرسید.
- وقتی راضی بودید merge کنید، سپس تغییرات را در ابزار ساختتان pull کنید تا شما و هوش مصنوعی از نسخه جدید ادامه دهید.
در تمام این مسیر می‌توانید دقیقاً ببینید چه چیزی تغییر کرده و در صورت نیاز آن را برگردانید. این کل ارزش کنترل نسخه در یک گردش کار است. اگر هنوز نمی‌دانید اصلاً به توسعه‌دهنده نیاز دارید یا نه، ببینید استخدام توسعه‌دهنده یا ساختن با هوش مصنوعی.
اشتباه‌ها و تصورات غلط رایج
- «GitHub و Git یک چیزند.» Git بدون گیت‌هاب کار می‌کند؛ سرویس‌های دیگری مثل GitLab و Bitbucket هم مخازن Git را میزبانی می‌کنند.
- «گیت‌هاب اپ من را اجرا می‌کند.» گیت‌هاب کد را نگه می‌دارد. اجرای اپ برای عموم میزبانی وب است، سرویسی جداگانه (هرچند بعضی سرویس‌ها از گیت‌هاب منتشر می‌کنند).
- commit کردن رمزها. پرخطرترین و رایج‌ترین اشتباه. فایل‌های
.envرا با.gitignoreکنار بگذارید، و هر کلیدی که یک بار push شده را عوض کنید. - فقط یک branch و بدون پیام. برای آزمایش‌های تنها اشکالی ندارد، اما به commitها پیام واضح بدهید و برای هر کار پرریسک از branch استفاده کنید.
- ویرایش در دو جا هم‌زمان. اگر کد را هم در گیت‌هاب و هم در ابزار ساخت با هوش مصنوعی تغییر دهید بدون pull کردن بین آن‌ها، تعارض ایجاد می‌شود. در هر لحظه یک جا را برای ویرایش انتخاب کنید و قبل از عوض کردن، همگام‌سازی کنید.
- فکر کنید مخزن خصوصی پشتیبان همه چیز است. فقط کد را نگه می‌دارد، نه محتوای پایگاه داده یا فایل‌های آپلودشده. آن‌ها به پشتیبان‌گیری جداگانه نیاز دارند.
از ابزار ساخت با هوش مصنوعی‌تان چه بخواهید
- «یک
.gitignoreاضافه کن که.env، پوشه وابستگی‌ها و خروجی build را کنار بگذارد.» - «یک README بنویس که نصب، متغیرهای محیطی لازم (فقط نام‌ها) و نحوه اجرای اپ را توضیح دهد.»
- «یک
.env.exampleاضافه کن با نام همه متغیرها و بدون مقدار واقعی.» - «برای هر تغییر از پیام‌های commit واضح و توصیفی استفاده کن.»
این چهار درخواست مخزنی می‌سازد که یک توسعه‌دهنده در چند دقیقه می‌تواند بردارد و ادامه دهد. برای انتقال اپ به سرورهای خودتان، ببینید چطور اپ ساخته‌شده با هوش مصنوعی را خروجی بگیرید و روی سرور خودتان میزبانی کنید، و برای سخت‌تر کردن آن پیش از کاربران واقعی، بردن نمونه اولیه هوش مصنوعی به محیط تولید.
گیت‌هاب و Mythex
Mythex در هر طرحی تاریخچه را برای شما نگه می‌دارد: بعد از هر نوبت موفق عامل، یک checkpoint ذخیره می‌کند که یک عکس فوری Git است و می‌توانید به آن برگردید. در طرح Pro می‌توانید گیت‌هاب را وصل کنید و پروژه را با مخزن خودتان push یا pull کنید، یا کل پروژه را به صورت آرشیو دانلود کنید؛ رمزها و وابستگی‌های نصب‌شده از خروجی‌ها کنار گذاشته می‌شوند. گیت‌هاب در اینجا برای همگام‌سازی کد است، نه برای ورود به Mythex. برای جزئیات، گیت‌هاب، خروجی و ورودی را در مستندات ببینید و برای آنچه هر طرح شامل می‌شود، صفحه قیمت‌گذاری را.
پرسش‌ها
تفاوت Git و گیت‌هاب چیست؟
Git نرم‌افزار رایگانی است که تاریخچه فایل‌های یک پروژه را روی هر کامپیوتری ثبت می‌کند. گیت‌هاب یک وب‌سایت است که متعلق به مایکروسافت است، مخازن Git را به‌صورت آنلاین میزبانی می‌کند و ابزارهای همکاری مثل پull request، issue و اتوماسیون را به آن اضافه می‌کند.
برای ساختن اپ با هوش مصنوعی به گیت‌هاب نیاز دارم؟
نه. بسیاری از ابزارهای ساخت اپ با هوش مصنوعی خودشان تاریخچه را داخل محصول نگه می‌دارند. گیت‌هاب وقتی مفید می‌شود که بخواهید یک کپی شخصی از کد داشته باشید، با یک توسعه‌دهنده کار کنید، یا قصد دارید اپ را جای دیگری میزبانی کنید.
آیا گیت‌هاب رایگان است؟
گیت‌هاب طرح رایگان دارد که مخازن عمومی و خصوصی را شامل می‌شود و برای اغلب افراد و تیم‌های کوچک کافی است. طرح‌های پولی مدیریت تیم و امکانات بیشتری اضافه می‌کنند؛ جزئیات فعلی را در صفحه قیمت‌گذاری گیت‌هاب بررسی کنید.
آیا کد من در گیت‌هاب عمومی است؟
فقط اگر مخزن را عمومی کنید. مخازن خصوصی فقط برای خودتان و افرادی که دعوت می‌کنید قابل مشاهده‌اند. حتی در مخزن خصوصی هم هرگز رمز عبور یا کلید API را commit نکنید.