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?
Oldest 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.
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 😶
Same for me !
don't know if it's habits, but it makes more sens to me has well.
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.
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.
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".
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.
This answer exists, so I don't need to write my own. Well put!
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.
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 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.
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 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.
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?
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.
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!
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.
Do you use your develop branch for all new feature work? Or do you create a new branch for each new feature?
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 donepand watch my merge and branch cleanup happen all by itself...quite satisfying.🌮 Git 'r done when you're done.
Stephen E. Chiang ・ Aug 27 ・ 2 min read
That’s a really cool function. I will have to try that out and see if it can help me with my workflow. 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'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.
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.
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.
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
Thanks for sharing Molly! I really appreciate your enthusiasm for doing all of the things you "aren't supposed to do." :)