سال اول برنامه‌نویسی، فکر می‌کردم GitHub فقط یک انبار برای کد است. تا روزی که در یک پروژه تیمی، متوجه شدم کدهای من در مخزن اصلی به‌هم ریخته و همکارانم نمی‌توانند پروژه را اجرا کنند. آن روز به من یاد داد که GitHub، فقط یک ابزار ذخیره‌سازی نیست؛ یک فرهنگ کاری، یک زبان مشترک بین توسعه‌دهندگان، و یک رزومه زنده است. از آن تجربه، رویکردم به استفاده از GitHub کاملاً تغییر کرد و در این نوشته، همان مسیر را برای شروع، با شما به اشتراک می‌گذارم.

GitHub دقیقاً چیست؟

GitHub یک پلتفرم میزبانی مخازن Git است که امکان همکاری، پیگیری تغییرات و مدیریت پروژه‌های نرم‌افزاری را فراهم می‌کند. تصور رایج این است که GitHub فقط برای ذخیره کد است؛ اما در تجربه‌ام، GitHub یک شبکه اجتماعی حرفه‌ای برای توسعه‌دهندگان، یک رزومه زنده و یک دفتر خاطرات پروژه است. برای درک مبانی Git (سامانه کنترل نسخه)، آموزش Git از صفر و دستورات پرکاربرد Git نقطه شروع خوبی هستند.

در تجربه‌ام، سه کاربرد اصلی GitHub در پروژه‌های واقعی:

  • ذخیره‌سازی ابری کد: دسترسی از هر دستگاهی، با تاریخچه کامل.
  • همکاری تیمی: چند نفر روی یک پروژه، بدون به‌هم ریختن کد یکدیگر.
  • نمایش حرفه‌ای به کارفرما: پروفایل GitHub، بخشی از رزومه فنی است.
GitHub، مثل یک کتابخانه عمومی است: هر کتابی که می‌نویسید، روی قفسه‌ای می‌نشیند که دیگران می‌توانند آن را بخوانند، نقد کنند و حتی تکمیل کنند. اگر کتاب را در خانه نگه دارید، فقط خودتان می‌بینیدش.

تفاوت Git و GitHub: مهم‌ترین سردرگمی مبتدیان

در تجربه‌ام، بیشترین سردرگمی مبتدیان، ندانستن تفاوت Git و GitHub است. تفاوت ساده اما حیاتی:

ویژگیGitGitHub
نوعابزار کنترل نسخهسرویس میزبانی ابری
اجراروی کامپیوتر شماروی سرورهای GitHub
کار اصلیثبت تغییرات کداشتراک‌گذاری و همکاری
جایگزینSVN، MercurialGitLab، Bitbucket

در تجربه‌ام، فهم این تفاوت، از همان روز اول مسیر یادگیری را روشن می‌کند. Git، ابزاری است که روی کامپیوتر شما اجرا می‌شود و تغییرات را ثبت می‌کند. GitHub، سرویسی است که این تغییرات را در فضای ابری نگه می‌دارد و ابزارهای همکاری را فراهم می‌کند. برای مطالعه بیشتر درباره Git، برنچ در Git، مرج در Git و حل تعارض در Git راهنماهای مکمل هستند.

راه‌اندازی حساب و ابزارها

راه‌اندازی GitHub در چند دقیقه انجام می‌شود، اما چند تصمیم کوچک، تجربه بلندمدت شما را تغییر می‌دهد. در تجربه‌ام، سه گام اصلی:

  1. ساخت حساب کاربری: با نام کاربری حرفه‌ای، نه نام‌های عجیب یا شوخی. چون این نام، بخشی از رزومه شما می‌شود.
  2. نصب Git روی کامپیوتر: برای ویندوز، Git for Windows؛ برای مک و لینوکس، از package manager.
  3. پیکربندی اولیه: تنظیم نام و ایمیل با دستورات git config.
git config --global user.name "نام شما"
git config --global user.email "ایمیل شما"

