Future ForgeFuture ForgeFuture ForgeFuture Forge
خدماتنمونه‌کارهاپکیج‌هاابزارهای رایگانیادداشت‌هادرباره ماتماس
شروع پروژه
  1. خانه
  2. /یادداشت‌ها
Future ForgeFuture Forge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

پروژه‌تان را مطرح کنید

ارتباط

hello@futureforge.ir09128464105
Future ForgeFuture Forge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

خدمات

طراحی و ساخت محصولتوسعه فول‌استکممیزی مهندسیمشاوره معماریزیرساخت و استقرارهوش مصنوعی در محصول

کاوش

نمونه‌کارهایادداشت‌هاپرسش‌هاپکیج‌ها

ابزارهای رایگان

ممیزی مهندسیمشاور معماریتخمین پروژهابزار پرامپت

شرکت

درباره ماتماسحریم خصوصیشرایط استفاده

پروژه‌تان را مطرح کنید

مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ می‌کنیم.

پروژه‌تان را مطرح کنید

ارتباط

hello@futureforge.ir09128464105
GitHubLinkedIn

© 2026 FutureForge. همه حقوق محفوظ است.

خانهخدماتابزارهای رایگانشروع پروژه
واژه‌نامه

مخزن عمومی یا خصوصی؟ انتخاب آگاهانه روی GitHub

چه وقت repo را public کنید، پیامدهای تغییر visibility، امنیت، Actions، Pages و فورک طبق مستندات رسمی GitHub.

سا
سهیل ابراهیم‌پور

بنیان‌گذار و مهندس محصول

·۲۹ شهریور ۱۴۰۵·5 دقیقه مطالعه
مخزن عمومی و خصوصیpublic repoprivate repovisibilityopen sourceGitHub Freefork
تنظیمات visibility و استیکی Public و Private

دکمهٔ Change visibility در تنظیمات مخزن ساده به نظر می‌رسد، ولی طبق مستندات GitHub پیامدهای زنجیره‌ای دارد: فورک‌ها، ستاره‌ها، Pages، Actions logs، ویژگی‌های امنیتی، و حتی Archive Program. «اول private بسازیم بعداً عمومی می‌کنیم» بدون چک‌لیست، یکی از منابع رایج نشت کد داخلی و secret است.

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

مقایسه OSS و IP داخلی؛ چه وقت public مناسب است

پاسخ کوتاه

عمومی برای کدی که می‌خواهید جهان ببیند و فورک کند — با فرض نبود secret و دادهٔ مشتری. خصوصی برای محصول، زیرساخت داخلی، و هر چیزی که هنوز برای افشا آماده نیست. قبل از public کردن: تاریخچه را برای secret اسکن کنید، لاگ Actions را در نظر بگیرید، و .env و کلیدها را حذف/بچرخانید. تغییر visibility را از Danger Zone فقط پس از خواندن پیامدها بزنید.

خصوصی بودن به‌معنای بی‌نیازی از انضباط امنیتی نیست.

تعریف عملی

  • Public: هر کسی روی GitHub می‌تواند بخواند (و معمولاً فورک کند).
  • Private: فقط افراد/تیم‌های مجاز.
  • Internal (در Enterprise): دید در سطح سازمان/enterprise.

مجوز نوشتن جدا از visibility است؛ مخزن عمومی هم می‌تواند push را محدود کند.

چه وقت عمومی منطقی است

  • کتابخانه، ابزار، مستند، نمونهٔ آموزشی.
  • ساخت اعتبار مهندسی و جذب مشارکت.
  • شفافیت عمدی برای جامعه یا مشتری (با مرز مشخص).

عمومی بودن secret scanning رایگان و برخی قابلیت‌های امنیتی را به‌همراه دارد، ولی همزمان سطح حملهٔ اطلاعاتی را بالا می‌برد: ساختار سیستم، وابستگی‌ها، و تاریخچهٔ اشتباهات دیده می‌شود.

چه وقت خصوصی بمانید

  • کد محصول و منطق کسب‌وکار حساس.
  • زیرساخت به‌عنوان کد با آدرس‌ها و سیاست‌های داخلی.
  • پروژه‌ای که هنوز پاک‌سازی تاریخچه/secret نشده.
  • کار مشتری تحت NDA.

پیامدهای تغییر visibility (خلاصهٔ Docs)

از public به private

  • فورک‌های عمومی جدا می‌شوند و عمومی می‌مانند؛ خودبه‌خود خصوصی نمی‌شوند.
  • در طرح‌های Free ممکن است برخی ویژگی‌ها محدود شوند؛ GitHub Pages منتشرشده ممکن است unpublish شود.
  • ستاره‌ها و watcherها پاک می‌شوند و رتبه اثر می‌بیند.
  • خروج از GitHub Archive Program.
  • برخی قابلیت‌های Advanced Security در private نیازمند مجوز مناسب سازمان‌اند.

از private به public

  • کد برای همه قابل مشاهده و معمولاً قابل فورک می‌شود.
  • تاریخچه و لاگ Actions برای عموم دیده می‌شود؛ مسیر workflowهای اشتراکی ممکن است در لاگ نمایان شود.
  • push rulesetها ممکن است غیرفعال شوند (طبق Docs).
  • ستاره‌ها/watcherها پاک می‌شوند.
  • فورک‌های private جدا و مستقل می‌شوند.

