GitHub چیست و چه تفاوتی با Git دارد؟

GitHub یک پلتفرم میزبانی مخازن Git به‌همراه لایهٔ همکاری است: Issues، Pull Request، Code Review، Actions (CI)، Packages و ابزارهای سازمانی. Git خودش نرم‌افزار کنترل نسخه است که روی لپ‌تاپ یا سرور شما اجرا می‌شود. اشتباه رایج این است که بگوییم «کد را روی Git بگذار» وقتی منظور هاست وب است — معمولاً منظور GitHub (یا GitLab/Bitbucket) است.

مستندات رسمی GitHub در «About Git» صریح می‌گوید Git سیستم کنترل نسخه است و GitHub روی آن collaboration می‌سازد: مخزن، Branch، Commit، سپس Pull Request و Merge در جریان GitHub flow. کتاب Pro Git هم فصل جداگانه‌ای برای GitHub دارد چون محصول جدا از هستهٔ Git است.

اگر مقالهٔ ۰۷۰ را خوانده‌اید، پایهٔ Git را دارید. این صفحه مرز ابزار و پلتفرم را می‌کشد تا تصمیم بگیرید چه چیزی را باید یاد بگیرید و چه چیزی وابسته به فروشنده است.

پاسخ کوتاه

Git = موتور کنترل نسخه (محلی و توزیع‌شده). GitHub = سرویس ابری/میزبانی که مخزن Git شما را نگه می‌دارد و روی آن UI، دسترسی، بحث، بازبینی و اتوماسیون می‌گذارد. می‌توانید Git را بدون GitHub استفاده کنید (سرور خودتان، یا فقط محلی). نمی‌توانید «ویژگی‌های GitHub» را جایگزین یادگیری مفاهیم Git کنید؛ بدون فهم Commit و Branch، Pull Request فقط دکمه است.

جایگزین‌های رایج هاست: GitLab، Bitbucket، Gitea، سرور Git خام روی VPS. فرمان‌های روزانهٔ Git عمدتاً یکسان می‌مانند؛ تفاوت در Issue، Permission و CI است.

Git تاریخچه را می‌سازد؛ GitHub گفتگو و قواعد تیم را دور آن تاریخچه می‌چیند.

جدول تفاوت

GitHub دقیقاً چه چیزی اضافه می‌کند؟

میزبانی Remote

وقتی مخزن را Clone می‌کنید، معمولاً remote با نام origin به یک URL روی github.com اشاره دارد. Push و Pull همان پروتکل‌های Git (HTTPS/SSH) هستند؛ GitHub سرور طرف دیگر است. مستندات Pushing commits و Getting changes از GitHub Docs همین مدل را توضیح می‌دهند.

GitHub flow

طبق صفحهٔ GitHub flow: از Branch بسازید، Commit کنید، Pull Request باز کنید، بحث و Review کنید، سپس Merge به Branch اصلی. این جریان روی مفاهیم Git سوار است ولی «Pull Request» شیء محصول GitHub است (در GitLab معادل Merge Request؛ مقالهٔ ۰۷۸).

لایهٔ محصول و سازمان

• Issues و Discussions برای کار و گفتگو.
• Protected branch و Rules برای جلوگیری از Push مستقیم مخرب.
• Actions برای CI/CD روی رویدادهای Git.
• سازمان، تیم، SSO و audit در طرح‌های بالاتر.
• Marketplace اپ‌ها و یکپارچگی‌ها.

چه چیزهایی را با هم اشتباه نگیرید؟

• «اکانت GitHub دارم» ≠ «Git را بلدم». بدون CLI یا حداقل Desktop، فقط UI را دیده‌اید.
• Star و Fork محبوبیت اجتماعی‌اند؛ جایگزین کیفیت Commit و تست نیستند.
• Private بودن مخزن روی GitHub به‌معنی امنیت کامل Secret نیست؛ .env را Commit نکنید (مقالات ۰۸۱–۰۸۲).
• GitHub Desktop یا IDE همان Git را صدا می‌زنند؛ یادگیری مفهوم همچنان لازم است.

چه زمانی Git کافی است و GitHub لازم می‌شود؟

فقط محلی: اسکچ شخصی، آزمایش، یا مخزنی که عمداً آفلاین است — Gitalone کافی است. به‌محض اینکه نفر دوم، پشتیبان خارج از لپ‌تاپ، Review، یا CI لازم شد، به یک Remote host نیاز دارید. انتخاب GitHub به‌خاطر اکوسیستم، متن‌باز، و آشنایی بازار کار رایج است؛ الزام فنی مطلق نیست.

