在一个项目上工作，大量使用Feature，有时该应用程序需要3个开发人员。

我们尝试了几种方法，但是当我们合并git分支时，似乎经常“覆盖”彼此的功能更改。看来，冲突比比皆是，打破了功能模块，使它难以使用。

功能确实是为项目上的一个配置节省时间的绝佳工具，我非常确定有解决此问题的方法。

是否有工作流程或过程可以减少冲突和覆盖的风险？

欢迎提供有关功能的任何线索。

欢迎到土地˚F功能设定Ç onfiguration 中号 anagement，又名FCM！它不仅与功能有关，而且与配置管理（如Drupal版本8中引入的）无关。相反，它是一个特例小号 oftware Ç onfiguration 中号 anagement，又称单片机。主要是因为特征可被认为是一个码发生器，而需要通过多种环境中迁移的生成的代码。请阅读以获得更多详情。

1-使用功能的优缺点

使用功能的优点

• 自动将应用于Drupal开发站点的更改部署到一个或多个目标Drupal（预）生产站点（而不是手动部署）。
• 促进Drupal开发人员/站点构建者之间正在进行的Drupal开发的共享（装运）（例如，使由视图专家创建的某些视图可供在另一个开发站点中工作的Drupal Themer使用以该视图为主题的视图）。
• 与GIT和Drush紧密集成，可将功能部件（在开发站点上）生成的代码副本发送到选定的目标（预）生产站点。

使用功能的缺点

• 避免功能冲突和/或管理功能依赖关系可能是具有挑战性的！
• 在现有（生产）站点上开始使用功能并不容易。
• 安装/启用“ 功能”模块很容易（仅是一个模块），但是学习正确使用功能是一项重大挑战。

2-功能包装技术

使用功能取决于您自己的想象力，如何包装（组成）功能的内容。这里有一些可以使用的技术。

一个超级功能

这是一种非常简单的包装技术：将所有内容一起包装在一个功能部件中（有人称其为“上帝”功能部件...）。看起来很简单，很前卫，等等。但是这种技术也或多或少地导致“冲突”（如下所述）。

一个好的用例似乎是在创建“ Drupal发行版”时，其中假定其所有用户都使用相同的模块，配置等集合。但是，如果这种发行版包含多个网站功能（不要使用单词“ “功能” ...），将这些功能分为多个功能似乎更合适，如下所述。

基于网站功能

这种打包技术为网站的每个功能创建了单独的功能，例如：

• 功能A =实施“ *图库 ”。
• 功能B =实现“ *博客 ”。
• 功能C =实施“ *事件日历 ”。

基于Drupal管理部分

这种打包技术为用于创建站点的Drupal网站的每个（主要）管理部分创建了单独的功能，例如：

• 所有必需的模块都包含在功能A中，
• 所有基本字段定义都包含在功能B中，
• 所有内容类型都包含在功能C中，
• 所有权限都包含在功能D中，
• 所有角色都包含在功能E中，
• 所有变量都包含在功能F中，
• 所有（自定义）视图都包含在功能G中，
• 所有（自定义）规则都包含在功能H中，
• 等等。

上面的列表实际上是无限的：最后，您甚至可以将其视为每个Drupal管理菜单选项的一项功能……如果您想走的那么远的话。

IMO也是最推荐的打包功能方法。

3-减少功能和/或GIT中发生冲突的可能性

不要重复使用字段

在多种内容类型之间重用字段似乎引起了许多冲突。例如，在内容类型A中，您有一个具有计算机名称的字段field_somefield，该字段也用作内容类型B中具有相同计算机名称的field_somefield字段，但又作为另一种字段类型和/或其他一些不同的字段设置。

通过不重用内容类型之间的字段，可以避免出现此问题。查看有关内容类型和字段的机器名称的有趣命名约定，如包装信息体系结构和文档表所示，该表是有关“ Drupal的相对性模型 ”的文章的一部分。有关这方面的更多详细信息，请参阅我对“ 如何从以数据库为中心的角度对内容（类型）建模？ ”的答案。

