Future ForgeFuture ForgeFuture ForgeFuture Forge
ServicesWorkPackagesFree toolsNotesAboutContact
Start
  1. Home
  2. /Notes
Future ForgeFuture Forge

Product engineering studio — design, build, and deploy software.

Discuss your project

Contact

hello@futureforge.ir09128464105
Future ForgeFuture Forge

Product engineering studio — design, build, and deploy software.

Services

Product engineeringFull-stack engineeringEngineering auditArchitecture consultingInfrastructure and deploymentAI in the product

Explore

WorkNotesFAQPackages

Free tools

Engineering auditArchitecture advisorProject estimatorPrompt tool

Company

AboutContactPrivacyTerms of use

Discuss your project

Describe the problem and the constraints. If there is a fit, we will schedule a conversation.

Discuss your project

Contact

hello@futureforge.ir09128464105
GitHubLinkedIn

© 2026 FutureForge. All rights reserved.

HomeServicesFree toolsStart
Glossary

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

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

SE
Soheil Ebrahimpour

Founder & product engineer

·Sep 20, 2026·5 min read
مخزن عمومی و خصوصی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

Author

SE

Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.

Related notes

Related notes

Categories

Related services

From note to project

If this topic is close to your product or system, we can talk about the real scope.

If you are unsure about architecture or the build path, we can talk about the project.

Describe the problem and the constraints. If there is a fit, we will schedule a conversation.

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

Operations

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

Sep 20, 2026

Software architecture

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

Sep 20, 2026

Operations

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

Sep 20, 2026

Product engineering

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

Sep 20, 2026

Product engineering

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

Sep 20, 2026
All notes219
Software architecture13
Glossary37
Operations87
Product engineering74
Web guide8
Product engineering
Full-stack engineering
Engineering audit
Architecture consulting
Infrastructure and deployment
Discuss your project
Free tools
Discuss your project