برای شرکت‌ها گاهی GitHub Enterprise یا جایگزین self-hosted به‌خاطر residency و سیاست امنیتی انتخاب می‌شود. معیار: دسترسی، Compliance، هزینه، و مهارت تیم — نه فقط برند.

مدل‌های همکاری روی GitHub

مستندات About Git دو الگوی اصلی را می‌گوید:

1. Shared repository: اعضای تیم مستقیم به یک مخزن دسترسی Write دارند؛ با Protected branch و PR کار می‌کنند.
2. Fork and pull: در متن‌باز رایج است؛ هر نفر Fork می‌سازد و با PR به بالادست پیشنهاد می‌دهد.

انتخاب الگو به اندازهٔ تیم و مرز اعتماد بستگی دارد. جزئیات Clone و Push در مقالات بعدی عملی می‌شود.

برای صاحب محصول / مدیر غیرفنی

وقتی مهندس می‌گوید «روی GitHub است»، بپرسید: مخزن خصوصی است یا عمومی؟ چه کسی Merge به main می‌کند؟ آیا PR اجباری است؟ Deploy از کدام Branch است؟ این پرسش‌ها ریسک را کم می‌کند بدون اینکه لازم باشد فرمان Git حفظ کنید.

GitHub جایگزین Jira/Trello کامل نیست هرچند Issues دارد؛ مرز ابزار کار در مقالات ۰۶۵–۰۶۹ بحث شده. همچنین GitHub جایگزین مستندسازی محصول نیست — README کمک می‌کند (مقالهٔ ۰۸۴) ولی PRD نیست.

مسیر یادگیری پیشنهادی

1. مفاهیم Git (۰۷۰) و یک مخزن محلی (۰۷۲).
2. ساخت حساب و مخزن خالی روی GitHub؛ اتصال remote add origin.
3. اولین Push و مشاهدهٔ تاریخچه در UI.
4. یک Branch، یک PR، یک Review کوتاه، Merge.
5. بعداً Actions و Protection — وقتی درد واقعی پیدا شد.

جمع‌بندی

Git موتور است؛ GitHub یکی از محبوب‌ترین اتاق فرمان‌های ابری دور آن موتور. تفاوت‌شان را قاطی نکنید تا هم مهارت قابل‌انتقال یاد بگیرید هم انتظارات درستی از پلتفرم داشته باشید. اگر امروز فقط یکی را می‌توانید تمرین کنید، اول Commit و Branch محلی را درست کنید؛ بعد همان را روی GitHub Push کنید.

ادامهٔ سری فرمان‌های همگام‌سازی و Branch را جدا می‌شکافد. منابع زیر صفحات رسمی‌اند.

لایه‌بندی مسئولیت: چه چیزی portable است؟

هرچه روی مفاهیم Git بسازید — Commit، Branch، Merge، Remotes — بین هاست‌ها قابل انتقال است. هرچه روی محصول GitHub بسازید — قالب خاص Issue، Actions YAML خاص، Apps مارکت‌پلیس — هزینهٔ مهاجرت دارد. این به‌معنی بد بودن GitHub نیست؛ یعنی باید آگاهانه وابسته شوید.

در تصمیم معماری سازمانی بپرسید: اگر سال بعد مجبور به تغییر هاست شویم، چه چیزی می‌ماند؟ تاریخچهٔ Git معمولاً می‌ماند؛ قوانین پیچیدهٔ Project و اتوماسیون UI ممکن است بازنویسی بخواهد. مستند کردن جریان PR و قواعد Branch در README تیم، وابستگی را شفاف می‌کند.

امنیت و حکمرانی روی GitHub — تصویر اولیه

GitHub برای مخازن Private دسترسی را کنترل می‌کند، ولی مسئولیت Secret همچنان با شماست. Commit کردن کلید API در مخزن خصوصی هم حادثه است؛ ابزارهای اسکن و مقالات ۰۸۱–۰۸۲ همین موضوع را عمیق می‌کنند. Protected Branch، Review اجباری، و جدا کردن محیط‌ها لایه‌های حکمرانی‌اند که روی Git خام باید خودتان بسازید.

