DEV Community

dAVE Inden
dAVE Inden

Posted on

Git Workflow: Do you commit to master on your solo projects?

When you are working on a project you know you will be working on solo do you still work out of branches or do you commit to master? Does it depend on the project?

Like many, I have some projects that I work on for learning and fun. On many of them I am working on them by myself. Out of all of the todos I have for them I work on them one at a time. Even though most of them aren't dependent on each other, I don't typically work on multiple at once, switching between what I am building on that project. I will work on one until completion and then work on the next.
These projects are things like Gatsby sites or React apps that have a development server I can run locally on my machine to see my changes working with the current code.
One example is my personal website. It is a Gatsby site that isn't overly complex, in my opinion. I can run the development server locally to see how things look with my new code and push the changes to the master branch which triggers a new build on Netlify. If there is an issue with the deploy I can roll back the commit and try again. I should note that this is held in a private repo and I won't have people coming across the project and possibly submitting pull requests.

What do you think of this workflow? How do you do it when working on projects by yourself? I know it doesn't practice the branching and pull request mechanics for working on a project with other people, but it seems to work for me on my solo projects. Are there benefits to creating branches and working in them on solo projects I'm not seeing?

Latest comments (67)

Collapse
 
salocinski profile image
STRYJEWSKI Nicolas

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 ^

Collapse
 
daveskull81 profile image
dAVE Inden

Thanks for sharing your experience! I'm sure there are many others who have worked the same way. I'm starting to get a better workflow down to better practice real world git workflow that will be good for a team. Do you still work this way on personal stuff? Or have you adopted a different workflow?

Collapse
 
bngcebetsha profile image
Buntu Ngcebetsha

branch off

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

                              `feature_branch`
                               (develop feature)
                               (make a PR)
                               (get it approved)
                               (merge into `master`)
Collapse
 
gautamkrishnar profile image
Gautam Krishna R

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.

Collapse
 
syashakash profile image
Akash Shivram

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.

Collapse
 
daveskull81 profile image
dAVE Inden

Some others have said similar things with the complexity of the change being a deciding factor in if they will create a branch or not. It seems like a good line to draw for the decision.

Collapse
 
jefftriplett profile image
Jeff Triplett (he/him)

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.

Collapse
 
daveskull81 profile image
dAVE Inden

This is a pretty common sentiment. It seems like complexity of the change is a big driving factor in folks decision on how their git flow will go.

Collapse
 
jessekphillips profile image
Jesse Phillips

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)

Collapse
 
twigman08 profile image
Chad Smith

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.

Collapse
 
embiem profile image
Martin Beierling-Mutz

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.

Collapse
 
gayanhewa profile image
Gayan Hewa

Sometimes, I cheat

Collapse
 
fcfn profile image
Peter Timoshevsky

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.

Collapse
 
chriskarpyszyn profile image
Chris Karpyszyn

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.

Collapse
 
daveskull81 profile image
dAVE Inden

Great points. I really like the perspective of how practicing the right methods in a personal project makes for good habits at work. It’s very true.

Collapse
 
chrisachard profile image
Chris Achard

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 :)

Collapse
 
daveskull81 profile image
dAVE Inden

I agree. I often just want to get the work done too. On projects that are more for fun it seems like a nice way to go, especially if I’m working by myself.

Collapse
 
robertomaurizzi profile image
Roberto Maurizzi

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.

Collapse
 
clamstew profile image
Clay Stewart • Edited

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.

Collapse
 
rnrnshn profile image
Olimpio

Same here... I directly push to master.