git flow对樱桃选择

Question

我们有用于生产版本的分支prod和用于正在进行的开发的dev。

我们目前的流量：

我们主要在dev分支机构工作，有时，客户会决定他想要来prod的哪些特性/错误，然后我们就会挑选它们。

根据我的理解，樱桃与git flow模型是矛盾的。

到目前为止，我还没有看到如何适应我们的流程来避免它。

git flow假设您事先知道更改是否转到prod上

社区有办法绕过它吗？

更新:我发现我的问题需要更好地澄清术语。

我们现在用的

实现问题#12345

git fetch
git checkout origin/dev -B issue-12345 # new branch for issue #12345 from bug tracking system
# ... do many atomic commits
git fetch
git checkout origin/dev -B dev
git merge issue-12345 --no-ff -m "Bug #12345 - Bug title from bug tracking system"
# ... fix merge conflicts if any and commit
git branch -D issue-12345
git push

备注

1. 我们使用原子提交使每个提交都有一个明确的意图。这简化了评审/指责/分割过程。
2. 我们使用自定义消息进行合并，因为它比默认的Merge 'issue-12345' into 'dev'更具描述性。
3. 我们通过--no-ff强制非快进合并，因为我们希望将所有问题都表示为合并。因此，git log dev --first-parent返回已完成任务的高级视图。
4. 我们不使用git merge --squash及其重碱类似物。我们希望保存整个任务的历史。

当客户决定将问题#12345投入生产时

git fetch
git checkout origin/prod -B issue-12345
git log origin/dev --grep "#12345" --oneline --reverse # get all commits that have to be cherry-picked, usually that's only one merge commit (abcd1234)
git cherry-pick abcd1234 -x -m 1 # '-m 1' required for cherry-picking merge commit
# ... fix merge conflicts if any and commit
# ... repeat for other commit if any
git checkout origin/prod -B prod
git merge issue-12345-prod --no-ff -m "Bug #12345 - Bug title from bug tracking system"
# ... fix merge conflicts if any and commit (although that's unlikely for them to occur)
git branch -D issue-12345
git push

git flow让我们做的事

有关更多细节，请参见http://nvie.com/posts/a-successful-git-branching-model/

在这篇文章中，我们的dev分支对应于develop，prod对应于master，而不使用发布分支。

根据git flow，只有特性分支应该基于dev分支，并且它们永远不会合并到prod中。

但是，修补程序分支应该基于prod，然后合并到prod和dev。

为什么git flow不适用于我们

1. 我们事先不知道任务是否需要转到prod分支。
2. 如果我们将特性分支建立在dev的基础上，我们将无法在以后将其合并到prod，如果这将被请求的话(可能很久以后)
3. 如果我们基于prod的特性分支，我们将无法从以前完成的其他任务中获益。

示例1

假设我们有一个任务#12345来实现一个新的Contact Us页面。然后我们有一个任务#23456，将页面的背景色从白色更改为黄色。

我们将issue-12345分支建立在prod上，然后将其合并到dev中，等待批准将其合并到prod中。

然后，我们开始在issue-23456上工作，并再次基于prod。但是prod代码甚至还没有提到任何Contact Us页面。因此，我们必须做一些怪癖，比如首先将issue-12345分支合并到issue-23456中。

对那个简单的案子来说也够复杂的了。如果您想使用在其他任务中引入的一些代码，您可以想象这将更加困难。

示例2

任务#34567要求实现Feedback页面。这个页面非常类似于Contact Us页面，所以它有类似的css。我们想再利用它。但是怎么做呢？说34567取决于#12345是不公平的。因此，将issue-34567建立在issue-12345上是不合逻辑的。那又怎么样？手动重写代码？复制糊？还是选择樱桃？

对于这样的问题，我看不出有什么合理的解决办法。

Answer 1

git-flow (见这里翻译成常规的git命令。)是基于将分支合并(将特性合并到dev，dev到master)。

git cherry-pick与合并不兼容，原因是：

• 在合并时复制提交，
• 功能依赖

因此，如果您当前基于摘樱桃的工作流程有效，您应该保留它。

