DEV Community

Cover image for Do you Git Branch in personal projects?

Do you Git Branch in personal projects?

Madza on December 03, 2020

Most devs are aware, that Git Branches are awesome for developing new features collaboratively in complex apps. For personal projects, I've seen mo...
Collapse
 
thomasbnt profile image
Thomas Bnt ☕

Yeah of course! Always versionning privates projects with only me to contributor.

Example :

Main branch — For production
Dev branch — For dev and test mode
Enter fullscreen mode Exit fullscreen mode

When dev is ready, I merge all on main branch 😄☕

Collapse
 
yoursunny profile image
Junxiao Shi • Edited

I used to have master only. If CI fails or I find a typo, I'll force push. I keep getting complaints regarding the force pushes.

Now I have main and develop. I use develop just like how I used master in the past, and push to main when I'm sure I don't need force push. main has a branch protection rule that requires CI passing and forbids force pushes.

Collapse
 
arskeliss profile image
Csokán Pál András

Brilliant, I shall follow this approach as well. >Thanks for mentioning it.

Collapse
 
ronan696 profile image
Ronan D'Souza

I too follow this approach 😎

Collapse
 
florianjisopp profile image
Florian J. Isopp

I also like this approach

Collapse
 
madza profile image
Madza

Solid approach 👍

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

Not really. I tend to focus on one thing at a time so there's no point in using feature-branches, as I'd only ever have one of them at a time anyway.

I also don't see much of a point in separating dev and stable branches since that's what tags are for and in personal projects that's more than enough.

Collapse
 
adriens profile image
adriens

Same here, focusing on one thing at a time and realease fast each feature

Collapse
 
ahferroin7 profile image
Austin S. Hemmelgarn

I try to make a point to do so, but am not exactly good at remembering.

The main advantage here in my opinion is not so much having a stable production copy (that’s what releases are for) but that it lets you quickly jump back to the main branch to fix a bug independent of whatever features you happen to be working on.

Put differently, I’m a strong believer that new features should not block bug fixes that are not inherently dependent on that new feature, and doing feature development in branches makes it easier to decouple bug fixes from feature development without having to push incomplete code to your main branch.

Collapse
 
ben profile image
Ben Halpern

I'm not the world's most disciplined brancher by nature, but even I use branching on personal projects.

I took a bit of CS and am otherwise self-taught, but I'm pretty sure git was never something I took any courses in, so I mostly stumbled through learning myself— and when I first got started with git I could find myself just developing on the one main branch.... But I have long-since cut that habit.

Collapse
 
djangotricks profile image
Aidas Bendoraitis

If a feature or fix takes a few hours to develop, I push to the main branch. If it's a feature that will take several days to complete, I create a new branch.

This way, I can ensure, that I can do any urgent bug or security fixes to the main branch whenever necessary. And without pushing unfinished work to production.

Collapse
 
jacobmgevans profile image
Jacob Evans

I don't do a lot of "best practices" in early projects.

Once all the foundation is in place, I try to use as many Git best practices as I can so that I don't reinforce bad habits. Also if the project ever gets other people contributing I don't want to be a hypocrite!

Collapse
 
davidmmooney profile image
davidmmooney

I use a branch to do the work and then I send myself a PR to merge to main. This forces me into a context shift from "developer" to "reviewer". There's a lot of things my eyes will just drift past in my editor that I will flag when I'm explicitly doing quality control.

Collapse
 
0916dhkim profile image
Danny Kim

I also do this. One main branch and thousands of short-lived feature branches (e.g. enhance/add-profile-component) which get closed immediately after PR.

Collapse
 
polaroidkidd profile image
Daniel Einars

yes, all the time. I use my personal website as a type of playground so I try different things. Some of them I merge, others I drop again. I also use standard-version and commitLint to keep my master commits clean and generate a CHANGELOG.md

Collapse
 
jonathanyeong profile image
Jonathan Yeong • Edited

