[barumi]

> It's not git-flow, as all commits are rebased on top of master to make the history of master linear.

I fail to see how that is relevant. I mean, the only possible impact that has is if individual commits within a feature branch are recorded or not, which is arguably irrelevant. You wouldn't get a different workflow if instead of reading you simply did a squashed merge.

> It is one of the more standard workflows, and it's a concise overview of how the maintainer of curl does their job.

It's gitflow, and leaving out feature branch commits doesn't make a difference.

[Cogito]

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

Look at any post on git-flow (or even just the original [0]), and you will see a myriad of merges.

Quoting the original git-flow post:

> When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. How this is done in detail will be discussed further on.

The examples further on all use `git merge --no-ff` (ie no fast forward).

This is very different to what is described in this post:

> When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possible. This makes the branch very easy to browse, understand and work with – as it is 100% linear.

So no, this is not git-flow.

[0] https://nvie.com/posts/a-successful-git-branching-model/

[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.