[barumi]

> Seems pretty standard to me. Anything notable here?

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.

[Cogito]

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

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

0: https://git.wiki.kernel.org/index.php/MaintNotes

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

[globular-toast]

It's not git flow. Git flow is horrendous, completely unnecessary and designed by someone who doesn't understand git.

The article describes a pretty standard git rebase workflow that is simple and works well.

[modderation]

Git Flow actually makes some sense if you need to track and retain history of self-contained fixes and features across concurrent release trains, where "retain history" means more than just a commit message.

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.

[NateEag]

The author of "GitFlow Considered Harmful" put out a simpler workflow that achieves all the upsides of GitFlow with none of the downsides:

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.

[barumi]

> The author of "GitFlow Considered Harmful" put out a simpler workflow that achieves all the upsides of GitFlow with none of the downsides:

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.

[globular-toast]

That's not git flow, that's just release/maintenance branches.

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.

[barumi]

> The main feature of git flow is having multiple redundant branches for no reason. Namely a separate develop and master.

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.

[globular-toast]

You don't have to look hard at the git flow diagram to see the redundancy. It's plain as day. Of course I'm talking about today. Why would I be talking about 20 years ago? We have continuous integration and automated build pipelines so there's no reason to have your build artifacts living in the git repository. git is for source code. There are other solutions better suited to storing artifacts.

[etripe]

IMO, git flow came about when people didn't want to or couldn't abandon the idea of trunks in TFS.

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.

[globular-toast]

Yeah, that matches my own analysis. I think it also comes from a time when people considered the source code to be an artifact and creating a source distribution was just checkout+zip. So you'd make a release commit with a version of the source code where the version is hard coded (the git flow page uses a "bump_version" script). Nowadays most projects can build an artifact (source or binary) from any version of the source code and derive their version number from git at build time.

[rurban]

The rational explanation is that branches are much easier to work with. You can rebase and merge branches with your standard workflow, but stashes can only be popped in order. Branches can be reordered and changed at will. As beginner I started with some stashes, but never needed them since. You already got tons of tools for branches, but none for stashes. Stashes are like submodules for me, quirky.

[sigjuice]

I gave up on git stash because over time I would end up with too many stashes that I couldn't keep straight in my head. Now I just make temporary branches and cherry pick from them as needed.