Вы можете использовать практики innersource для повышения сотрудничества и продуктивности в вашем предприятии. Innersource позволяет всем сотрудникам легко находить и повторно использовать работу. Это позволяет командам разработчиков учиться на работе друг друга, делиться опытом и избегать дублирования усилий по созданию общих сервисов.
Сделайте репозитории доступными для обнаружения
Если они не содержат конфиденциальную информацию, следует стремиться сделать хранилища видимыми для всех сотрудников.
Для этого поощряйте сотрудников использовать внутреннюю видимость, когда это возможно. Внутренняя видимость позволяет любому члену любой организации в предприятии просматривать репозиторий, независимо от того, является ли пользователь членом организации, владеющей репозиторием.
Также стоит установить разрешительные разрешения на базу для организаций. Политика базовых разрешений организации определяет уровень доступа членов этой организации ко всем репозиториям организации. Как правило, у организаций должно быть хотя бы разрешение на базу «Чтение», чтобы все члены организации могли видеть любой репозиторий. Владельцы организаций могут использовать команды для предоставления людям большего доступа к определённым репозиториям.
Если у вас есть более чувствительные репозитории, которые не должны быть широко заметны, вы можете создать выделенную организацию с более ограниченным базовым разрешением и добавить в неё конкретные команды.
Дополнительные сведения см. в разделе [AUTOTITLE и Сведения о репозиториях](/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization).
Документальные проекты
Организуйте и документируйте свои репозитории так, чтобы люди могли искать работу по всему предприятию.
**README** репозиторий эффективны, потому что они определяются в файлах репозитория, поэтому пользователи могут искать их, как в коде. Вы также можете создавать README на уровне учётной записи организации или предприятия, чтобы получить более глубокий обзор того, где можно найти разные проекты. Для более формальной внутренней документации рассмотрите возможность создания **сайта или вики-сайтов GitHub Pages****.**
Вы можете использовать темы репозиториев для группировки репозиториев, которые содержат определённый язык программирования, принадлежат определённой команде и так далее. Это ещё один способ упростить поиск репозиториев.
Дополнительные сведения можно найти здесь
-
[АВТОЗАГОЛОВКИ](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes), [АВТОЗАГОЛОВКИ](/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile#adding-a-member-only-organization-profile-readme) и [АВТОЗАГОЛОВКИ](/admin/managing-your-enterprise-account/creating-a-readme-for-an-enterprise) -
[AUTOTITLE](/pages/getting-started-with-github-pages/creating-a-github-pages-site) -
[AUTOTITLE](/communities/documenting-your-project-with-wikis/adding-or-editing-wiki-pages) -
[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics)
Создайте культуру для совместного использования работ
Поощряйте команды публиковать свою работу и делиться ресурсами с другими командами. GitHub имеет ряд функций, которые делают это проще. Например, команды могут:
- Используйте обсуждения , чтобы сделать их работу более заметной для других команд. См . раздел AUTOTITLE.
- Создайте выделенный внутренний репозиторий для обмена действиями и повторно используемых GitHub Actions рабочих процессов, к которым любой сможет обращаться при написании рабочего процесса внутри предприятия. См . раздел AUTOTITLE.
- Делитесь многоразовыми частями кода во внутренних пакетах с регистрами GitHub Packages . Для повышения безопасности вы можете предоставить GitHub доступ к этим реестрам. См . раздел AUTOTITLE.
- Создайте общие шаблоны и фреймворки в виде репозиториев , которые другие смогут скопировать для начала проекта. См . раздел AUTOTITLE.
Как и в случае с открытым исходным кодом, вы должны убедиться, что общие проекты имеют модель поддержки и чётко определённую команду сопровождающих, особенно для сервисов, от которых зависят многие части вашего предприятия. В идеале в команде сопровождающих будут представители различных команд, использующих сервис.
Скрыть контент от внешних соавторов
Если у вас есть внешние подрядчики или сотрудники, которым нужен доступ к проектам вашего предприятия, вы можете предоставить им другой уровень доступа, чем обычным сотрудникам.
В частности, вы можете захотеть скрыть внутренние репозитории от внешнего соавтора. Для этого выполните указанные ниже действия.
- Если вы используете Enterprise Managed Users, создайте аккаунт для пользователя в роли гостевого соавтора . Гостевые коллаборанты по умолчанию не имеют доступа к внутренним репозиториям, но получают базовые права в организациях, где их добавляют как участников. Их также можно добавлять в качестве соавторов репозиториев в репозиториях.
- Если вы не используете Enterprise Managed Users, добавьте пользователя как внешнего соавтора в необходимые репозитории, но убедитесь, что он не добавлен в качестве члена какой-либо организации.
Внешние коллаборационисты (если использовать Enterprise Managed Users называются репозиториями ) имеют доступ только к конкретному репозиторию. Эти пользователи не являются полноправными членами организации, поэтому не получают базового уровня доступа организации и не могут автоматически видеть внутренние репозитории предприятия, если не являются членами другой организации.
Дополнительные сведения см. в разделе [AUTOTITLE и Включение гостевых участников совместной работы](/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/adding-outside-collaborators-to-repositories-in-your-organization).