FutureForgeFutureForge

خدمات FutureForge

  • طراحی و ساخت محصولاز شناخت نیاز تا انتشار محصول، یک مسیر روشن پیش رو دارید.
  • توسعه فول‌استکوب‌اپلیکیشن، API و داده را هماهنگ و یکپارچه توسعه دهید.
  • ممیزی مهندسیپیش از هزینه‌ی بیشتر، از وضعیت واقعی محصول‌تان باخبر شوید.
  • مشاوره معماریپیش از یک تصمیم فنی پرهزینه، گزینه‌ها را درست بسنجید.
  • زیرساخت و استقرارمحصول را با خیال راحت منتشر کنید و پایدار نگه دارید.
  • هوش مصنوعی در محصولهوش مصنوعی را فقط جایی به کار می‌گیریم که مسئله‌ای را حل کند.
نمونه‌کارهایادداشت‌هاقیمت‌گذاریدرباره ما
شروع گفتگو
  1. خانه
  2. /یادداشت‌ها
  3. /یادداشت‌ها
FutureForge

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

خدمات

طراحی سایت با وردپرستوسعه اختصاصیمهندسی محصولزیرساخت و استقرارمشاوره معماریهوش مصنوعی در محصول

راهنمای انتخاب

یادداشت‌هاقیمت‌گذاریتخمین هزینه پروژهمقایسه روش‌هانمونه‌کارهادرباره ماتماس

ارتباط

hello@futureforge.ir

ایده‌ای برای ساخت دارید؟

نیازتان را مطرح کنید تا درباره مسیر توسعه و قدم بعدی صحبت کنیم.

شروع گفتگو

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

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

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

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

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

دکمهٔ 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 است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.

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

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

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

خدمات مرتبط

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

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

برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟

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

سهیل ابراهیم‌پور
یادداشت‌ها
prompt injection در RAG
Embedding چیست؟
نمایش منبع در پاسخ هوش مصنوعی
RAG یا Fine Tuning؟ چارچوب انتخاب
خروجی ساختاریافته JSON از LLM

مهندسی محصول

prompt injection در RAG

۱۳ آبان ۱۴۰۵

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

Embedding چیست؟

۱۳ آبان ۱۴۰۵

مهندسی محصول

نمایش منبع در پاسخ هوش مصنوعی

۱۲ آبان ۱۴۰۵

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

RAG یا Fine Tuning؟ چارچوب انتخاب

۱۲ آبان ۱۴۰۵

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

خروجی ساختاریافته JSON از LLM

۱۱ آبان ۱۴۰۵
همه یادداشت‌ها315
معماری نرم‌افزار31
واژه‌نامه37
عملیات و استقرار94
مهندسی محصول122
راهنمای وب31
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
شروع گفتگو
ابزارهای رایگان
شروع گفتگو