قبل از تغییر، GitHub از شما تأیید می‌خواهد که آثار را فهمیده‌اید — آن متن را جدی بخوانید.

چک‌لیست قبل از عمومی کردن

  1. اسکن secret روی تمام تاریخچه؛ چرخش هر یافته.
  2. حذف دادهٔ مشتری، کلید، و پیکربندی محیط واقعی.
  3. بازبینی Issues/PR برای پیست تصادفی توکن.
  4. بازبینی Actions artifacts و لاگ‌ها.
  5. README و مجوز (LICENSE) مناسب.
  6. تصمیم دربارهٔ دامنهٔ پشتیبانی جامعه.

امنیت در هر دو حالت

کنترلPublicPrivate
gitignore و عدم hardcodeحیاتیحیاتی
secret scanningپیش‌فرض قویبسته به طرح/تنظیم
branch protectionتوصیه می‌شودتوصیه می‌شود
کمینه دسترسی collaboratorلازملازم
فرض دشمن خوانندهٔ کدبلهبرای خودی‌های زیاد هم مفید

مدل کسب‌وکار و طرح GitHub

روی حساب‌ها و سازمان‌های Free، تعداد و ویژگی مخازن private در طول زمان تغییر کرده؛ قبل از اتکا به یک قابلیت (Pages، فضای Actions، protected branch پیشرفته) صفحهٔ طرح‌ها را برای تاریخ روز خودتان چک کنید. تصمیم معماری را به یک افسانهٔ قدیمی «private فقط پولی است» گره نزنید.

سازمانی: سیاست visibility

مالکان سازمان می‌توانند تغییر visibility را محدود کنند تا کسی مخزن داخلی را تصادفی عمومی نکند. این کنترل مدیریتی را برای شرکت‌ها جدی بگیرید.

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

  • عمومی کردن برای «نمونه کار» بدون پاک‌سازی تاریخچه.
  • فرض اینکه private یعنی کسی کد را نمی‌بیند پس API key اشکالی ندارد.
  • تغییر به private و خیال اینکه فورک‌های عمومی محو شده‌اند.
  • نادیده گرفتن دیده شدن لاگ CI پس از public شدن.

خلاصه

عمومی و خصوصی برچسب دسترسی خواندن‌اند، نه گواهی امنیت. انتخاب را بر اساس مخاطب و حساسیت داده انجام دهید، تغییر visibility را با چک‌لیست Docs پیش ببرید، و در هر دو حالت انضباط secret و حفاظت شاخه را نگه دارید.

سوالات متداول

می‌توان بخشی از مخزن را عمومی کرد؟

معمولاً با جدا کردن مخزن/پکیج عمومی از هستهٔ خصوصی، نه با نیمه‌visibility روی یک repo.

Internal چه فرقی با private دارد؟

در سطح enterprise، دید پیش‌فرض برای اعضای enterprise گسترده‌تر از private کلاسیک است؛ Docs همان سازمان را بخوانید.

برای نمونه کار شخصی چه کنم؟

مخزن جدا با کد پاک، دادهٔ جعلی، و بدون تاریخچهٔ شرکتی.

منابع و مراجع

  • GitHub Docs — Setting repository visibility: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility
  • GitHub Docs — About repositories: https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories
  • GitHub Docs — Quickstart for securing your repository: https://docs.github.com/en/code-security/getting-started/quickstart-for-securing-your-repository
  • GitHub Docs — GitHub's plans: https://docs.github.com/en/get-started/learning-about-github/githubs-products

نویسنده

سا

سهیل ابراهیم‌پور بنیان‌گذار FutureForge است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.

یادداشت‌های مرتبط

یادداشت‌های مرتبط

دسته‌بندی‌ها

خدمات مرتبط

از یادداشت تا پروژه

اگر موضوع این مقاله به سیستم یا محصول شما نزدیک است، می‌توانیم درباره دامنه واقعی صحبت کنیم.

اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، می‌توانید درباره پروژه صحبت کنیم.

مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ می‌کنیم.

سهیل ابراهیم‌پور
یادداشت‌ها
لینوکس چیست و چرا بخش بزرگی از اینترنت روی لینوکس اجرا می‌شود؟
Monolith در برابر Microservices: کدام را انتخاب کنیم؟
Logging چیست؟ ثبت رویداد برای تشخیص و پاسخ به حادثه
Empty State، Error State و Loading State چیست؟
UX مهم‌تر است یا UI؟

عملیات و استقرار

لینوکس چیست و چرا بخش بزرگی از اینترنت روی لینوکس اجرا می‌شود؟

۲۹ شهریور ۱۴۰۵

معماری نرم‌افزار

Monolith در برابر Microservices: کدام را انتخاب کنیم؟

۲۹ شهریور ۱۴۰۵

عملیات و استقرار

Logging چیست؟ ثبت رویداد برای تشخیص و پاسخ به حادثه

۲۹ شهریور ۱۴۰۵

مهندسی محصول

Empty State، Error State و Loading State چیست؟

۲۹ شهریور ۱۴۰۵

مهندسی محصول

UX مهم‌تر است یا UI؟

۲۹ شهریور ۱۴۰۵
همه یادداشت‌ها219
معماری نرم‌افزار13
واژه‌نامه37
عملیات و استقرار87
مهندسی محصول74
راهنمای وب8
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
پروژه‌تان را مطرح کنید
ابزارهای رایگان
پروژه‌تان را مطرح کنید