RIC ROBERTS

This is the second post in my Getting to grips with git series. Last time, I covered the basics; this time we’ll explore branches and tags.

Branches

How branches in git work

In git everything is treated like a branch, so they’re quick and easy to create and manage. Branching doesn’t involve copying the files into a new directory, like in other version control systems. Git keeps track of only the most recent commit to that branch and from there, it can figure out all the changes in that branch. (The history of changes in git takes the form of a Directed Acyclic Graph).

Branching marks the point that files in the repository diverge onto two different paths. Each branch keeps track of the changes separately. Changes in branches can be merged together later if you like.

So, what would you use a branch for?

You can use a branch for whatever you want, but they’re especially useful for keeping experiments or new features separate from bug fixes to already-released code.

Making a new branch

To make a new branch from the current one, use:

git branch <name of new branch>

If you then run the branch command with no params, it will give you a list of all the existing branches (with an asterisk indicating the current one):

> git branch
* master
  my_new_branch

Working with your new branch

Now, to start working on your new branch, you need to check it out. Remember, I mentioned last time that checkout means something different in git to subversion? In git, it refers to switching your working tree over to using that branch. Don’t worry – any committed changes will safely remain in the other branch (even if you’ve not pushed them to your central repository).

git checkout my_new_branch

Pushing your branch into Github

Once you’ve made some changes to your branch, it’s likely that you’ll want to share them with your colleagues. To push the branch up to Github, you can use:

git push <remote_repository> <branch_name>

e.g.

git push origin my_new_branch

Getting an existing branch from Github

What if someone else has made a branch and pushed it up to Github already? You can see a list of all the remote branches for a repository with:

git branch -r

It’s then simple to create a local version of that branch:

git branch <name of branch> <remote branch> 

Merging branches

As I mentioned earlier, branches are commonly used as part of a release-process, to keep fixes to ‘live’ code separate from ongoing development. At some point, it’s likely that you’d want to get the bug fixes into the main development branch. This is where merging comes in.

There are three main types of merging:

• Straight: Commits are just merged in as they appear in the source branch.
• Squashed: All commits from the source branch are applied to the target branch as a single commit.
• Cherry picked: A single commit from the source branch can by applied to the target branch.

For all types of merging, commands must be run from the target branch (i.e. the one you’re merging to).

Straight Merge

git merge <source branch>

Squashed Merge

git merge --squash <source branch>

Note that for squashed merges, the changes are applied as staged (not committed).

Cherry Picking

git cherry-pick <commit name>

... where the commit name is the SHA-1 hash of the commit you want to pick (or at least, enough characters of it to uniquely identify a commit). You can stage multiple cherry-picked merges by adding the -n argument.

Merge tracking and conflicts

Git has automatic merge-tracking that keeps tabs on what commits have been merged together, and so wont merge the same thing twice. Git will also warn you when you try to merge and it can’t resolve merge conflicts automatically.

Tags

Tags are used to mark a certain point (such as a milestone like a release) in the history of a repository with a name.

To make a tag based on the current working tree’s latest commit:

git tag <name of tag>

To get your tags up to Github, you need to run:

git push --tags

You can make a branch from a tag by using:

git checkout -b <tag name>

How should I use tags?

Git is very flexible and it’s up to you based on your project’s requirements, but tags are very useful for managing releases. For example, you can tag the last commit that went into a release, so that if a bug arises in the released code, you can retrospectively branch from that point (even if you’ve already started work on the new features).

Next time…

There’s still plenty more material to cover, including rebasing, diff, undoing changes, forking and git tools.

Update: Part 3: rebasing is now available.