برای ویرایشگر کد و ابزارهای مکمل، بررسی VS Code، افزونه‌های ضروری VS Code و ابزارهای Git و GitHub برای تیم‌ها راهنماهای عملی هستند. برای ویرایشگرهای جایگزین، Sublime Text و Chrome DevTools گزینه‌های خوبی هستند.

ساخت اولین مخزن

ساخت اولین مخزن (Repository)، اولین قدم عملی در GitHub است. در تجربه‌ام، سه روش برای ساخت مخزن:

  • ساخت از GitHub: مستقیم از وب‌سایت، مخزن خالی بسازید و به کامپیوتر بیاورید.
  • ساخت محلی و اتصال: پروژه را محلی بسازید و به مخزن GitHub متصل کنید.
  • Fork کردن: پروژه موجود را کپی کنید و تغییر دهید.
# روش دوم: ساخت محلی و اتصال
git init
git add .
git commit -m "اولین commit"
git remote add origin https://github.com/username/repo.git
git push -u origin main

در تجربه‌ام، روش دوم، برای تازه‌کارها روشن‌تر است چون همه چیز را از پایه می‌سازد. راهنمای کامل در آموزش Git از صفر و استفاده از SDKها در پروژه‌ها آمده است.

مخزن GitHub، مثل یک باغچه است: اگر از همان روز اول مرتب بکارید، در سال دوم نگهداری‌اش آسان است. اما اگر رها کنید، در سال دوم نمی‌دانید کدام گیاه کجاست.

دستورات ضروری Git

در تجربه‌ام، برای شروع کار با GitHub، فقط یک زیرمجموعه کوچک از دستورات Git کافی است. ده دستور اصلی:

دستورکارکرد
git initساخت مخزن جدید
git cloneکپی مخزن از GitHub
git statusمشاهده وضعیت فایل‌ها
git addافزودن فایل به مرحله آماده
git commitثبت تغییرات
git pushارسال تغییرات به GitHub
git pullدریافت تغییرات از GitHub
git branchمشاهده یا ساخت شاخه
git checkoutتغییر شاخه
git mergeادغام شاخه

در تجربه‌ام، اگر فقط همین ده دستور را بلد باشید، ۹۰٪ کارهای روزمره GitHub را انجام می‌دهید. راهنمای عمیق‌تر در دستورات ضروری Git و دستورات ضروری CLI آمده است.

Commit: هنر ثبت تغییرات

Commit، ثبت یک تغییر در تاریخچه پروژه است. در تجربه‌ام، کیفیت Commit، تفاوت بین پروژه قابل نگهداری و پروژه آشوبناک را می‌سازد. سه اصل برای Commit مؤثر:

  1. کوچک و متمرکز: هر Commit باید یک تغییر منطقی مشخص باشد.
  2. پیام روشن: پیام Commit باید توضیح دهد چه چیزی تغییر کرده و چرا.
  3. بدون فایل‌های زائد: فایل‌های سیستم، فایل‌های بزرگ، اطلاعات حساس، نباید Commit شوند.
# پیام خوب
git commit -m "افزودن فرم ورود با اعتبارسنجی ایمیل"

# پیام بد
git commit -m "تغییر"

در پروژه‌ای که با یک تیم بزرگ کار می‌کردم، پیاده‌سازی قاعده Commit باعث شد پیدا کردن منبع یک باگ، از یک روز به یک ساعت کاهش پیدا کند. برای مطالعه بیشتر درباره استانداردهای کد، اصول کدنویسی تمیز، استانداردهای کدنویسی و خطاهای رایج Git راهنماهای مکمل هستند.

شاخه (Branch) و مدیریت موازی کار

شاخه (Branch)، امکان کار موازی روی پروژه بدون تأثیر روی نسخه اصلی را می‌دهد. در تجربه‌ام، کار با شاخه، سه مزیت روشن دارد:

  • آزمایش امن: ویژگی جدید را در شاخه جدا تست کنید.
  • کار موازی تیم: چند نفر روی ویژگی‌های مختلف کار کنند.
  • بازگشت آسان: اگر ویژگی موفق نبود، شاخه را حذف کنید.
