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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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?
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.
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!
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.
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.
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.
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.
I commit to master no matter if it's a personal or day job project
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.
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.
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 do that all the time on my solo projects. I only use branches for parking experimental code, and release preparation and post-release maintenance.
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.
Same here... I directly push to master.
Sometimes, I cheat
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.