I do! My workflow on personal projects is very different from work. In that, I find myself making commits to the main branch way more often.

However, if I want to POC something or start building a feature that won't be finished in a single session. I'll use a branch. It's easier to rollback if things break. And you can push code to your repository without triggering a build on your main branch (assuming you have CI/CD setup).

Collapse
 
coopercodes profile image
🧸 🏳️‍🌈 cooper-codes 💻 🎮

I never used to, basically only worked on smaller solo personal projects and didn’t see the need.
I do now, as my projects are getting bigger and often have some kind of continuous integration on Main branch.
Personally I don’t think it’s needed for smaller solo projects for anything other than to get comfortable with using git processes, but for that alone it is worth it.

Collapse
 
nescalan profile image
Nelson González Escalante

Hello Madza, you are completely right. It is absolutely useful to understand and to use "Branches" in personal projects, but I think that people don't use it because they don't want to get deep in Git. 

Collapse
 
goodevilgenius profile image
Dan Jones

I use git flow for most of my personal projects. So, I have a prod branch and a develop branch. When I've got a new version, I merge develop into prod.

I will occasionally create feature branches, if I know it might take a while to work on it. But most small stuff is put into the develop branch directly.

If anybody else were working on it, I'd be more strict and always use a feature branch.

For stuff like my blog or personal website, I only have a single branch. I don't push until I've got it ready. If I'm working on a blog post on one computer, and want to switch computers to finish it, then I'll create a branch and push it there.

Collapse
 
jandedobbeleer profile image
Jan De Dobbeleer • Edited

Always. I kind of developed the habit to setup CI for everything I do and doing those things “in the open”.

It forces me to think about best practices or what they would mean in that context, without pressure (although that’s not always true).

You could argue pushing to master, providing feedback at that point in time could also work, but as soon as others join in, it makes things a lot less efficient and even accessible.

I will say this though, all you need is main when it comes to pets. Treat everything else like cattle.

Collapse
 
nbull92 profile image
NBull92

When I first started using github on my personal projects, I only used master. But then after getting concerned about showing it during job application processes. I made the choice to have a dev branch for development. With feature branches coming off of dev. I'd then push Dev into master, one I felt I had a new "version" that was solid to showcase.

Collapse
 
joelnwalkley profile image
Joel N. Walkley

I have a solo side gig that includes 2 projects for a client. One of the projects is just simple config file changes when a directory listing is updated - I push those to the main branch.
The other is a more complex full-feature app. You better believe I use branches for that one because I inevitably try something out for feature request that fails miserably. I am thankful I can just delete the branch and start over from the most recent stable develop commit,

Collapse
 
daviddalbusco profile image
David Dal Busco • Edited

Of course there is always the quick fix or whatever, but I would say that 99% of the time I always use branches for my personal projects too.

Since a year or so I even almost always create PR too, even if I merge these a few seconds after their opening. I feel like it is more traceable doing so, specially for open source work published on GitHub.

Collapse
 
serialhex profile image
serialhex

Yes, all the time. Usually for testing or to check if something else will work better and not break what currently works.

As an example, I'm working on a additive software synth and I made separate branches for the different UI frameworks I'm trying out, AND I have multiple synthesis techniques I'm testing (basically, different methods of numerical integration).

Collapse
 
_garybell profile image
Gary Bell

For most projects, yes. If it's a code/development repository I do.

I'm currently working on using GitLab to hold my blog drafts, but I only use the main branch for that so I'm not chopping and changing branches to work on different posts

Collapse
 
prkns profile image
David Perkins

Client/Team Projects: YES.
Personal Projects: YES kinda?

I'm not sure if it's all laziness or a mixture of that plus nobody to really hold yourself accountable to 🤷‍♂️

I have to FORCE myself to stick to the "best practices" regarding branching if it's only myself on a repo/a personal project. Inevitably I'd end up ditching them in favour of quick and dirty commits straight to master.

