GitHub Enterprise Cloud的概念页将custom properties定义为附着于仓库或组织的结构化元数据。repository custom properties附着单个仓库，organization custom properties则附着enterprise中的组织。两者共用自定义属性这个名称，却把资料挂在不同对象上；仓库的项目详情与组织本身的描述，因而不是只换一个名字便能互换的记录。[1][2]
组织管理页进一步区分属性定义和仓库所记的值。定义里有名称、可选描述和类型，类型可以是字符串、单选、多选或真/假布尔值。单选和多选还带有允许值列表。一个字段先规定可表达什么，再由具体仓库对应其值；多选所容纳的一组选择，也与真或假这个二择类型保留不同的数据形态。[1]
默认值与显式值在required属性下同时出现。来源说，一项属性被要求覆盖全部仓库并设有默认值时，没有显式值的仓库会继承该默认值。因此，一份仓库资料中有值可读，仍可能来自属性定义上的默认内容；它并不独自证明这个仓库另行写过一项独有答案。这个区别围绕值的来源，不是对任何真实仓库的核验结果。[1]
Require explicit user-specified values又增加一层条件：在这一选项成立时，有权设置属性的用户和应用，在设置属性、新建或转移仓库时必须提供显式值。紧接的原文仍说，尚无显式值的仓库会继承默认值。要求显式提供与缺值时仍有继承，因而可以出现在同一份说明里；前者描述特定动作的要求，后者交代已有资料没有显式值时从哪里取得内容。[1]
外部属性则将来源指向GitHub之外，例如软件目录或内部开发者门户。概念页解释，外部系统应作为source of truth时，属性名称采用external_system.property_name这样的命名空间，以区分来源并避免与组织内其他属性混名；在GitHub侧又是只读的。来源名称与可编辑位置一起保留了这项资料的归属，而不是把外部内容写进来以后就视为GitHub本地独立维护的值。[1][2]
同一概念页还限定，外部属性可以用在标准仓库属性所用的相同位置，却不适用于附着于组织的organization custom properties。由此，外部属性的用途和附着对象各有一项条件：可与仓库属性同处使用，没有把最初区分的仓库、组织两种对象消除。[2]
属性能被谁看见，另随仓库可见性而定。公开仓库的自定义属性可由任何人查看；内部或私有仓库的属性则面向有该仓库read权限的账户。管理页还说明，能查看某仓库属性值的人不能仅凭这一读取身份编辑这些值。读到一项元数据与能维护该值，是来源分别陈述的关系，本篇没有据此为账户设置或扩大权限。[1]
两项新能力的状态也分别标明：外部custom properties，以及Copilot为单选、多选属性建议允许值，都属public preview。后者建议的是属性定义的候选值列表；这与某一仓库是否已经具有一个显式值，仍是不同对象。不能把建议列表的存在当作GitHub已验证仓库的实际业务情况。[1]
本文采用本次Enterprise Cloud latest公开文字，不执行属性设置、同步、搜索命令或API调用，也不据元数据判断安全或法律合规。两页首次发布日期均未知。[1][2]
信息来源
- GitHub Docs — Enterprise Cloud：Managing custom properties for repositories in your organization
- GitHub Docs — Enterprise Cloud：Custom properties
本文基于上述公开资料整理，未使用来源页面的图片、视频或嵌入媒体。