Helping Hand

Git Branches, Branching Strategies

Making and Managing Branches

The philosophy in git is to branch often. Since branches are lightweight in git, be sure you are taking advantage of this philosophy. Git branch and switch commands will be the most frequently used.

Basic Branch Commands

To view branches:

$ git branch

To view remote branches

$ git branch -v -a

To create a new branch

$ git branch new-branch-name

Create a new branch AND switch to it (two-step):

$ git branch new-branch-name
$ git switch new-branch-name

Create a new branch (one-step):

$ git switch --create new-branch-name

which is the same as
$ git switch -c new-branch-name

Switching branches

It’s easy to switch branches. You can always use $git checkout branchname to switch local branches, but after git 2.23, the switch command is the accepted method:

$ git switch branchname

If there is a remote branch of that you haven’t added to your local workspace and you use the switch command, git will guess that you want to switch to the remote branch of the same name. As switching to remote branches comes up frequently enough, here is a stack exchange that explains this more in depth.

Branching Strategies

There are many branching strategies for git repositories. If you have more than one branch, you are using a branching strategy of some kind. As git has been around for a while, people have formalized some branching strategies.

These are great for large teams and complex projects, but I’ve found they are often too complex for small teams and simple projects.

My personal philosophy, for personal and small team projects, is to keep it simple. At the very least have the master branch protected — this is the STABLE version branch. Then have a dev branch. This branch should be as stable as possible and is the branch that the majority of pull requests, and hence code reviews, should happen on. That means, lots of branching off of and back to dev. In my own personal projects I frequently only have the master and dev, but I always have at least these two. That way one branch is always safe for a quick show and tell. In any situation, I tag important version commits.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s