拆分功能取决于谁在做什么

如果多个人在一个站点上工作，则可以通过根据谁在做什么来组织（=创建单独的）功能来减少冲突的数量。此示例可能如以下示例所示：

• 视图进入功能A，
• 规则进入功能B，
• 图表进入功能C，
• 关于主题的任何内容都包含在功能D中，

4-推荐的Drupal环境

以上所有内容均应有助于以某种方式促进Feature的使用。但是，为了确保一切都能按预期（设计）运行，出于以下原因，您还需要具有一组适当的环境（与逻辑相关的Drupal网站）：

• 合并多个功能提供的功能。
• 预测并解决冲突。
• 最终用户对经认证不存在任何冲突的所有合并功能进行的测试。

在理想的情况下，应该配置和使用这些与逻辑相关的Drupal网站，如下所示：

1. 个人开发站点 -每个网站开发人员都有一个单独的开发站点。当开发的某些部分准备好与其他人共享时，就会创建适当的功能，并将其传送到登台环境。
2. 沙盒站点 -这是一个Drupal环境，仅包含Drupal核心，用于对单个功能的完整性进行单元测试。如果某个功能意外地具有一些意外的依赖关系（例如，该功能依赖的某个模块，而在沙箱中未启用），则在此依赖关系将变得很清楚。
3. 暂存站点 -在此处交付一个或多个功能（在开发站点中创建）。它可能只是一些生产问题的修补程序，也可能是网站新版本的所有开发都已合并的地方。如果确实存在多个功能之间的任何冲突，那么这是它们将首先出现的环境...并且需要以某种方式解决。
4. 质量检查站点 -在暂存环境被认为是稳定的之后，该是继续使用相关功能并使它们在更高级别可用的时候了，这些功能可用于质量检查测试，验收测试，体积测试等。在此级别，您可以在允许进行任何其他更改（如果有）时应格外小心。因为任何此类更改都可能使此环境中已经完成的所有先前测试工作无效。
5. 影子生产站点 -要准备在实际生产中进行激活，您可能需要先将相关功能进一步推广到被认为是您的实际生产环境的副本（影子）的环境。如果此时在迁移过程中一切仍然中断，那么这是一个危险信号，它可以还原您之前的某些步骤。修复它，然后重试，直到所有相关方批准更改为止。
6. 生产站点 -如果您完成了所有先前的步骤，则此步骤应该可以自我解释，并且非常容易。根据您的需求，它可以是单个站点，也可以是等同于Drupal的多站点，而所涉及的所有站点都在运行所有功能的完全相同的版本。
7. 基准站点 -根据我的经验，使用这种类型的站点的Drupal实现也不多（如果有的话）。它只是生产站点的一个副本，但可供Drupal开发人员，测试人员等使用，可用于验证生产站点的外观或执行用户培训等。以及在任何时候进行新开发周期开始时，应使用此基准站点作为输入，以个人开发站点为目标，以某种方式“复制”将受影响（需要更改）的站点组件。

显然，以上有关Drupal网站类型的清单就像一个理想的世界。根据您的开发团队的规模和/或创建和维护它们的可用预算，可能不会全部使用（或负担得起）。此清单是根据SCM领域的最佳实践建模的，几乎适用于所有大型/跨国公司（银行，航空公司等）。

5-相关模块

强壮有力的手臂

Strongarm模块允许使用功能模块导出变量（将其设置存储在变量中的模块）。

节点导出

该节点输出模块允许用户导出节点，然后将其导入到另一个Drupal安装。

角色导出

该角色导出模块允许角色有machine_names并产生不同machine_name基于掀起了独特的作用ID（RID）。角色可以与功能一起导出，并且在其他站点上导入时也可以完全摆脱。

特点放逐

