مخزن عمومی یا خصوصی؟ انتخاب آگاهانه روی GitHub
چه وقت repo را public کنید، پیامدهای تغییر visibility، امنیت، Actions، Pages و فورک طبق مستندات رسمی GitHub.
Founder & product engineer

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

پاسخ کوتاه
عمومی برای کدی که میخواهید جهان ببیند و فورک کند — با فرض نبود 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 از شما تأیید میخواهد که آثار را فهمیدهاید — آن متن را جدی بخوانید.
چکلیست قبل از عمومی کردن
- اسکن secret روی تمام تاریخچه؛ چرخش هر یافته.
- حذف دادهٔ مشتری، کلید، و پیکربندی محیط واقعی.
- بازبینی Issues/PR برای پیست تصادفی توکن.
- بازبینی Actions artifacts و لاگها.
- README و مجوز (LICENSE) مناسب.
- تصمیم دربارهٔ دامنهٔ پشتیبانی جامعه.
امنیت در هر دو حالت
| کنترل | Public | Private |
|---|---|---|
| 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
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
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.