Never ideal but the only person I had to answer to was myself should anything go a bit pear-shaped. Having a team/others to call you out is a great method of keeping you in check 😃

Persisting with proper branching and best practices (although taking slightly longer to manage), is definitely worth the extra effort even if it is a personal project that nobody else will really ever see the inside of.

Collapse
 
nikzy7 profile image
Apoorv Negi

Exactly ! Sticking to the "best practices" has its advantages but its a tedious task.

Collapse
 
brandonskerritt profile image
Autumn

Yes, but only when I have an MVP :P

Collapse
 
arskeliss profile image
Csokán Pál András

Never tried it before, but I had it in mind to give it a go for a simple project. Then afterwards I will have the knowledge to fully use it as a semi-pro.

Collapse
 
adriens profile image
adriens

For apis for example targetting Heroku CD, I have at least a dedicated branch

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited

Of course, if master has been stable, and I cannot break things; I will indeed branch. I will consider tests and CI as well.

So it depends on maturity.

Collapse
 
snyderling profile image
David Snyder

I try to branch off main as much as possible but i forget sometimes. For the past few months I have even tried to make a PR for each branch even if I merge these a few seconds after their opening.

Collapse
 
ivanrusanov profile image
Ivan Rusanov

Yes. But in personal projects, I use less complicated branching strategies, than in commercial ones.

Collapse
 
shashharsh profile image
Harsh Mangal

Yes, I personally used git flow workflow for a project.
Mostly 2 branches main and develop and sometimes feature 😅

Collapse
 
devansh2005 profile image
Devansh Tayal

Mostly..

Collapse
 
amitmisra16 profile image
Amit Misra

Sure thing. Took me a while to do so on local projects but now it has become second nature.

Collapse
 
aghost7 profile image
Jonathan Boudreau

I commit directly to master and for releases I use tags. This allows me to move quickly and allows users to pick what they want to install without constant breakage.

Collapse
 
hbaguette profile image
H-Baguette

I do, yeah. I also make PRs in personal repos, for... some reason.

Collapse
 
promikecoder2020 profile image
ProMikeCoder2020

What's the reasoning behind using branches in a solo side project?

Collapse
 
0916dhkim profile image
Danny Kim

I use PR for CI purposes because it is easier to track down failing tests with PRs. And you cannot open PR without a branch!

Collapse
 
abdisalan_js profile image
Abdisalan

never -- straight to master!

Collapse
 
darthbob88 profile image
Raymond Price

Yeah, with PRs and CI/CD so I can make sure that even my dopey little project only gets deployed if it's actually working properly.

Collapse
 
gawetaner profile image
Gawetaner

Yes, i always use a git flow like approach. Except small projects that are used only once and done in an hour or two.

Collapse
 
mintjar profile image
Martijn van de Beek

On personal projects I am usually less strict. I create branches for new features and experiments when I feel the need but smaller and shorter projects are usually easy to maintain with only commits and stashing. Especially in the beginning of a project.

Collapse
 
zarszz profile image
Ganjar Gingin Tahyudin

use multi branch, ci/cd, and multi-stage

Collapse
 
katafrakt profile image
Paweł Świątkowski

Yes, but mostly for bigger experiments (new layouts, changing libs, upgrading main framework), when I want to be able to still do quickfixes on main/master when needed.

Collapse
 
bulletinmybeard profile image
Robin Schulz

Yep, ofc. :D

Collapse
 
victoredier profile image
Victor Edier

Yes, I should, I didn't but definitely I should do it

Collapse
 
rocketsumit profile image
Sumit Patidar

Yeah, I use features branches for different features and them merge in master.

Collapse
 
noprod profile image
NOPR9D ☄️

It's depends of the feature, if it's a big change and i'm not sur about what i'm doing i create a new branche ^^

Collapse
 
vicpal25_70 profile image
vicpal25

Always! In fact it’s easy to go back in history and compile features from an RC for a client when they are properly tagged and merged back into Master.