برای شرکت‌ها، تفاوت طرح Free/Team/Enterprise در SSO، audit و سیاست‌های سازمانی است. قیمت و جزئیات را از صفحهٔ رسمی Pricing همان روز بخوانید؛ این مقاله عدد ثابت فروش نمی‌دهد چون عوض می‌شود.

مدل Fork در متن‌باز عالی است، ولی داخل شرکت کوچک گاهی Shared repository ساده‌تر است. انتخاب غلط مدل دسترسی باعث می‌شود یا گلوگاه مجوز داشته باشید یا هرج‌ومرج Push مستقیم.

GitHub در مسیر یادگیری توسعه‌دهنده

پروفایل GitHub برای بسیاری از استخدام‌کنندگان نمونهٔ کار است — نه تنها تعداد Star. مخزن‌های کوچک با README روشن، Commitهای خوانا، و چند PR واقعی معمولاً از ده پروژهٔ نیمه‌کاره بدون توضیح قوی‌ترند. اگر تازه‌کارید، از امروز مخازن تمرینی عمومی با محتوای امن بسازید.

در عین حال، فشار «همه‌چیز باید روی GitHub باشد» را با حریم خصوصی متعادل کنید: تمرین‌های شامل دادهٔ واقعی مشتری یا کلید را عمومی نکنید. Private و .gitignore بخشی از حرفه‌ای بودن است.

جایگزین‌ها را چگونه با انصاف مقایسه کنیم؟

• GitLab: غالباً CI و DevOps را در یک محصول عمیق‌تر یکپارچه می‌کند؛ برای self-host محبوب است.
• Bitbucket: در اکوسیستم Atlassian با Jira پیوند طبیعی دارد.
• Gitea/Forgejo و مشابه: سبک و قابل میزبانی خود؛ ویژگی اجتماعی کمتر.
• سرور Git خام روی SSH: حداکثر کنترل، حداقل UI همکاری.

معیار مقایسه: محل داده، هزینهٔ کل مالکیت، مهارت تیم، نیاز به UI بازبینی، و یکپارچگی CI. «همه GitHub دارند» دلیل کافی برای تیم تحت‌تحریم یا الزام residency نیست؛ «هیچ‌کس GitLab بلد نیست» هم می‌تواند هزینهٔ پنهان باشد.

چک‌لیست تصمیم برای هفتهٔ اول تیم

1. آیا مخزن اصلی Private است و چه کسانی Admin هستند؟
2. آیا main با Review محافظت می‌شود؟
3. آیا Secret در Actions یا جای دیگر چگونه تزریق می‌شود؟
4. آیا Issue همان سیستم کار ماست یا فقط مکمل Jira/Trello؟
5. آیا مسیر آنبوردینگ شامل Clone و اولین PR مستند شده؟

پاسخ به این پنج سؤال از ده‌ها تنظیم پیشرفتهٔ بلااستفاده مهم‌تر است. GitHub وقتی ارزش می‌دهد که قواعد تیم را اجرا کند، نه وقتی فقط جای ذخیرهٔ ZIP باشد.

Actions و Marketplace — ارزش و ریسک

GitHub Actions اجازه می‌دهد روی Push و PR خط CI اجرا شود. ارزشش در تکرارپذیری است؛ ریسکش در YAML پیچیده، Secretهای محیطی، و وابستگی به Actionهای شخص ثالث است. قبل از اضافه کردن Action از Marketplace، منبع، مجوز و نسخهٔ پین شده را ببینید.

Marketplace اپ‌ها می‌توانند Review، امنیت و مدیریت پروژه را گسترش دهند. هر اپ یعنی سطح حمله و دادهٔ بیشتر. اصل حداقل دسترسی اینجا هم صادق است: اول مسئله را بنویسید، بعد اپ را انتخاب کنید.

اگر هنوز CI ندارید، از یک workflow مینیمال تست شروع کنید نه از ماتریس ده‌سیستمی. پیچیدگی زودرس همان بدهی است که GitHub نتوانست جادویی حذفش کند.

سازمان، تیم و مخزن — واحدهای دسترسی

در GitHub، Organization مالک مجموعه‌ای از مخازن و تیم‌هاست. دسترسی را تا حد ممکن گروهی بدهید نه تک‌تک افراد روی هر مخزن. خروج نیرو باید با حذف از تیم، دسترسی را قطع کند.

