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?

Discussion (67)

Collapse
gnsp profile image
Ganesh Prasad

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.

Collapse
marcussa profile image
Marcus S. Abildskov

I do the same.
After having reached a "stable" repository, I branch out and use Gitflow.
Master should ALWAYS be a working project/application.
When you have CI/CD this is really important as it'll most likely trigger on PRs being merged into your master branch.

Collapse
terabytetiger profile image
Tyler V. (he/him)

I've been using and loving this workflow! I mostly started with it because Netlify pushed me toward it.

I will chip away at my side projects between 3-4 computers, so I ended up needing the branches to prevent incomplete work getting pushed to the live site 😅

Collapse
daveskull81 profile image
dAVE Inden Author

Netlify is the reason for my working this way too lately. I haven't been working on these projects across multiple computers, but I might. Branching is a good way to help that from getting too messy while keeping the live site working smoothly.

Thread Thread
yvonnickfrin profile image
🦁 Yvonnick FRIN • Edited

Did you know Netlify has a Deploy preview feature that deploys the code of your branch on a special url ?

Thread Thread
daveskull81 profile image
dAVE Inden Author

I have seen this! It looks really useful. I am interested to try it out.

Collapse
derickhess profile image
Derick Hess

This is exactly the way I work on my solo projects as well. I prefer master to be the stable branch at all times

Collapse
woody_tanner profile image
Tanner Woody

I'm reading "prefer" as mandating here 😂 Who would want their master to not be the stable branch! That's just scary 😶

Collapse
0ctavia profile image
Octa

I think I'll start implementing this workflow from now on. It makes more sense than the whole "now in which commit did I f things up".

Collapse
thomas_ph35 profile image
Thomas Philippot

Same for me !

don't know if it's habits, but it makes more sens to me has well.

Collapse
guneyozsan profile image
Guney Ozsan

Some of my projects go like this as well.

Collapse
molly profile image
Molly Struve (she/her)

✋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

Collapse
daveskull81 profile image
dAVE Inden Author

Thanks for sharing Molly! I really appreciate your enthusiasm for doing all of the things you "aren't supposed to do." :)

Collapse
johannesjo profile image
Johannes Millan • Edited

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.

Collapse
daveskull81 profile image
dAVE Inden Author

I like this approach to branch based on how long the work will take. Something short that will be done in a single sitting can be tested and pushed out to master, but a longer term feature can be put to a branch for changes to be saved remotely as well as locally until it is ready. Interesting.

Collapse
charlesdlandau profile image
Charles Landau

This answer exists, so I don't need to write my own. Well put!

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 Author

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
darkwiiplayer profile image
DarkWiiPlayer

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.

Collapse
woody_tanner profile image
Tanner Woody

I drive to work using the interstate. Other people use the interstate to transport cargo from warehouse to retailer. Those other people aren't silly. People use things for different purposes.

But this is more like saying seat belts are silly because I'm never involved in accidents 😂

Collapse
marcussa profile image
Marcus S. Abildskov • Edited

I see you haven't had the need of CI/CD yet, otherwise you would've known the point of Gitflow.

Collapse
quii profile image
Chris James • Edited

You don't need gitflow for CI or CD.. at all. How did you come to this conclusion? If anything gitflow is an obstruction to CI.

Collapse
elmuerte profile image
Michiel Hendriks • Edited

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

Collapse
ryaninvents profile image
Ryan Kennedy

I have the same workflow! I haven't yet used trunk-based development within a team, but really like it for my own workflow.

Generally I'll create a side branch if I think there's risk involved; e.g. if I'm working on a new feature and am playing around with API ideas. That way, I can delete the branch if it's not going well. Otherwise though I usually just commit to master.

Collapse
elmuerte profile image
Michiel Hendriks

New features should be developed on the trunk/master.
If you want to try things out, which basically means you want to create a proof on concept, then you can do this on a special branch. This branch you throw away when you are going to implement the real thing on the trunk. Proof of concepts are meant to be thrown away, not merged.

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 Author

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
notsag profile image
Maxime Gaston

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.

Collapse
daveskull81 profile image
dAVE Inden Author

Do you reuse the develop branch to work out of for the future? Or do you create new branches when there is new work to be done?

Collapse
notsag profile image
Maxime Gaston

I make most of the work on develop and regularly merge to master to ship. I don't find the need for additional branches when working solo.

Thread Thread
daveskull81 profile image
dAVE Inden Author

Very cool. Thanks!

Collapse
bngcebetsha profile image
Buntu Ngcebetsha

branch off

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

                              `feature_branch`
                               (develop feature)
                               (make a PR)
                               (get it approved)
                               (merge into `master`)
Collapse
8ucik profile image
8ucik

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.

Collapse
daveskull81 profile image
dAVE Inden Author

Neat. One of the reasons I stay away from branches is that I once made a new branch each time I built a new feature and managing / deleting old branches was a pain. I do like the idea of having a working branch to commit to and merging it into master when I need to deploy.

Collapse
jonasroessum profile image
Jonas Røssum • Edited

Same. GitHub helps me a lot with this, as deleting the branch is suggested whenever you merge a pull request. You still gotta delete them locally, but I recommend using your remote repository as the "source of truth", so that you can always delete branches that are no longer coupled to a pull request, if that makes sense.

Thread Thread
daveskull81 profile image
dAVE Inden Author

That does make sense and I agree that GitHub helps a lot with this. The management of local branches to me is a painful process and part of why I asked this question.

Collapse
chiangs profile image
Stephen E. Chiang

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.

Collapse
daveskull81 profile image
dAVE Inden Author

Do you use your develop branch for all new feature work? Or do you create a new branch for each new feature?

Collapse
chiangs profile image
Stephen E. Chiang

I try to always make a branch to work off then merge to Develop and then to Master.

I do this because it's similar to the flow I use in teams. I also like making release snapshots in case I need to roll back what is in production.

Also, thanks to my new handy git function, I really like typing g donep and watch my merge and branch cleanup happen all by itself...quite satisfying.

Thread Thread
daveskull81 profile image
dAVE Inden Author

That’s a really cool function. I will have to try that out and see if it can help me with my workflow. Thanks!

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
darkain profile image
Vincent Milum Jr

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.

Collapse
daveskull81 profile image
dAVE Inden Author

Do you ever have issues with when the work is merged and coordinating that? Do you ever have a situation where someone's work is dependent on the work being done by someone else being merge in first?

Collapse
pilskalns profile image
Andžs • Edited

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.

Collapse
daveskull81 profile image
dAVE Inden Author

Thanks for all of this detail! I like this approach. I love Netlify and I love how it can do a build off of branches. I might use this for my final testing to run the site locally on my machine and then get a preview of what a build with the branch looks like before merging it into master.

Collapse
guneyozsan profile image
Guney Ozsan

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.

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
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
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 Author

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
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
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 Author

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
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 Author

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
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
quii profile image
Chris James

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

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
derickhess profile image
Derick Hess

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.

Collapse
daveskull81 profile image
dAVE Inden Author

How do you handle managing the branches? Do you use certain branches over and over again? Or do you create a new branch for a new feature / bug fix? Does it get messy to manage the branches between your remote and your local machine?

Collapse
fennecdjay profile image
Jérémie Astor

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.

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
sublimegeek profile image
Jonathan Irvin

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.

Collapse
olimpioadolfo profile image
Olimpio

Same here... I directly push to master.

Collapse
jingxue profile image
Jing Xue • Edited

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.

Collapse
naimlatifi5 profile image
Naim Latifi

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.

Collapse
gayanhewa profile image
Gayan Hewa

Sometimes, I cheat