gitflow修补程序应该如何工作？ [英] How should gitflow hotfixes work?

问题描述

我们在我们的网页版本中使用了Gitflow，并且我有一个关于修补程序应该如何工作的问题。但首先我应该解释一下，我们并不是使用普通的Gitflow工作流。

我明白，通常你会将 features ，它们在完成后会合并到 develop 中，您可以创建 release >， release 合并到 master 中，然后将其部署为实际的版本化版本。

但是，由于这是客户端工作，我们不会执行发布，而是在需要时部署功能，因此我们的功能分行在特设的基础上合并为 master 。

特性分支出现的问题从 develop 分支，这比 master ;将这些特性分支合并到 master 会将其他更改合并为 master （当特性为分支时， develop 中的变化尚未处于主）。我们意识到这不是Gitflow的设计方式，但我们需要某种分支模型，所以我们（有点）通过挑剔提交来解决这个问题，而不是合并分支。

所以，我理解这些问题，我不相信他们正在为我现在的问题做出贡献，但以防万一，这就是我们如何使用它的原因。然而，我的问题是：

如何合并到修复程序


• master 是产品


• develop 超过 master

然后您想用修补程序解决即时问题分支。在Gitflow中，它从 master 分支，当你完成修补程序时，它将被合并到 master 和 develop

不会造成大量问题？

最近，我尝试创建一个修补程序以将一行副本更改为一个文件。我完成了修补程序，并且更改合并为 master ，没有问题，但是当它合并到 develop ，由于 develop 之间的不一致，它创建了一个巨大的文件差异， >和 master 。

我知道这是因为您正在合并 / code> branch ，它本身是从 master 分支的，转换为 develop ，特别是 change 或单个 commit ，所以我明白为什么存在大量的合并提交/冲突。

但是，我不明白的是，考虑到这一点，修补程序是否可以工作真实世界，考虑到它们是从 master >分支的，然后合并到 develop 中，这是设计的方式在 master 之前。这就是为什么我不认为我们使用Gitflow的方式是问题，因为 develop 会比 master



t对我来说似乎有意义的是，你的 hotfix 可以像将 true 更改为 false 或更改电子邮件地址，但要将它放入 master 中，您可能不得不面对一大堆合并冲突。这只是标准的行为？这只是修补程序的工作原理，如果你必须坐下来解决一个大规模的合并冲突，那么做到这一点？仅仅为了提交一个提交而不是更容易？看起来像是有这么大的范围来为可能是如此微小的变化引入错误 - 你正在处理两个分支，可能需要几个月和数百次提交。

我可能会误解修补程序的过程，但如果是，我不确定哪一个位。

解决方案

我不明白为什么会有很多冲突。合并到 develop 的更改只是最新的修补程序，可能是以前的修补程序，如果它们由于某种原因而未合并。

（尽管我宁愿将修补程序合并到 master 中，并将它们合并为 master 到 develop ，而不是直接合并修补程序到 develop ，只是为了避免交叉合并，但它不应该改变太多）

We use Gitflow for our web builds, and I have a question about how hotfixes are supposed to work. But first I should explain that we don't quite use the normal Gitflow workflow.

I understand that usually you would branch your features, they would merge into develop when finished, you would create your release, release gets merged into master and you deploy that, as an actual "versioned release".

However, as this is client work, we don't do "releases", instead features are deployed as and when they are required, so changes from our feature branches are merged into master on an ad-hoc basis.

This did cause problems as the feature branches were branched from develop which was way ahead of master; merging these feature branches into master would merge other changes into master (changes that were present in develop at the time the feature was branched that weren't yet in master). We were aware that this is not how Gitflow is designed, but we needed a branching model of some sort, so we (sort of) solved this by cherrypicking commits instead of merging branches.

So, I understand these issues, and I don't believe they're contributing to the issue I have now, but just in case, this is how we use it. However my question is:

How are hotfixes supposed to merge in?

In my head, the scenario is:

• master is "production"
• develop is ahead of master

You then want to patch an immediate issue with a hotfix branch. In Gitflow, this branches from master, and when you finish the hotfix, this gets merged into master and develop

But how does this not cause massive problems?

Recently, I tried to create a hotfix to change a single line of copy in one file. I finished the hotfix, and the change merged into master with no problems, but when it tired to merge into develop, it created an enormous 35 file diff with several merge conflicts in files I hadn't touched, due to the disparity between develop and master.

I understand that this is because you are merging the hotfix branch, which was itself branched from master, into develop, not specifically the change or single commit, so I understand why there was the massive merge commit/conflict.

However, what I don't understand is, with this in mind, how hotfixes work at all "in the real world", considering they are branched from master and then merged into develop, which is, by design, way ahead of master. This is why I don't think the way we're using Gitflow is the issue, because develop would be ahead of master regardless of our non-standard deployment process - I can't see why this doesn't cause huge headaches regardless of the project or exact workflow.

What doesn't seem to make sense to me is that your hotfix could be something as simple as changing a true to a false or changing an email address, whatever, but to get it into master, you may have to wrestle with an enormous set of merge conflicts. Is this just standard behaviour? Is this just how hotfixes work, and if you have to sit and sort out a massive merge conflict, then so be it? Would it not be easier to just cheerypick a commit? It just seems like there is such massive scope to introduce an error for what could be such a tiny change - you're dealing with two branches that are, perhaps, several months and hundreds of commits away from each other.

I may just be misunderstanding the process of hotfixes, but if I am, I'm not sure which bit.

解决方案

For first picture in this link

I don't see why there would be many conflicts. The changes which are merged to develop are only the latest hotfix, of maybe previous hotfixes, if they were not merged for some reason in their turn.

(though I would rather merge the hotfix into master, and them merged master to develop, instead of directly merging hotfix to develop, just to avoid criss-cross merges, but it should not change much)

这篇关于gitflow修补程序应该如何工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！