مخازن آرشیو یا فقط‌خواندنی برای پروژه‌های مرده جلوی Commit تصادفی را می‌گیرد. نام‌گذاری یکدست مخازن (پیشوند تیم/محصول) هزینهٔ پیدا کردن را کم می‌کند.

برای پیمانکاران، دسترسی موقتی و محدود به مخزن لازم بدهید؛ Admin ندهید مگر دلیل مکتوب داشته باشید.

GitHub در قیاس با «فقط فایل روی سرور»

بعضی تیم‌ها هنوز با FTP یا اشتراک پوشه کار می‌کنند و GitHub را اضافهٔ تشریفاتی می‌دانند. واقعیت: هزینهٔ یادگیری اولیه Git کمتر از هزینهٔ یک بازیابی فاجعه‌بار بدون تاریخچه است. GitHub فقط این تاریخچه را قابل همکاری و بازبینی می‌کند.

اگر محدودیت تحریم یا شبکه دارید، گزینه‌های self-hosted را صادقانه ارزیابی کنید؛ اجبار به ابزاری که تیم نمی‌تواند به آن برسد، فرهنگ را به دور زدن می‌کشاند. دور زدن از مسیرهای ناامن (ارسال ZIP در پیام‌رسان) همان چیزی است که می‌خواستید با Git جلویش را بگیرید.

جمع‌بندی تصمیم برای انتخاب هاست

اگر تیم کوچک و نیاز به آشنایی بازار کار دارید، GitHub معمولاً مسیر کم‌اصطکاک است. اگر self-host و CI یکپارچه اولویت است، GitLab را در پایلوت بگذارید. اگر داخل اکوسیستم Atlassian هستید، Bitbucket را جدی مقایسه کنید. در هر حال Git را اول یاد بگیرید — هاست عوض می‌شود، مفاهیم می‌مانند.

بعد از انتخاب، سه قاعده را همان هفته بنویسید: نام Branch، الزام PR برای main، و ممنوعیت Secret در Commit. بدون این سه، بهترین هاست هم فقط درایو ابری شیک است.

سناریوهای واقعی انتخاب

استارتاپ سه‌نفره با محصول خصوصی: GitHub یا GitLab Private با PR اجباری معمولاً کافی است؛ وقت را صرف فرآیند فروش و کیفیت کنید نه تنظیمات بی‌پایان. شرکت با الزام نگهداری داده در محل: self-hosted را زودتر در پایلوت بگذارید. تیم متن‌باز محور: GitHub به‌خاطر شبکه و Fork/PR هنوز جاذبه دارد.

مهاجرت بین هاست‌ها ممکن است ولی دردناک است — Issues، Wiki، و Actions به‌اندازهٔ Git خام portable نیستند. پس انتخاب سال اول را با فرض ماندگاری دو تا سه ساله انجام دهید، نه با هیجان یک فیچر UI.

در نهایت، کیفیت همکاری به قوانین تیم وابسته است نه لوگو. GitHub بدون Review اجباری همان FTP با تاریخچه است؛ GitLab با قواعد روشن می‌تواند عالی باشد. ابزار را با رفتار بسنجید.

جمع‌بندی یک‌صفحه‌ای برای ذی‌نفع غیرفنی

Git تاریخچهٔ تغییرات را می‌سازد. GitHub جایی است که آن تاریخچه را می‌گذاریم تا تیم ببیند، درباره‌اش حرف بزند، و با قواعد Merge کند. وقتی می‌گوییم کار «روی GitHub است» یعنی روی Remote قابل‌مشاهده است، نه لزوماً روی سایت کاربر. وقتی می‌گوییم «Merge شد» یعنی وارد خط اصلی شده و آمادهٔ مسیر انتشار است — مگر flag یا محیط جلویش را بگیرد.

از تیم بخواهید وضعیت را با سه برچسب بگویند: فقط محلی، روی Remote در PR، روی main. این سه برچسب از ده‌ها پیام مبهم در چت مفیدتر است و هزینهٔ هماهنگی را کم می‌کند.

منابع و مراجع

• GitHub Docs — About Git — https://docs.github.com/en/get-started/using-git/about-git
• GitHub Docs — GitHub flow — https://docs.github.com/en/get-started/using-github/github-flow
• Pro Git — GitHub (فصل ۶) — https://git-scm.com/book/en/v2/GitHub-Account-Setup-and-Configuration
• Git Documentation — https://git-scm.com/docs
• Pro Git book — https://git-scm.com/book/en/v2