2

首先，我想

  1. 让我的master分支始终保持绿色。
  2. 能够为下一个版本挑选更改。

分支策略：

  1. 我有一个master分支和一个integration与它一起运行的分支。
  2. master从任务/问题分支。
  3. 当一个任务分支完成它的工作时，将其合并，integration看看它是否破坏了其他任务分支的任何工作。如果是，请修复它们。

  4. 从任务分支（不是integration分支）拉取请求到master分支。

    这意味着该integration分支仅用于 CI 目的，它永远不会被合并到master

  5. 决定下一个版本将包括哪些更改。将这些分支合并到master.
  6. 发布。

这是问题所在，假设我有以下情况：

master       -*-----------------
              |\
integration  -+-\-------C---F---
              |  \     /   /
ken/task#1    |   A---B   /
              |          /
bob/task#2    D---------E

在F中，发生了两件事：

  1. 发生合并冲突C并F更改了相同的行some-code.js
  2. F打破了一些测试C。

现在，Bob 必须解决这个问题，他有两个选择：

选项1

  1. 合并integration为bob/task#2_G
  2. 修复中的错误H
  3. 合并integration为I
  4. integration绿色

  5. 拉取请求

    master       -*--------------------------
              |\
integration  -+-\-------C---F-----------I
              |  \     /   / \         /
ken/task#1    |   A---B   /   \       /
              |          /     \     /
bob/task#2    D---------E-------G---H

但是，通过这种方法，我不能只task#2选择包含在我的下一个版本中。因为bob/task#2( H) 中已经包含了 中所做的更改ken/task#1，所以并入bob/task#2意味着master并入ken/task#1在一起master。

选项 2

  1. 切换回bob/task#2
  2. 尝试修复中的错误G
  3. 合并integration并运行测试以查看测试是否为绿色
  4. 如果没有，请切换回bob/task#2
  5. 尝试修复它I

  6. 合并integration并运行测试

    ...

    直到integration是绿色的。

  7. 拉取请求

    master       -*-----------------
              |\
integration  -+-\-------C---F---H---J--- ..........
              |  \     /   /   /   /
ken/task#1    |   A---B   /   /   /
              |          /   /   /
bob/task#2    D---------E---G---I--- ..............

这种方法可以防止将更改ken/test#1从bob/task#2.

然而，Bob 现在需要“猜测”他需要做什么来修复这个错误。然后一遍又一遍地合并到integration，看看测试是否是绿色的，因为G现在I没有添加测试C。

some-code.js每次他将他的工作合并到中时，他还需要解决同样的合并冲突integration，这既痛苦又多余。

Bob有更好的选择3吗？

谢谢。

4

1 回答 1

1

您应该考虑遵循 Git 流程：

https://www.atlassian.com/git/tutorials/comparing-workflows

以下是我对如何与 Git 流开发模型保持一致的想法：

  1. 开发人员创建功能/错误修复分支并提交拉取请求以将他们的更改合并到集成分支中。
  2. 应该在将更改集成到集成分支之前（而不是之后）决定将哪些功能发布到版本中。一旦您将功能合并到集成分支中，它就注定要发布，并且顺序已确定（您将功能应用到集成分支的顺序）。
  3. 当您审查拉取请求并决定将其纳入发布时，您应该审查变更集以查看它是否可以合并为快进合并，是否会导致干净的合并提交，或者是否存在合并冲突。
  4. 如果存在合并冲突，您应该建议开发人员将他们的更改重新基于集成分支的尖端。这导致了一个干净的提交历史和一个更稳定的集成分支，因为冲突解决发生在开发分支上，并且由最熟悉代码库的开发人员进行。
  5. 从开发分支到集成分支的合并应该是干净的：没有合并冲突，只是快进合并和/或干净的合并提交。集成分支上不应该发生冲突解决！
  6. 一旦你准备好发布，从集成分支创建一个预发布分支（这个分支是一个发布分支，它比开发分支寿命更长，以稳定发布）。只有修复进入预发布分支。

  7. 当预发布分支准备好用于生产时，将预发布分支合并回主分支（这将是一个快进合并），同时将同一分支合并到集成中。借此机会将提交压缩为单个提交，以便您在 master 上拥有更清晰的提交历史。

  8. 合并到 integration 或 master 分支后，清理分支：合并到 integration 后删除 dev 分支；合并到 master 后删除 pre-release 分支。

  9. 使用语义版本控制策略标记生产版本。创建一个官方发布分支以支持未来的修复。

  10. 当您在发布分支上发现问题时，请按照与开发新功能相同的过程来解决问题（步骤 1-5）。修复主分支优先于修复发布分支的问题。修复后，将修复挑选到发布分支上。

  11. 热修复的策略是不同的。对于热修复，从 master 的分支应用修复，然后将修复选择到集成分支上。

总而言之，我建议的要点是：

  1. 在将开发分支拉入集成分支之前，让开发人员在开发分支上合并代码并处理合并冲突
  2. 挑选并选择哪些拉取请求（开发分支）将使其发布。一旦决定，这些功能就注定要发布。
  3. 不要从集成分支中挑选提交/更改到主分支！
  4. 合并到 master 应该总是快进合并。由于您有一个额外的集成分支，因此您没有理由不想强制执行此操作。

Git Flow 非常适合大中型项目。但我实际上更喜欢将 GitHub Flow 用于较小的项目，特别是如果我正在为 Web 开发组件库。

在此处了解更多信息：http: //scottchacon.com/2011/08/31/github-flow.html

于 2017-05-09T18:22:19.767 回答