处理测试和生产的git分支 [英] Handle git branching for test and production

问题描述

当使用git（流程）并且有一个客户正在开发他们对开发事务的评论的阶段/测试环境时，处理未被批准的功能的最佳方式是什么？

考虑几个开发人员在sprint或连续工作流中使用不同功能的场景。这些功能需要由客户进行审查，并且功能可以在舞台环境中进行审查，并且必须将其合并到开发分支中并进行部署。

假设开发团队已经开发了两个功能，并且已经开发完成。客户回顾并批准其中一个。但是现在客户希望将批准的功能发布到生产环境中。开发分支现在被未批准的功能代码污染，无法推送到生产。

处理这种情况的最佳方法是什么？当然，实际上它更复杂。樱桃选择解决方案还是应该重新考虑分支机构的整个流程和处理？

解决方案

这个问题（由未批准但已经集成的功能分支污染的开发分支） em> 拉曼古普塔 在 Git创作者如何分支 。

在您的情况下（gitflow），您需要在合并dev之前恢复未经批准的功能的合并提交。

但是gitworkflow使用短暂的分支，与gitflow相反：

GitFlow鼓吹拥有两个永恒分支 - master 和 develop

工作流程（gitflow或gitworkflow）使用功能或主题分支：

主题分支是所有目前的工作正在完成 - 每个问题一个分支，bug或功能，并且可能有许多主题分支一次性进行开发。

主题最终合并到gitworkflow中的分支 next 中。

然而，一个关键的区别是下一个分支永远不会合并到 master 到永久分支开发，这意味着合并到 master / release in gitflow）

既然主题已经毕业到 next ，它可以是测试版或接受版本的一部分。因此，接下来的每个主题都可以进行第二轮稳定化，这正是测试版发布/验收测试环境的目的。

但是，请注意，使用gitworkflow，我们仍然没有提交（没有双关语！）使这个主题作为我们下一个发布版本的一部分 - 它仍然没有合并到 master 。

这与GitFlow的<$因为 master 对 next 没有依赖关系，所以c $ c> release 分支更加灵活和强大。 （不同于相应的GitFlow分支无论如何也不是 next ）批量合并到 master c> develop 和 release ）。

如果next不是合并到master，那么如何将一个功能投入生产？

一个主题被判断为足够稳定以便发布，该主题再次毕业并被合并为 master （或者 maint ），再次使用 - no-ff 来保存顶部的完整历史记录

为什么这会更好：

请注意，在gitworkflow中，不稳定和稳定的开发工作绝不会混合在同一个分支上。

相比之下，使用GitFlow我有两种选择：

1. 我可以测试我的话题在它自己的分支上是孤立的，或者
   
2. 我可以合并它来开发测试。

两种选择都不具吸引力。

• 与其他正在进行的工作一起部署时，前者不提供对主题稳定性的真实测试，而
  
• 后者在主题稳定之前提交该主题进行开发。

含义：

简而言之，在GitFlow中，始终存在一种无法解决的紧张问题，它需要保持开发工作的清晰和独立于主题分支，并将主题分支与其他工作集成，方法是合并它们以使其可见并可检测并检查冲突。

Gitworkflow允许在不牺牲另一个目标的情况下实现两个目标。

When working with git (flow) and having a stage/test environment where the customer are doing their reviews of the things developed what is the best way of handling features that aren't approved along with features that are?

Consider the scenario that several developers working with different features in a sprint or in a continuous workflow. The features need to be reviewed by the customer and for the features to be able to be reviewed in the stage environment they have to be merged into the dev branch and deployed.

If, let's say, two features have been developed, considered done by the development team and been pushed to dev. The customer reviews them and approves ONE of them. But now the customer wants to release the approved feature to production. The dev branch is now "polluted" by a not approved feature code that can not be pushed to production.

What is the best way to handle such a scenario? Of course in reality it's more complex. Is cherry picking a solution or should the overall process and handling of branches be reconsidered?

解决方案

That issue (dev branch polluted by "non-approved but already integrated" feature branches) is exactly what describe Raman Gupta in "How the Creators of Git Do Branching".

In your case (gitflow), you would need to revert the merge commit of the non-approved features before merging dev to release.

But the "gitworkflow" uses ephemeral branches, by opposition of gitflow:

GitFlow advocates having two eternal branches — master and develop

Both workflow (gitflow or gitworkflow) use "feature" or "topic" branches:

Topic branches are where all the current work is being done — one branch per issue, bug, or feature, and there can be many topic branches undergoing development at once.

A topic ends up merged into the branch "next" in gitworkflow.
However, a key difference is the next branch is never merged to master (as opposed to the eternal branch "develop" which is meant to be merged to master/release in gitflow)

Now that the topic has graduated to next, it can be part of a beta, or acceptance release. So every topic on next can now undergo a second round of stabilization, which is exactly the purpose of a beta release / acceptance testing environment.

However, note that with gitworkflow, we still have not committed (no pun intended!) to having this topic as part of our next release to production — it still has not been merged to master.
This is similar in concept to GitFlow’s release branch, but far more flexible and powerful, since master has no dependencies on next whatsoever, nor is next ever merged wholesale into master (unlike the corresponding GitFlow branches develop and release).

If next is not merged to master, how you graduate a feature to production?

Once a topic is judged stable enough to release, the topic graduates again and is merged to master (or perhaps maint), again with --no-ff to preserve the complete history of the topic branch.

Why is this better:

Note that in gitworkflow, unstable and stable development work is never mixed together on the same branch.

In contrast, with GitFlow I have two choices:

1. I can test my topic in isolation on its own branch, or
2. I can merge it to develop for testing.

Neither choice is appealing.

• The former doesn’t offer a true test of a topic’s stability when deployed together with other ongoing work, and
• the latter commits the topic to develop perhaps before it is stable.

Meaning:

In short, in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts.
Gitworkflow allows both goals to be achieved without sacrificing one for the other.

这篇关于处理测试和生产的git分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！