本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 附录：示例 ADR
<a name="appendix"></a>

**标题**

该决策定义了 ABC 应用程序开发的软件开发生命周期方法。

**状态**

已接受

**日期**

2022-03-11

**上下文**

ABC 应用程序是一个打包的解决方案，它通过部署包部署到客户的环境中。我们需要一个开发流程，使我们能够拥有可控的功能、修补程序和发布管道。

**决策**

我们使用[GitFlow工作流程](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)的改编版本来开发 ABC 应用程序。

![\[GitFlow 工作流程，适用于 ABC 示例应用程序\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/architectural-decision-records/images/gitflow-workflow.png)


为简单起见，我们不使用 `hotfix/*` 和 `release/*` 分支，因为 ABC 应用程序将被打包，而不是部署到特定环境中。因此，没有必要增加复杂性，以免妨碍我们快速做出反应，修复生产版本中的错误，或在单独的环境中测试版本。

以下是约定的分支策略：
+ 每个存储库必须有一个受保护的 `main` 分支，用于标记发布版本。
+ 每个存储库必须有一个受保护的 `develop` 分支，用于所有正在进行的开发工作。

**结果**

有利：
+ 调整 GitFlow 后的流程将使我们能够控制 ABC 应用程序的发布版本。

不利：
+ GitFlow 比基于主干的开发或 GitHub 流程更复杂，而且开销更大。

**合规性**
+ 每个存储库中的 `main` 和 `develop` 分支必须标记为 `Protected`。
+ 对 `main` 和 `develop` 分支的更改必须使用合并请求来传播。
+ 每个合并请求至少需要一次批准。

**备注**
+ 作者：Jane Doe
+ 版本：0.1
+ 更改日志：
  + 0.1：初始提议版本