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?
Top comments (67)
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 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.
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 😅
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.
Did you know Netlify has a Deploy preview feature that deploys the code of your branch on a special url ?
I have seen this! It looks really useful. I am interested to try it out.
This is exactly the way I work on my solo projects as well. I prefer master to be the stable branch at all times
I'm reading "prefer" as mandating here 😂 Who would want their master to not be the stable branch! That's just scary 😶
Some of my projects go like this as well.
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".
Same for me !
don't know if it's habits, but it makes more sens to me has well.
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 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.
This answer exists, so I don't need to write my own. Well put!
✋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
Thanks for sharing Molly! I really appreciate your enthusiasm for doing all of the things you "aren't supposed to do." :)
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.
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.
It's trunk based development for me.
I don't see a reason to deviate from that practice.
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.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.
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 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 😂
I see you haven't had the need of CI/CD yet, otherwise you would've known the point of Gitflow.
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.
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 :)
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.
branch off
----
master|---->------------>--------->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.
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?
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.
Very cool. Thanks!
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.
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.
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.
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.
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.
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.
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.
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?
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)
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.