I agree, it's pretty vanilla git usage. I was curious to see any insightful take of whimsical twist, but it boils down to a basic take of good old git flow, which is git 101 for a long time.
https://nvie.com/posts/a-successful-git-branching-model/
The only surprising thing in the article was the refusal to use git stash, which can't really be explained on a rational level.
It is one of the more standard workflows, and it's a concise overview of how the maintainer of curl does their job.
For a more complex workflow, I recommend reading the notes from the maintainer of the git project [0].
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.
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/
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?
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.
The article describes a pretty standard git rebase workflow that is simple and works well.
With that said, I don't think this need is particularly common. Most projects are happier to throw away merge history in favor of a linear history with ephemeral branches and semantic versioning, and that's perfectly fine. The repository layout should be dictated by the project's needs, be it a glorified personal Undo Log, or a management tool on top of a Subversion repository.
https://www.endoflineblog.com/oneflow-a-git-branching-model-...
If you can tell me something GitFlow buys you which OneFlow doesn't, I'd be very intrigued.
I see no relevant difference between that workflow and GitFlow, besides the rebranding of old concepts and some unexplained focus on merging options.
I've also revisited the author's old rant from 2015 regarding gitflow and the only tangible criticism he had was the separation of the master/mainline and development branches, which is extremely shortsighted and miopic as it fails to acknowledge the reality of non-CICD/old-fashined software release lifecycles.
GitFlow has one main concept: using feature branches to do develop work, use release-specific branches to integrate changes, establish and enforce upstream/downstream relationships between branches. The rest is just rebranding and nit-picking over semantics.
The main feature of git flow is having multiple redundant branches for no reason. Namely a separate develop and master. There is no point of that at all. Look at the diagram, move all tags from master to develop, delete master and rename develop to master. There, you now have the workflow you've described without redundant branches.
This statement is simply wrong and ignorant.
The reason why mainline and develop branches exist is due to the fact that production-ready code and unstable code are not the same ops-wise.
Nowadays, with the dissemination of CICD practices, that difference has been shifted away from the source code repository and into the Delivery/Deployment phase of a CICD pipeline. Yet, the overall principle is the same, and arguably its still here. Calling those differences "redundant and for no reason" is just ignorant at multiple levels, from software engineering to the fact that the sofware lifecycle process for commercial software projects, the kind that had to "go gold", had very specific requirements.
I've heard its benefits explained as "more security for the business", while in practice it only leads to extra complications and accomplishes nothing a git tag couldn't.