Confused about branches in github


I just started worked with git and github for the first time and I am a little bit confused about when to create new branches. I read through the github guide and from what I can understand you should create new branches when you are working on a new feature and keep it separate from the main branch. But the guide made it seem like you should do this when you are working on a team.

Should I just keep adding everything to the main branch and worry about new branches later?


When you work with the team, you should make an update to develop branch first, then when everything is okay make a merge request to master branch.

1 Like

It depend on you. while you work on project if you have many idea to solve the same problem you can make branch to test your ideas and when you comfortable with your solution you merge to master or you just forget that branch and continue your project.

1 Like

Branching is really most relevant when you are working on a team because it allows multiple people to work separately without getting in each other’s way. It can also be pretty useful when you’re working on your own though.
Here are a few ways branches can be helpful when you’re working on your own project:

  • You’re working on a feature for a while. You use multiple computers and want to be able to put lots of small commits into the remote repository. Doing this on a remote branch means that you can merge the whole feature into your main branch when it’s all done. You don’t have a live application with partially implemented code and you don’t have a long, messy commit history.
  • You are working on a feature that takes a while when you notice a bug. You can pop over from one branch to another and keep those efforts separate.
  • You have a couple different ideas about how to solve a problem or add a feature. You can prototype each of those ideas in their own branch, decide which one you like best, and just keep that one.

–to expand on that, branches can act as sources for different environments too. In some dev shops, it’s common practice to have several release branches which are cut-overs with your production branch or master. There would be deployment tool which would maintain the complied instances of your release branches.

This helps with maintaining versions within the production environment where real users are using your product but don’t necessarily use your latest version for technical or business reasons. You can easily work on hotfixes whilst not to disturb the already available deployed codebases until you’re ready to commit to them.

1 Like

Even when working on a solo project, I sometimes work on branches. Like if I am working on a certain feature and it may take a while, I can make a branch so that if I have to do something quick in master I can. Or, I can just work on that feature until master and then I can move it to a branch if I need to.


Thanks everyone! It makes a lot more sense now.