[WIP] Feature branches should track the develop branch

[orjan]

This is just a failing test case and I'm not sure if it's possible or even desirable to solve this issue.

We're using a derived version of git flow where feature branches is merged into develop via pull requests. Develop is then merged to master via a merge commit that's tagged with the actual version.

Doing like this a new feature branch will then loose tracking to develop branch, this is not the case if develop is integrated to master via a fast forward commit.

I would like to know what you think, does this test make sense and should I investigate it further?

[asbjornu]

We have the same flow and would very much love to not have to merge master back into develop after tagging. So I support this use-case! 👍

[orjan]

@asbjornu if you checkout my latest commit, it looks like setting track-merge-target: true will do the trick, so this is not a GitVersion bug at least.

I'm still puzzled about the approach to use merge commits against the master. We switched over due to an old bug in GitVersion together with having a closer look at git flow.

  feature[/-]:
    track-merge-target: true

[asbjornu]

@orjan Interesting. I've seen track-merge-target, but did not expect it to solve this problem. I think I'll put it to good use. About this:

I'm still puzzled about the approach to use merge commits against the master

What is it you're puzzled about? The fact that track-merge-target: true isn't the default?

[orjan]

@asbjornu sorry about that it was only me thinking about load git flow and the usage of merge commits against master with the result that master and develop will diverge over time due to the tagged merge commits. On the other hand with the benefit that it's possible to see when and by whom develop was merged into master. I think it was this line that started my thoughts: orjan@66bb9e5#diff-32ad2f294466812f9b17969c748568e4R194

[asbjornu]

I see. Yea, I find the merge to master to be a good practice. It makes the graph very intuitive visually and, as you mention, makes it obvious who merged and perhaps why.

By the way, how does track-merge-target relate to prevent-increment-of-merged-branch-version? Sounds like they try to solve the same problem, only with opposite perspectives.

[orjan]

The problem can be resolved by adding track-merge-target to the configuration file.

  feature[/-]:
    track-merge-target: true

[JakeGinnivan]

Release branches do not track merge targets, and feature branches can target release branches. Not sure that works?

[orjan]

In our case release branches is skipped, so the chain is.
PR>develop>master
Both steps via merge commits and master is tagged

On 12 Oct 2015, at 01:24, Jake Ginnivan [email protected] wrote:

Release branches do not track merge targets, and feature branches can target release branches. Not sure that works?

—
Reply to this email directly or view it on GitHub.

[JakeGinnivan]

What does develop even give you? Why not just use githubflow?

[orjan]

@JakeGinnivan not sure really but I'll try to describe the work flow and I agree with you to some extent and it would be great to be able to use githubflow, but I'll try to describe the workflow.

We're working with pull requests and after a review they are merged to develop. A release are typically scheduled during the night since some features requires a small down time window. Using the develop branch gives us the possibility to do some regression testing in the staging environment to see if there no hidden interference between 2 features without locking the master branch if we'll need to do a critical bug fix. One could argue the a true gitflow would be better, but since the release branch would almost never contain any commits and since there's only one version of the system in production, it feels like adding some extra overhead.

So my it's probably more processes related (comming from releases every 2 week we're loads of commits was pumping straight to the old svn trunk) together with the need of a small down time window for some releases that causes the "need" for the develop branch.

But I appreciate the critique and I'm open for all kind of suggestions even if we'll have to go back to a true gitflow even if it feels like the wrong direction!

[asbjornu]

@JakeGinnivan We have a process that is very similar to the one @orjan describes. GitFlow is a bit too complicated (we don't do release/*) and GitHubFlow is a bit too simple (we need feature/* branches, for instance). So we have master, develop and feature/* and possibly hotfix/* as well. Adding any more branches to this model doesn't really give us anything other than process overhead.