该功能放逐模块可完全排除个别功能部件从功能UI和功能的出口。以下是其项目页面中的报价：

 当您有一些功能部件要确保从不导出时，此模块很有用。如果您使用功能进行网站构建或部署，则可能会遇到有人意外导出时间戳变量（例如cron_last或update_last_check）的问题。您可能还希望取消开发人员模块的权限，以免开发人员模块被您要导出的其余站点权限困扰。被放逐的项目不会显示在功能模块或任何其他功能模块中，因此请谨慎使用。有关永远不应该导出的功能的中央列表，请参阅https://www.drupal.org/node/2400531

豆角，扁豆

该Bean的模块，使您的块导出。以下是其项目页面中的报价：

可以将Bean视为提供新类型的方法（与之相比，这是一种内容类型的节点），然后提供一个添加内容接口以创建所需数量的块（请参见下面的屏幕截图）。然后可以像其他任何块一样将Bean内容放置在站点周围。

该模块与UUID和UUID功能集成模块结合使用也非常有效。该模块仅从D7开始启动，但是已经包含在Drupal 8内核中。视频教程Drupal Bean模块教程-使用Bean Admin UI提供了一个很好的介绍，可以真正理解该模块的功能以及您可以使用该模块执行的操作（仅使用网站构建技术，不涉及自定义编码）。

栖息地

在基于功能的工作流程中，人居模块最有意义。以下是其项目页面中的报价：

在多环境设置（例如prod，test，dev，local）中，有些模块要始终在某些环境中启用或禁用。每次您向下同步数据库时，都必须重新启用/禁用相同的模块。更糟糕的是，您会变得懒惰，并在生产中启用开发模块。

栖息地提供了用于在每个环境（栖息地）上启用或禁用某些模块的设置。只需使用$ conf ['habitat'] ='local'设置变量；在settings.php文件中（要在其中使用的实际变量可以针对当前工作流程进行配置）。禁用/启用模块在hook_init上完成。

6-推荐资源：

• 有关功能的社区文档。
• 这个答案的一部分是基于（我认为很有趣）Features debat。
• 影片教学课程：
  • 创建特征。
  • 还原功能。
  • 更新功能。
  • 以正确的方式制作特征。
  • 功能的局限性。

7-使用功能的可能替代方法

如果您还不能（或尚未）使用Feature，那么您可能需要检查以下方法/模块的扩展范围，以提供某些替代方法。

手动导出/导入

这些是可通过admin UI使用的，针对Rule，Views等模块（不完整列表！）的常用功能（避免使用word features ... ）。

捆绑副本

有些人认为捆绑复制模块是一种可能的选择。它具有以下方面的进出口支持：

• 节点类型。
• 分类。
• 用户。
• 字段API字段。
• 字段组。

当多个开发人员将其配置集成到功能中时，合并冲突很可能会给定。我撰写了一些复习功能代码的准则，但我认为最重要的是：

仅提交预期的代码更改。

这是什么意思？这意味着每个开发人员都必须在提交之前检查代码。没有“魔术”可以防止在不小心开发人员的情况下意外更改代码。

• 使用检查代码更改git diff。
• 使用制作快速差异补丁git diff > blah.patch，然后手动修改补丁以仅包括预期的配置更改。
  • 诸如“ mtime”之类的信息，信息文件中视图导出中的注释等内容无需包含在提交中。
  • 随着时间的推移，我已经变得非常熟练于查看配置代码差异块。现在，更容易发现视图或面板中的多余更改，并且快速生成10ddVim即可消除补丁中的更改（例如）。
  • 我认为“哦，嘿，我没有更改任何与字段有关的内容，所以我不会提交featurename.features.field_base.inc。”
• 永远不要使用git commit -a。这是一种可怕的做法，应严格禁止使用。始终添加并明确提交！
• git rebase在本地 git分支上使用，以确保该功能是最新的。
• 实际进行合并时，git合并策略也可能会有所帮助：
  • git merge -s recursive -X patience （需要git 1.7+ iirc）。

最后，考虑对开发人员添加社会限制，以便开发人员必须先检查其代码，然后才能通过补丁程序审查或请求请求合并到主干/稳定表中。人们会对社会限制感到生气，但是他们应该为自己不对自己的法规进行审查而生气。