git checkout -b feature/login-form
# کار روی ویژگی
git add .
git commit -m "افزودن فرم ورود"
git push origin feature/login-form

راهنمای کامل در برنچ در Git، یادگیری Git از commit تا merge و Pull Request در GitHub آمده است.

ادغام (Merge) و حل تعارض

ادغام (Merge)، ترکیب تغییرات یک شاخه با شاخه دیگر است. در تجربه‌ام، تعارض (Conflict) در ادغام، رایج‌ترین لحظه‌ای است که تازه‌کارها گم می‌شوند. سه گام حل تعارض:

  1. شناسایی فایل‌های متعارض: git status فایل‌های متعارض را نشان می‌دهد.
  2. باز کردن فایل و انتخاب نسخه درست: بین نسخه‌ها، یکی را انتخاب یا ترکیب کنید.
  3. ثبت تغییرات: بعد از حل، فایل را add و commit کنید.

راهنمای کامل در حل تعارض در Git و مرج در Git آمده است. در تجربه‌ام، هرچه تیم بیشتر با شاخه‌های کوچک و Commit‌های متمرکز کار کند، تعارض‌ها کمتر و ساده‌تر می‌شوند.

Pull Request: قلب همکاری تیمی

Pull Request (PR)، درخواست ادغام یک شاخه با شاخه اصلی است. در تجربه‌ام، PR قلب همکاری حرفه‌ای روی GitHub است. سه مزیت اصلی PR:

  • بازبینی کد: قبل از ادغام، همکاران تغییرات را بررسی می‌کنند.
  • بحث و تصمیم‌گیری: تغییرات بزرگ، در PR بحث می‌شوند.
  • مستندسازی تاریخچه: هر PR، یک بخش از تاریخچه پروژه است.

راهنمای کامل در Pull Request در GitHub و GitHub فراتر از میزبانی کد آمده است. در پروژه‌ای که با یک تیم بین‌المللی کار می‌کردم، استفاده منظم از PR، کیفیت کد را به‌طور چشمگیری بالا برد.

Pull Request، مثل یک جلسه رسمی است: هر تغییر، فرصت دارد که بحث شود، بهبود یابد و بعد به پروژه اصلی راه پیدا کند. تغییرات بدون PR، مثل تصمیم‌های پشت در بسته است.

README: آینه پروژه شما

README، فایل توضیحی پروژه است که در صفحه اصلی مخزن نمایش داده می‌شود. در تجربه‌ام، README خوب، تفاوت بین پروژه‌ای که کسی نمی‌فهمد و پروژه‌ای که همه به راحتی استفاده می‌کنند است. سه بخش اصلی README:

  1. معرفی کوتاه: پروژه چه کاری انجام می‌دهد و چرا.
  2. نصب و راه‌اندازی: چه گام‌هایی برای اجرا لازم است.
  3. مشارکت: چطور می‌توان به پروژه کمک کرد.

در پروژه‌ای که برای یک تیم داخلی می‌ساختم، اضافه کردن README خوب، سوالات تکراری در تیم را حدود ۵۰٪ کاهش داد. برای نوشتن مستندات، ابزارهای مدیریت کسب‌وکار و بهترین کدهای آماده وردپرس می‌توانند الهام‌بخش باشند.

GitHub Actions: اتوماسیون رایگان

GitHub Actions، ابزار اتوماسیون یکپارچه در GitHub است که امکان اجرای خودکار کارها را فراهم می‌کند. در تجربه‌ام، سه کاربرد اصلی GitHub Actions:

  • اجرای تست خودکار: هر بار که کد جدید push می‌شود، تست‌ها اجرا می‌شوند.
  • انتشار خودکار: بعد از ادغام PR، نسخه جدید منتشر می‌شود.
  • بازبینی خودکار کد: ابزارهای کیفیت کد، خودکار اجرا می‌شوند.

