Open XXHolic opened 4 years ago
这是 GitHub flow 之后的第三篇资料。选择了个人认为必要的部分，并进行了部分顺序重组。
GitLab 流把 feature-driven development 和 feature branches 与 issue 跟踪结合起来，将 Git 工作流与 issue 跟踪系统集成在一起。它提供了使用 Git 的简单、透明和有效的方法。原文见 Introduction to GitLab Flow。
GitHub 流假设每次你合并一个功能分支，就可以发布到生产。虽然在一些情况下，这个是可能的，例如 SaaS 应用，然而也有许多情况这是行不通的。一种情况就是你不能控制发布的时间，例如 IOS 应用发布需要经过审核。另外一种情况是，当你部署有窗口期（例如才做团队工作日从上午 10 点到下午 4 点满负荷工作），但是你可以在其它时间合并代码。
在这些情况下，你可以创建反映已部署代码的 production 分支。你可以通过合并 master 分支到 production 分支来发布一个新版本。如果你需要知道那些代码在生产，你只需要切换到 production 分支进行查看。由于合并的记录在版本控制系统中，部署的大致时间很容易看到。如果你自动部署 production 分支，这个时间就相当准确。如果你需要更精确的时间，你可以让部署脚本在每次部署时创建一个标签。这个流程防止了 Git 流发布、标记和合并的开销。
有一个能够自动更新到 master 分支的环境，可能是一个好的主意。只是在这种情况下，这个环境可能由于分支名称不同而不同。假设你有一个演示环境、一个预发布生产环境和一个生产环境。在这种情况下，部署 master 分支到演示环境。如果要部署到预发布生产环境，就创建一个从 master 合并到 pre-production 分支的请求。到线上就把 pre-production 分支合并到 production 分支。
这个工作流中提交只会向下流动，可确保所有环境的所有内容是经过测试的。如果需要选择一个热修复提交，通常在功能分支上开发它，并通过一个合并请求将其合并到 master 。在这种情况下，请不要删除功能分支。如果 master 通过了自动测试，则可以将功能分支合并到其它分支中。如果需要更多的手动测试，你可以将合并请求从功能分支发送到下游分支。
如果你需要发布软件到外部世界，你只需要在 release 分支上工作。在这种情况下，每个分支都包含一个次要版本，例如 2-3-stable、2-4-stable 等。使用 master 作为起点创建稳定的分支，并尽可能晚地创建分支。通过这样做，你可以最小化将错误修复应用于多个分支的时间长度。
在宣布有了 release 分支之后，只在这个分支上修复验证的 bug 。如果可能，首先将这些 bug 修复合并到 master，并且 cherry-pick 到 release 分支。如果你一开始就合并到 release 分支，可能会忘记将它们 cherry-pick 到 master，那么在随后的发布中会遇到相同的 bug 。合并到 master ，然后 cherry-pick 到 release 的这种做法叫做“上游优先”策略，Google 和 Red Hat 也采用这一策略。
每次在 release 分支中 bug 修复时，通过设置新标记来提升一个版本（以符合语义版本控制）。有些项目还有一个稳定的分支，指向与最新发布的分支相同的提交。在这个流程中，拥有一个 production 分支（或 Git 流 master 分支）并不常见。
当创建 feature 分支时，始终基于最新的 master 分支。如果你在开始之前知道你的工作依赖于另一个分支，你也可以基于那个分支创建。如果开始后需要合并到另一个分支，请在合并提交中解释原因。如果尚未将提交推送到共享的地方，也可以通过在 master 或其它 feature 分支上重新定位来合并更改。如果你的代码可以工作，且在不执行此操作的情况下干净地进行合并，请不要再次从上游进行合并。仅在需要时进行合并，可防止在 feature 分支中生成合并提交，这些提交将导致 master 历史记录变得凌乱。
当你准备合并功能分支时，请将合并请求分配给最了解你正在更改的代码库的人。另外，可以提及你希望获得反馈的任何其他人。当被分配者对结果感到满意后，他们可以合并分支。如果被指派的人员感觉不满意，他们可以要求更多的更改或关闭合并请求。
在 GitLab 中，通常会保护长时间存在的分支（如 master 分支），这样大多数开发人员就无法修改它们。因此，如果要合并到受保护的分支，请将合并请求分配给具有维护者权限的人。
合并功能分支后，应将其从源代码管理软件中删除。在 GitLab 中，可以在合并时执行此操作。删除已完成的分支可确保分支列表仅显示正在进行的工作。它还确保，如果有人重新打开问题，他们可以使用相同的分支名称，而不会导致问题。
在旧的工作流中，持续集成（CI）服务器通常只在 master 分支上运行测试。开发人员必须确保他们的代码不会破坏 master 分支。当使用 GitLab 流时，开发人员基于 master 分支创建分支，因此基本上是不会破坏的。所以，在接受每个合并请求之前，必须对其进行测试。像 Travis CI 和 GitLab CI 这样的 CI 软件会在合并请求本身中显示构建结果，这样做很容易。
测试合并请求有一个缺点：CI 服务器只测试功能分支本身，而不是合并的结果。理想情况下，服务器还可以在每次更改后测试 master 分支。但是，在每次提交到 master 时重新测试都会在计算上花费很大，这意味着你更频繁地等待测试结果。由于功能分支应该是短期存在的，因此只测试这个分支是一个可接受的风险。如果 master 中的新提交导致与功能分支合并产生冲突，请将 master 合并回分支，以使 CI 服务器重新运行测试。如前所述，如果你经常有持续几天以上的功能分支，则应使分解为更小的 issue 。
GitLab 流是一种使代码和 issue 跟踪之间的关系更加透明的方式。
对代码任何有意义的更改都应该从描述目标的 issue 开始。对每一个代码更改都有一个解释，这有助于团队的其他成员理解，并保持功能分支的范围较小。在 GitLab 中，对代码库的每次更改都从 issue 跟踪系统中的一个 issue 开始。只要更改需要一定量的工作，即超过 1 小时，如果还没有 issue ，则创建 issue 。在许多组织中，提出 issue 是开发过程的一部分，因为它们用于冲刺规划。issue 标题应描述系统所需的状态。例如，issue 标题“作为管理员，我希望在不收到错误的情况下删除用户”比“管理员无法删除用户”要好。
准备好编写代码后，从 master 分支创建 issue 相关的分支。此分支是与此更改相关工作的位置。
当你完成或想要讨论代码时，发起一个合并请求。合并的请求是在线讨论更改和检查代码的的地方。
如果发起合并请求但未将其分配给任何人，则它是一个“正在处理”的合并请求。它们用于讨论提议的实现，但尚未准备好包含到 master 分支中。合并请求的标题用 [WIP] 或 WIP: 开头，以防止它在准备就绪之前被合并。
[WIP]
WIP:
当您认为代码已准备就绪时，将合并请求分配给一个审阅者。当审阅者认为代码已准备好包含在 master 分支时，就可以合并更改。当他们按下合并按钮时，GitLab 合并代码并创建一个合并 commit 记录，使该事件在以后很容易查看。合并请求总是创建一个合并 commit 记录，即使在没有合并提交的情况下也可以合并分支。这种合并策略在 Git 中称为“不快进”。合并后，删除对应功能分支，因为不再需要它。在 GitLab 中，此删除是合并时的一个选项。
假设合并了一个分支，但出现了问题并重新打开了该 issue 。在这种情况下，重用相同的分支名称是没有问题的，因为合并时删除了第一个分支。任何时候，每个 issue 最多只能有一个分支。一个功能分支可能解决多个 issue 。
在 commit 信息或合并请求的描述中，可以关联 issue ，例如 “Fixes #16” or “Duck typing is preferred. See #12.”
通过关键字 “fixes” 或 “closes” ，可以自动关闭 issue ，例如 “fixes #14” or “closes #67.”。
如果你有一个 issue 关联了多个库，那么在每个库里面创建一个 issue，并把这些 issue 关联到一个父级 issue 。
目录
引子
这是 GitHub flow 之后的第三篇资料。选择了个人认为必要的部分，并进行了部分顺序重组。
简介
GitLab 流把 feature-driven development 和 feature branches 与 issue 跟踪结合起来，将 Git 工作流与 issue 跟踪系统集成在一起。它提供了使用 Git 的简单、透明和有效的方法。原文见 Introduction to GitLab Flow。
Production 分支
GitHub 流假设每次你合并一个功能分支，就可以发布到生产。虽然在一些情况下，这个是可能的，例如 SaaS 应用，然而也有许多情况这是行不通的。一种情况就是你不能控制发布的时间，例如 IOS 应用发布需要经过审核。另外一种情况是，当你部署有窗口期（例如才做团队工作日从上午 10 点到下午 4 点满负荷工作），但是你可以在其它时间合并代码。
在这些情况下，你可以创建反映已部署代码的 production 分支。你可以通过合并 master 分支到 production 分支来发布一个新版本。如果你需要知道那些代码在生产，你只需要切换到 production 分支进行查看。由于合并的记录在版本控制系统中，部署的大致时间很容易看到。如果你自动部署 production 分支，这个时间就相当准确。如果你需要更精确的时间，你可以让部署脚本在每次部署时创建一个标签。这个流程防止了 Git 流发布、标记和合并的开销。
Environment 分支
有一个能够自动更新到 master 分支的环境，可能是一个好的主意。只是在这种情况下，这个环境可能由于分支名称不同而不同。假设你有一个演示环境、一个预发布生产环境和一个生产环境。在这种情况下，部署 master 分支到演示环境。如果要部署到预发布生产环境，就创建一个从 master 合并到 pre-production 分支的请求。到线上就把 pre-production 分支合并到 production 分支。
这个工作流中提交只会向下流动，可确保所有环境的所有内容是经过测试的。如果需要选择一个热修复提交，通常在功能分支上开发它，并通过一个合并请求将其合并到 master 。在这种情况下，请不要删除功能分支。如果 master 通过了自动测试，则可以将功能分支合并到其它分支中。如果需要更多的手动测试，你可以将合并请求从功能分支发送到下游分支。
Release 分支
如果你需要发布软件到外部世界，你只需要在 release 分支上工作。在这种情况下，每个分支都包含一个次要版本，例如 2-3-stable、2-4-stable 等。使用 master 作为起点创建稳定的分支，并尽可能晚地创建分支。通过这样做，你可以最小化将错误修复应用于多个分支的时间长度。
在宣布有了 release 分支之后，只在这个分支上修复验证的 bug 。如果可能，首先将这些 bug 修复合并到 master，并且 cherry-pick 到 release 分支。如果你一开始就合并到 release 分支，可能会忘记将它们 cherry-pick 到 master，那么在随后的发布中会遇到相同的 bug 。合并到 master ，然后 cherry-pick 到 release 的这种做法叫做“上游优先”策略，Google 和 Red Hat 也采用这一策略。
每次在 release 分支中 bug 修复时，通过设置新标记来提升一个版本（以符合语义版本控制）。有些项目还有一个稳定的分支，指向与最新发布的分支相同的提交。在这个流程中，拥有一个 production 分支（或 Git 流 master 分支）并不常见。
Feature 分支
当创建 feature 分支时，始终基于最新的 master 分支。如果你在开始之前知道你的工作依赖于另一个分支，你也可以基于那个分支创建。如果开始后需要合并到另一个分支，请在合并提交中解释原因。如果尚未将提交推送到共享的地方，也可以通过在 master 或其它 feature 分支上重新定位来合并更改。如果你的代码可以工作，且在不执行此操作的情况下干净地进行合并，请不要再次从上游进行合并。仅在需要时进行合并，可防止在 feature 分支中生成合并提交，这些提交将导致 master 历史记录变得凌乱。
Merge/pull 请求
当你准备合并功能分支时，请将合并请求分配给最了解你正在更改的代码库的人。另外，可以提及你希望获得反馈的任何其他人。当被分配者对结果感到满意后，他们可以合并分支。如果被指派的人员感觉不满意，他们可以要求更多的更改或关闭合并请求。
在 GitLab 中，通常会保护长时间存在的分支（如 master 分支），这样大多数开发人员就无法修改它们。因此，如果要合并到受保护的分支，请将合并请求分配给具有维护者权限的人。
合并功能分支后，应将其从源代码管理软件中删除。在 GitLab 中，可以在合并时执行此操作。删除已完成的分支可确保分支列表仅显示正在进行的工作。它还确保，如果有人重新打开问题，他们可以使用相同的分支名称，而不会导致问题。
合并之前测试
在旧的工作流中，持续集成（CI）服务器通常只在 master 分支上运行测试。开发人员必须确保他们的代码不会破坏 master 分支。当使用 GitLab 流时，开发人员基于 master 分支创建分支，因此基本上是不会破坏的。所以，在接受每个合并请求之前，必须对其进行测试。像 Travis CI 和 GitLab CI 这样的 CI 软件会在合并请求本身中显示构建结果，这样做很容易。
测试合并请求有一个缺点：CI 服务器只测试功能分支本身，而不是合并的结果。理想情况下，服务器还可以在每次更改后测试 master 分支。但是，在每次提交到 master 时重新测试都会在计算上花费很大，这意味着你更频繁地等待测试结果。由于功能分支应该是短期存在的，因此只测试这个分支是一个可接受的风险。如果 master 中的新提交导致与功能分支合并产生冲突，请将 master 合并回分支，以使 CI 服务器重新运行测试。如前所述，如果你经常有持续几天以上的功能分支，则应使分解为更小的 issue 。
Issue 跟踪
GitLab 流是一种使代码和 issue 跟踪之间的关系更加透明的方式。
对代码任何有意义的更改都应该从描述目标的 issue 开始。对每一个代码更改都有一个解释，这有助于团队的其他成员理解，并保持功能分支的范围较小。在 GitLab 中，对代码库的每次更改都从 issue 跟踪系统中的一个 issue 开始。只要更改需要一定量的工作，即超过 1 小时，如果还没有 issue ，则创建 issue 。在许多组织中，提出 issue 是开发过程的一部分，因为它们用于冲刺规划。issue 标题应描述系统所需的状态。例如，issue 标题“作为管理员，我希望在不收到错误的情况下删除用户”比“管理员无法删除用户”要好。
准备好编写代码后，从 master 分支创建 issue 相关的分支。此分支是与此更改相关工作的位置。
当你完成或想要讨论代码时，发起一个合并请求。合并的请求是在线讨论更改和检查代码的的地方。
如果发起合并请求但未将其分配给任何人，则它是一个“正在处理”的合并请求。它们用于讨论提议的实现，但尚未准备好包含到 master 分支中。合并请求的标题用
[WIP]或WIP:开头，以防止它在准备就绪之前被合并。当您认为代码已准备就绪时，将合并请求分配给一个审阅者。当审阅者认为代码已准备好包含在 master 分支时，就可以合并更改。当他们按下合并按钮时，GitLab 合并代码并创建一个合并 commit 记录，使该事件在以后很容易查看。合并请求总是创建一个合并 commit 记录，即使在没有合并提交的情况下也可以合并分支。这种合并策略在 Git 中称为“不快进”。合并后，删除对应功能分支，因为不再需要它。在 GitLab 中，此删除是合并时的一个选项。
假设合并了一个分支，但出现了问题并重新打开了该 issue 。在这种情况下，重用相同的分支名称是没有问题的，因为合并时删除了第一个分支。任何时候，每个 issue 最多只能有一个分支。一个功能分支可能解决多个 issue 。
在 commit 信息或合并请求的描述中，可以关联 issue ，例如 “Fixes #16” or “Duck typing is preferred. See #12.”
通过关键字 “fixes” 或 “closes” ，可以自动关闭 issue ，例如 “fixes #14” or “closes #67.”。
如果你有一个 issue 关联了多个库，那么在每个库里面创建一个 issue，并把这些 issue 关联到一个父级 issue 。
参考资料
:wastebasket:
> 如果要付出这种代价才能拯救世界，那最好还是让世界消逝吧。 ![70-poster][url-local-poster]