[barumi]

> I don't know what you think git-flow is, but a linear history it is not.

Your statement makes no sense at all. Gitflow is a workflow. What do you believe it's supposed to be? It's irrelevant how you see commit histories, because with regards to the master/mainline branch it's always linear, isn't it?

What do you personally believe gitflow is?

> Quoting the original git-flow post:

I don't know what you expected to show, but you are only describing a workflow. Changes are made in dedicated branches, and later these changes are merged back into the master/mainline branch in a single commit, which is expected to have been validated and tested and working. That's a workflow. How the log ends up looking is entirely indifernet or irrelevant, isn't it?

Again, what do you personally believe is the whole point of a workflow like git flow, specially in light of allowing large teams to continuously integrate their work ? I mean, what do you believe is the whole point of getting devs to work on branches independent of what changes go into master/mainline, and leave merging as a last step that's the responsibility of the developer prposing a change?

[Cogito]

Sorry for the late response, meant to reply hours ago!

I guess that first sentence should have been "I don't know what you think git-flow is, but it does not produce a linear history" or soemthing like that.

The history is very much not linear in git-flow, and for good reason - but it makes things more complicated and most people don't need it.

If, as you can find examples in other parts of thread, you use rebase-and-merge with git-flow you end up with something very similar to the methodology used in the article, but it is still different.

One of the main downsides to the featured method is that it's not clear which commits "go together" from the git history - you have to look at the pull requests in github. With git-flow, or rebase-and-merge, you always have a merge commit that lets you distinguish between commits that are 'releases' and commits that are part of a series.

So that is the key difference - the structure of the git log.

[Huggernaut]

The person you are responding to is only making the point that the OP's rebase flow is a very different workflow from git-flow. The pros and cons of each approach are significantly different, and the commit history will demonstrate the two different approaches.