Normally I work on the master branch in the initial phase. Once I reach a stable state with the most basic functionalities, I branch out. If there are more than one way of implementing something that I need to try out, then implementing them in separate branches makes more sense to me.

Like you mention, while working solo, one works on one feature at a time -- that's true for 9 cases out of 10. Even so I prefer working on a separate development branch. In any case, switching to a stable branch is always faster and easier than finding the stable commit and checking out to that commit.

I work in feature branches for bigger features, which I won't be able to finish in a day and the rest goes directly into the master branch. On work we usually have also a develop branch (following the git flow flow) but even there is not much of a benefit and it* tends to get updated very rarely.

Edit: *I meant that if we have a develop branch the master branch rarely serves a practical purpose.

I've never seen much of a point in branches for most cases.

There's lots of cases where you aren't necessarily working on a huge new feature but just need to adjust some details of the behavior, so why bother creating a branch for that?

Even when working with someone else; in most cases I will pull, work on some feature, then (pull again and) push. If some work has been pushed in the meantime, there will be a merge at that point anyway.

Branches are for when your project actually branches off and both branches will be worked on in parallel. Using branches for anything else, in my opinion, is just silly and serves no purpose.

I always do, even on solo projects. Master is always stable. I create branches for features and bugs and only merge into master when they are finished and all tests pass.

I tend to use feature branches, but I'm dedicating this month to fuzzing my main project and I fix bug and push to master when I do this.

I actually do the same, I create features branches, work with them once I am done with the feature then I merge it to master. Keeping in mind that branches in GIT are cheap.

At first yes, then I like to have a develop branch to have all current and merge to master when I find it stable enough, can be packaged, tested and have documentation.

When working on bigger projects with a team of more than 3 people, feature branches is a must.

Pushing to master branch for me triggers a build process so I always build on develop or a feature branch even on my solo projects.

I mostly use 3 branches. Master, Testing and Buggy. I commit to testing all the time. When everything is done I merge the Testing with Master. If I want to try develop a new feature I commit to Buggy and validate the issues there to have testing saved with a clear path.

It's trunk based development for me.
I don't see a reason to deviate from that practice.

For my Unity 3D projects I almost always use branches, and most of them is gitflow. It helps me prevent going tweak-frenzy and keeps me focused.

On the other hand I have a couple of wordpress sites. All the customization I did was via FTP on live site. There is even no git or master branch. So I can say it depends.

My strategy for our company website (I maintain it as secondary priority, sometimes no changes for weeks, sometimes work on it few days in a row):

• CMS/content branch if its plug-n-play content like article/news/press release/blog/case-study etc. This way preview will have the same URL.

• Dedicated branches always for each styling/structure/feature/product change. Sometimes also bigger content changes gets its branch. Basically, for anything that might span over long enough time to overlap with other changes.

• Directly master only with visual bug-fixes like button placement, padding etc. Ofc, I use localhost live preview server.

Though not required, I do always ask for final proof-reading and approval on the branch preview from our marketing/company lead. Most of the time they find something to fine tune once they see content in place.

Also, our master branch have few more grunt tasks like image compression, critical css, etc. that takes considerably more time to build. Having ability just to push new branch in minute or so with Netlify branches is just pure gold. Almost like a new site, but max close to the prod.

In the end, even though one works solo on a project, things will go in parallel. I have taken this practice over for other projects (where possible), it makes you to focus just on the feature scope.

I commit to master no matter if it's a personal or day job project

I do everything on master and use CI/CD to handle any environmental pushes. I'm always building on master and always deploying to dev, however, I choose when those builds go to other environments.

✋That's me! I commit to master, I force push to master, I do all the things you aren't supposed to do on my solo side projects and I'm not ashamed of it 😎

This reminded me of a great talk by Justin Searls

In my place, "master" IS the development branch, and then there is a "live" branch for once we're ready to push things into production. The projects themselves though are designed in such a way that multiple people can work on independent sections with zero merge conflicts. This is all part of the actual architectural design of the framework in place. "Everything is an island" in that every feature / module / whatever are entirely isolated in the code from one-another.

I do that all the time on my solo projects. I only use branches for parking experimental code, and release preparation and post-release maintenance.

Same here... I directly push to master.

It evolves for me. Like one big side project, I probably committed to master for a year. Then you want to add a feature and you don’t know how it will turn out or you want to refactor a outdated npm library out of your project. And you don’t know how those will turn out and you don’t want to do either on a single commit and so I’d check out a branch in those cases. And it then has its advantages of allowing you to do the more complicated thing and go make some quick UI updates on master and ship faster. All while getting the more complex task done on a branch.

But that’s the changing nature of a web app sometimes. At first you’re getting the core idea down and iterating on a single idea. Once you get a version 1 out, things can get a bit more complex in updating it.

It really depends on the project's complexity. If it's non-trivial I usually still have at least development and production branches (no master :-) )
For simpler projects I commit trivial changes and fixes to master but I create feature branches for any more complex or "risky" change.

If it's just me? Everything just goes into master 🤣

On a team is when I start to worry about feature branches and PRs, etc. Maybe that's practicing bad habits, but on my own (and especially on fun/side projects), I simply optimize for development speed :)

Even on solo projects I'll have a production, a develop and work in feature branches.

I think there are two main benefits of this.

First, branches allow you to prototype features and dump them easily without ever hitting your main branches. There will be no need to do any crazy gitfu to clean up something buggy or that you don't want.

Second, practice makes perfect. If you cut corners in your personal life, you'll carry that over when you'll need to follow a stricter git workflow.

If it's something experimental, I would branch it out and merge to master when it's deemed stable or actually needed. Otherwise it goes into master.

Sometimes, I cheat

My rule of thumb is that I start branching if things get more serious so that I need a staging environment/branch or I want to experiment/explore some ideas.

Depends on the project.
If it is just something I'm doing to learn, it will never be published or anything I push directly to master. I am not a fan of over engineer things just to over engineer it.

If it is going to be a legit side project, then master is reserved for stable builds. I work mainly on develop. If what I'm going to do might not work or will take multiple days then I will branch off develop.

Like most comments I'll push and rebase master when working alone. Sometimes it would have been nice to work out in a branch, but really doesn't matter. (I would catch stupid mistakes which avoid kicking off deployment)

For "me" projects, I commit to master, and I leverage branches for bigger or messy features. That way I can work on an idea, and if it doesn't work, I can throw it away or file it away for a later date.

For me it depends on the time taken and complexity of the project. Like for my portfolio, I have a master branch that is live and I have divided features or things that are to be added into versions. So there is a working site available throughout the development.
For another project that I am working in, I have a branch for managing view and other to manage data. There is a main branch where I integrate front end and back end.

Releasing from master is not a good Idea sometimes. Creating a separate branch for release is the best practice. Master always contains finished features that may of may not deployed to production whereas develop branch can contain unfinished features that can be later merged to master when its done.

branch off

----master|---->------------>--------->

                              `feature_branch`
                               (develop feature)
                               (make a PR)
                               (get it approved)
                               (merge into `master`)

I always worked on master branch when it was some personal work/fun. Why ? Because I was like you. I worked on one todo at a time and I didn't care about file's version. I don't know if it was a good way to worked. But it was mine ^{^}