GitFlow：先合并到 master 还是在产品发布后合并？
GitFlow: merge to master first or after prod release?
学习 GitFlow 并且我有一些担忧，我没有看到在我读过的任何 docs/articles 中得到解决。
在某些时候 develop 分支上的代码需要部署到 QA/staging 环境并进行严格测试。因此，使用 GitFlow，您从 develop 中切出一个 release 分支，然后将 release 部署到所述暂存环境。
首先，只是想快速澄清一些事情：特定 project/repo 第一次经历这个过程时，您实际上 forking/creating 这个来自 release 的新分支develop，是？并且在未来的所有其他时间，您只是 merging develop 到 release，yes?
然后 QA 测试了暂存环境中的 release 分支，一切看起来都很好，我们准备好部署到 prod。你：
- 部署到产品并然后将
release合并到master？ ; 或
- 将
release 合并到 master 并 然后 部署到产品？
我问是因为在前一种情况下，您似乎 需要 将 release 分支部署到生产环境，然后部署到生产环境，然后合并到 master。这听起来不错，但通常生产环境和非生产环境并不相同，并且在暂存中运行得很好的代码在生产服务器上第二次启动时会发生阻塞。我知道 GitFlow 支持 hotfix branches 的概念，但它们是为小修复保留的。在需要 rollback/backout 发布的复杂修复的情况下，我们现在将 "dirty code"（由于某种原因破坏产品的代码）合并到 master.
在后一种情况下，从合并并放入产品发布请求到，可能需要数小时甚至数天（特别是如果您需要涉及 IT/Ops 来进行产品部署）产品部署实际发生的时间。在此期间，您有一个 master 分支，上面写着 "features X, Y and Z are in prod" 但实际上不是。
我想知道 GitFlow 是否真的以某种方式解决了这个问题，或者这两种情况的已知解决方法是什么。
您创建的发布分支是一个短暂的分支，类似于您创建的功能分支。发布完成后，删除分支。例如，我会创建一个 release/0.1.0 分支，完成工作，然后合并。
在部署到生产环境时，我总是从 master 分支中获取代码，这意味着我先将发布分支合并到 master 中，然后再进行部署。
GitFlow 更多的是前进，而不是后退。因此，为什么使用修补程序来修复已识别的问题。
就投入生产所需的时间而言，这确实不是 GitFlow 关心的问题，我认为它不会在这方面提供太多帮助。无论您使用哪种分支策略，这对您来说都是一个问题。
我工作的项目非常混乱，决策在分钟内发生变化，所以我的策略是尽可能拖延 软件配置管理决策。
特别是合并到 master 中：我们只有在部署到生产环境后才合并到 master 并且我们有一封确认电子邮件，表明冒烟测试有效很好。通过这种方式，我们通过管理决策变更、部署回滚、技术问题或任何可能发生的问题的风险来拥抱混乱。
一开始我们在生产之前合并到master，但是技术问题，回滚，最后一刻的管理决策......给我们带来了很多问题，所以我们改变了策略，并且一直有效最近 3 年都很好。
如果最终在投入生产后发现了一些回归，那就是 修补程序 并且必须像那样处理 :)
You'll actually be forking/creating this new release branch from develop, yes?
没错。第一次，您唯一的选择是从您的主分支创建 release 分支，这就是您要为 QA/Staging 部署的内容，稍后将部署到生产环境。
And that all other times in the future, you're simply merging develop into release, yes?
视情况而定。根据 Git Flow 的描述，发布分支是 short lived 分支。它可能仅从 develop 分支出来，并合并到 master。理论上，release 应该在您的发布完成后合并回 develop，然后被 删除 。您唯一应该合并到发行版中的是 hotfix。这是一个关于流程的干净利落的 article。
这因团队而异。我曾在完全遵循 Git 流程描述的团队工作，而其他团队则选择删除 release 并像第一次一样从开发中重新创建它。
Deploy to prod and then merge release into master?; or
Merge release to master and then deploy to prod?
理论上，master 应该总是 包含生产就绪代码，唯一保证的方法是部署到生产中的代码完全 主分支中有什么。也就是说，我们可能无法为您提供完美的答案，特别是对 您的 团队有效的方法。
例如，我目前在一个有 CI/CD 管道的团队工作，这让我们别无选择，只能合并之前：部署从 master 自动发生。我看到一些团队的发布相距太远，并且更有信心部署 release 分支并在之后合并。这避免了部署在 release -> master 合并期间发生的人为错误（这可能包括随着时间的推移建立起来的令人讨厌的冲突）。
我认为您应该选择最适合您的解决方案，因为 GitFlow 可能无法涵盖所有可能的场景和上下文。
从 master 部署适合小型商店。如果必须支持多个版本，则应从发布分支维护和部署。
学习 GitFlow 并且我有一些担忧，我没有看到在我读过的任何 docs/articles 中得到解决。
在某些时候 develop 分支上的代码需要部署到 QA/staging 环境并进行严格测试。因此，使用 GitFlow，您从 develop 中切出一个 release 分支，然后将 release 部署到所述暂存环境。
首先，只是想快速澄清一些事情：特定 project/repo 第一次经历这个过程时，您实际上 forking/creating 这个来自 release 的新分支develop，是？并且在未来的所有其他时间，您只是 merging develop 到 release，yes?
然后 QA 测试了暂存环境中的 release 分支，一切看起来都很好，我们准备好部署到 prod。你：
- 部署到产品并然后将
release合并到master？ ; 或 - 将
release合并到master并 然后 部署到产品？
我问是因为在前一种情况下，您似乎 需要 将 release 分支部署到生产环境，然后部署到生产环境，然后合并到 master。这听起来不错，但通常生产环境和非生产环境并不相同，并且在暂存中运行得很好的代码在生产服务器上第二次启动时会发生阻塞。我知道 GitFlow 支持 hotfix branches 的概念，但它们是为小修复保留的。在需要 rollback/backout 发布的复杂修复的情况下，我们现在将 "dirty code"（由于某种原因破坏产品的代码）合并到 master.
在后一种情况下，从合并并放入产品发布请求到，可能需要数小时甚至数天（特别是如果您需要涉及 IT/Ops 来进行产品部署）产品部署实际发生的时间。在此期间，您有一个 master 分支，上面写着 "features X, Y and Z are in prod" 但实际上不是。
我想知道 GitFlow 是否真的以某种方式解决了这个问题，或者这两种情况的已知解决方法是什么。
您创建的发布分支是一个短暂的分支，类似于您创建的功能分支。发布完成后，删除分支。例如，我会创建一个 release/0.1.0 分支，完成工作，然后合并。
在部署到生产环境时，我总是从 master 分支中获取代码，这意味着我先将发布分支合并到 master 中，然后再进行部署。
GitFlow 更多的是前进，而不是后退。因此，为什么使用修补程序来修复已识别的问题。
就投入生产所需的时间而言，这确实不是 GitFlow 关心的问题，我认为它不会在这方面提供太多帮助。无论您使用哪种分支策略，这对您来说都是一个问题。
我工作的项目非常混乱，决策在分钟内发生变化，所以我的策略是尽可能拖延 软件配置管理决策。
特别是合并到 master 中：我们只有在部署到生产环境后才合并到 master 并且我们有一封确认电子邮件，表明冒烟测试有效很好。通过这种方式，我们通过管理决策变更、部署回滚、技术问题或任何可能发生的问题的风险来拥抱混乱。
一开始我们在生产之前合并到master，但是技术问题，回滚，最后一刻的管理决策......给我们带来了很多问题，所以我们改变了策略，并且一直有效最近 3 年都很好。
如果最终在投入生产后发现了一些回归，那就是 修补程序 并且必须像那样处理 :)
You'll actually be forking/creating this new release branch from develop, yes?
没错。第一次，您唯一的选择是从您的主分支创建 release 分支，这就是您要为 QA/Staging 部署的内容，稍后将部署到生产环境。
And that all other times in the future, you're simply merging develop into release, yes?
视情况而定。根据 Git Flow 的描述，发布分支是 short lived 分支。它可能仅从 develop 分支出来，并合并到 master。理论上，release 应该在您的发布完成后合并回 develop，然后被 删除 。您唯一应该合并到发行版中的是 hotfix。这是一个关于流程的干净利落的 article。
这因团队而异。我曾在完全遵循 Git 流程描述的团队工作，而其他团队则选择删除 release 并像第一次一样从开发中重新创建它。
Deploy to prod and then merge release into master?; or Merge release to master and then deploy to prod?
理论上，master 应该总是 包含生产就绪代码，唯一保证的方法是部署到生产中的代码完全 主分支中有什么。也就是说，我们可能无法为您提供完美的答案，特别是对 您的 团队有效的方法。
例如，我目前在一个有 CI/CD 管道的团队工作，这让我们别无选择，只能合并之前：部署从 master 自动发生。我看到一些团队的发布相距太远，并且更有信心部署 release 分支并在之后合并。这避免了部署在 release -> master 合并期间发生的人为错误（这可能包括随着时间的推移建立起来的令人讨厌的冲突）。
我认为您应该选择最适合您的解决方案，因为 GitFlow 可能无法涵盖所有可能的场景和上下文。
从 master 部署适合小型商店。如果必须支持多个版本，则应从发布分支维护和部署。