然而，正如“如果你摘樱桃，你的树枝模型就错了。”中所解释的：

他们的见解是，使用git (或任何基于DAG的SCM)，如果您能够预测提交可能/将需要应用的位置，您可以将其放在它自己的分支上，并根据需要将其合并到不同的位置。 这将使更改应用于所有必要的分支(您可以将其合并为发行版和主版)，但不会导致提交得到复制/粘贴。相反，将记录新的合并提交，因此没有新的提交ids和历史记录(哪个分支有此提交？)在DAG中被很好的跟踪。

然而：

不摘樱桃的好处是你需要预先知道你想要把你的提交应用到多个地方，这样你就可以把它放在它自己的分支上。

在您的情况下，这将涉及多个独立的特性分支，只有在得到客户端的批准后才会合并为master。

关于git-flow，这是真的，它不是一个好的适合你。集成模型更准确：

拥有一个从integration开始的master分支并以以下方式进行比较简单：

• 从integration分支创建的特性分支
• 这些相同的特性分支每次合并到integration时，都是基于更新的integration分支顶部的特性分支:这涉及到与负责该特性分支的团队进行通信，因为每次功能分支被重基时，他们都必须重新设置自己的特性分支副本(因为它的历史会改变)。
• 合并提交从一个特性，一个特性分支合并到integration，如果删除该功能，则可以随时恢复该功能。的结果:所有尚未合并的其他特性分支都需要在更新的integration分支之上重新建立自己的基础。

一旦integration分支完成了特性并通过了用户验收测试，它将被合并到master (或prod)中。

从OP的场景来看，当特性可以在任何时候单独进入prod时，您不需要dev或integration

第一天. prod=dev=integration

让我们在这里只考虑prod和integration，以及特性或发布分支。

第二天，第一题提出。这里很明显。所有的分支都是一样的。所以我们可以git checkout prod -B issue-1 第三天，第一题修好了。我们在任何地方合并issue-1分支吗？

合并-no到integration

第四天第二题提出。又是从整合部门开始的？

这里基于prod。特别是如果它是一个问题(在prod中检测到)。

如果它是一个特性，您可以考虑从integration启动它，但是由于特性将从integration中删除，早期集成的好处并不是保证。

第五天，第二期修好了。在任何地方合并？

到integration (merge --no-ff)，检查问题2是否适用于问题1。

第六天，第二期批准进入刺激。我们该怎么办？

首先，在issue-2的基础上重新设置prod (在prod的情况下，从那以后)

然后merge --no-ff issue-2到prod。

将integration重置为prod，并将所有其他功能分支合并回integration，以验证它们是否在新prod (现在包括issue-2)之上一起运行良好。

第七天，第一题被批准进入刺激。我们该怎么办？

首先，在issue-1的基础上重新设置prod：这将验证issue-1仍然有效，即使是基于issue-2 (以前已经合并到prod )之上。

然后，合并--不。

注意merge --no-ff的使用，它从一个特性/发布分支在prod或integration中生成合并提交:如果需要从prod中删除所述特性/发布，则只需在prod或integration中恢复唯一的合并提交(而不是还原表示分支的一系列提交以删除)。

Answer 2

使用cherry-pick是一种非常不错的方法。

但

"problem“是指git流将您的分支合并为彼此(完全，然后删除它们作为其流的一部分)，因此使用cherry-pick和git-flow是某种滥用 git流的。

如何向客户提供功能？

在我看来，您应该考虑开发特性切换机制，以选择每个客户要关闭/关闭哪些功能。

Answer 3

我只想指出，我们的工作流程有一个类似的问题，我们选择了一个“还原”工作流，而不是挑选樱桃。当创建一个可以包含一个或多个特性的发行版时，我们会在开发分支中找到我们想要进入发行版的最新特性，然后再从那里分支。然后，我们决定哪些特性合并(git日志--第一父)我们不想从它下面进入并恢复它们。一旦发布完成，我们将通过还原并合并回开发分支来“取消还原”。

尽管git和其他一些命令显示“un”提交是导致代码更改的命令，但是git指责是足够聪明的，可以将历史追溯到原始特性提交，并且还有带有ids的提交消息的跟踪。