$ git branch new_branch

That’s all that’s absolutely required (see the man page for all the options).  And with that you now have a new branch to work on whose starting point is where you just were in your Git repository.

So what can you do with it? Or more to the point, what should you do with it?

For a single developer, you can work on an experimental code path: You’ve got an idea about how a feature should be implemented and want to get started.  But you’ve also got some regular development that needs to take place at the same time (fixes, other features, etc.).  So create a branch and code away:

$ git branch feature_x dev
$ git checkout feature_x
# add/commit... add/commit... add/commit

If the feature code works out, you merge it back into your development branch.

$ git checkout dev
$ git merge feature_x


If not, you just go back to the dev branch and delete feature_x:

$ git checkout dev
$ git branch -D feature_x

Actually, you really don’t have to delete the branch.  You can leave it as is in case you want to easily go back to take a look at that work.

For a team, branches separate each developer’s individual updates.  The distributed nature of Git sets up a default branch structure: Each repository creates a new branch in the extended repository network.

For a set of repositories configured as

the extended branch structure would look like

From your local repository, you’ll be limited to seeing only the branches on the remotes you’re connected to.

For Alice who’s connected to shared and Bob, the branches that her repository knows about are

alpha:alice $ git branch -a
dev
bob/dev
shared/dev

For Bob who’s connected to shared and Alice,

beta:bob $ git branch -a
dev
alice/dev
shared/dev

And for Chris,

gamma:chris $ git branch -a
dev
shared/dev


For a project, a branch could represent a new feature set or version of an application.  Updates are pushed up to an “integration” branch by developers as they are completed.  This is similar to the use of branching by a single developer but on a more formalized, process-driven basis.

In this case, Alice has already merged her changes for Project A into the shared integration branch.  Bob and Chris are still working on their changes and will need to pull in the updates before they’ll be able to push up to shared/integration.

Branches can also be used to represent the application’s lifecycle, with separate branches for each state such as development, test, and production.

This is the ideal case where changes flow from development to test and then from test to production.

These strategies are, of course, only a starting point.  Your actual branching structure will depend on your team and where you are in your application development cycle.  And odds are it’ll evolve along the way.

We’ll be going into more detail in future posts.