راهنمای کامل در GitHub Actions، ابزارهای CI/CD، CI/CD برای پروژه‌های وردپرس و CI/CD و تحول تحویل نرم‌افزار آمده است. در تجربه‌ام، GitHub Actions، بالاترین بازگشت سرمایه در بین ابزارهای CI/CD رایگان را دارد.

اشتباهات پرهزینه مبتدیان در GitHub

اشتباهاتی که در پروژه‌ها دیده‌ام و هر بار هزینه‌بر بوده‌اند:

  1. Commit کردن فایل‌های حساس: رمز، کلید API، فایل .env. این‌ها هرگز نباید در مخزن باشند.
  2. Commit کردن فایل‌های حجیم: فایل‌های باینری بزرگ، مخزن را کند و سنگین می‌کنند.
  3. پیام Commit مبهم: پیام «تغییر» یا «fix»، تاریخچه را بی‌فایده می‌کند.
  4. کار مستقیم روی main: در پروژه‌های تیمی، main باید همیشه پایدار باشد.
  5. نادیده گرفتن .gitignore: بدون .gitignore، فایل‌های غیرضروری وارد مخزن می‌شوند.

فهرست کامل در خطاهای رایج Git، اشتباهات رایج فریلنسرها، اشتباهات رایج توسعه وردپرس و اشتباهات رایج فرانت‌اند آمده است. برای ابزارهای تکمیلی، ابزارهای Git و GitHub برای تیم‌ها راهنمای عملی است.

پرسش‌های پرتکرار درباره شروع با GitHub

آیا برای استفاده از GitHub باید برنامه‌نویسی بلد باشم؟ بله، GitHub ابزاری برای برنامه‌نویسان است. اما در واقع، GitHub به برنامه‌نویسی معنا می‌دهد — بدون کنترل نسخه، کار حرفه‌ای در تیم تقریباً غیرممکن است. برای یادگیری پایه‌ها، آموزش Git از صفر و دستورات Git را ببینید.

آیا حساب GitHub رایگان است؟ بله، حساب رایگان برای اکثر کاربردها کافی است. مخازن عمومی رایگان، مخازن خصوصی رایگان با محدودیت‌های کوچک. برای تیم‌های بزرگ، پلن‌های پولی با ویژگی‌های اضافه وجود دارد. GitHub فراتر از میزبانی کد را ببینید.

آیا باید GitHub Desktop استفاده کنم یا خط فرمان؟ برای شروع، GitHub Desktop تجربه بهتری می‌دهد. اما در بلندمدت، یادگیری خط فرمان ضروری است چون کنترل و انعطاف بیشتری می‌دهد. راهنمای خط فرمان در دستورات ضروری CLI آمده است.

آیا مخزن خصوصی ارزش دارد؟ برای پروژه‌های شخصی و کلاینت، مخزن خصوصی حرفه‌ای‌تر است. برای پروژه‌های Open Source، مخزن عمومی انتخاب می‌شود. برای پروفایل حرفه‌ای، ترکیبی از هر دو توصیه می‌شود.

چطور پروژه‌ای را از GitHub به سرور منتقل کنم؟ GitHub فقط محلی برای ذخیره کد است، نه سرور اجرای آن. برای انتقال، می‌توانید از FTP، SSH یا ابزارهای CI/CD استفاده کنید. راهنما در CI/CD برای وردپرس و مدیریت سرور آمده است.

از اولین مخزن تا اولین همکاری حرفه‌ای

GitHub، ابزار ذخیره‌سازی نیست؛ پلی است بین شما و حرفه‌ای‌ترین شکل همکاری در نرم‌افزار. اگر امروز فقط یک گام بردارید، این باشد: یک مخزن بسازید و اولین پروژه کوچک خودتان را در آن قرار دهید، حتی اگر فقط یک فایل متن ساده باشد. همین شروع کوچک، مسیر بلندمدت شما را روشن می‌کند. اگر تجربه‌ای از شروع با GitHub دارید — چالش یا کامیابی — در دیدگاه‌ها بنویسید. تجربه‌های واقعی شما، برای توسعه‌دهندگان بعدی، از هر راهنمای عمومی ارزشمندتر است. 🐙