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)
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 ^
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?
branch off
----
master|---->------------>--------->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.
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.
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.
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.
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.
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.
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.
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.
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.