GitHub: what is the most common pattern for using branches?

Question

Recently I have been using git and GitHub more and more, and although I understand the concept of branches in general and in theory, I do not yet understand the way people actually use branches in practice?

How do I know it is time to maintain different branches and when it is time to start committing to anything other than the master branch?

I mainly develop on my own and for myself, and I don't quite have to keep up with "production" and "development" versions, as most of my stuff is heavily in development. Still: is in this scenario any benefit for me in keeping my code in different branches?

Answer 1

I just realized I should have searched stackoverflow more and I wouldn't have needed to ask this question.

Here is a 4 year old locked question with everything I think I need to know about Git and GitHub, including the git-flow paradigm mentioned by socketwiz.

Git for beginners: The definitive practical guide

Answer 2

The chapter Branching Workflows in the book - Pro Git by Scott Chacon, explains some of the git workflows. Since git is extremely flexible, you can have your own workflow. For e.g.

Release -> Production Deployment
Master -> Most Stable tested branch - Deployed on staging
All other branches -> One branch for each feature

Answer 3

The correct branching strategy heavily depends on the project, the people working in the team and external requirements. There are some general pattern like git-flow, but you should always ask yourself if they make sense in your situation.

In your case you are working alone on the code, you don't have to maintain different versions of the code and you have no external requirements. - Hence you are pretty free what to do and all kind of sophisticated pattern are really overkill.

I would suggest having only a single branch(master) on github. In your local repository you will most likely work on master, too. You commit whenever you finished some step and you push to github whenever you are happy with the current state of your work.

Be aware of the difference between a commit and a push: As long as you did not push you can always change your commits, fix mistakes, reorder commits, etc. - Therefore you most probably do not need any explicit branches.

If you like to, you can use branches for a cleaner history. If you are developing one feature after the other and commit very often it might lead to a very long history. In this case you can develop each feature on its own branch and merge (--no-ff) it to master when finished. - Then your master branch should only contain (--first-parent) one merge per feature. But that might already be overkill in your case.

Answer 4

I recommend to keep the master branch in a state ready to release at anytime. If all your commits are really "solid", then no need to branch.

I made it a habit to work on a dedicated branch for each new feature. That way if I have to fix a bug urgently, for example because I received a crash report from an Android app, I can suspend my current work, fix the bug in master, package a new release, and get back to where I left off.

Btw, I merge my feature branches into master with this command:

git merge --no-ff --no-commit the_branch
git commit -m 'merged: improved this and that'

This way when I look at the history in gitk, I see the detailed implementation steps nicely grouped per feature branch.

Answer 5

A common paradigm is to commit as often as possible in order to have really small incremental steps in the development since this makes it easy to go back in the history if something turns out to be bad. If you're doing all your development on the the master branch only, the revision history will be very long as contain a lot of comments making it difficult to distinguish when featured were added.

Another approach is to create a branch for a new feature and do all the incremental development there. When you are satisfied with the design/code you squash the revision history and merge it back to master which then will have a very clean history which is feature based and you don't need to see all the small steps that got you there.

Answer 6

Here is a pattern called git-flow that I like to use: git-flow