RicRoberts

Last month, I posted my first set of five ruby-related blogs for your delectation. Here’s five more for your RSS reader:

• Ruby Inside: A Ruby news, links, code and tips blog, to which I’ve recently started contributing.
• Robby On Rails: A blog by Robby Russell from Planet Argon. Full of useful rails tidbits.
• A Fresh Cup: Mike Gunderloy’s mostly link-based blog focusing on Ruby On Rails. I always find something interesting here.
• Alex Young: Blog from a London-based web developer, who runs Helicoid and QuiteUseful.
• Igvita: Ilya Grigorik’s blog, often featuring Ruby-related articles.

This is the third post in my Getting to grips with git series. In previous articles, I’ve covered the basics and merging, branching & tags. This time, I’m going to introduce the concept of rebasing. I think it justifies its own article as it’s a potentially confusing subject.

Rebasing

Rebasing is similar to merging in that it allows you to apply changes from one branch to another. Rebasing lets you replay/rewrite the history in your current branch against a particular point on another branch, so you can choose where in the history your changes appear.

For example, if say you branched from master to work on a new feature. When you branched, the state of the master branch was A, and after you’ve added some code, the state of your new feature’s branch is AB (i.e. A plus some new stuff B).

---A        master
   \
    ----AB  new feature branch

After working on your new feature for a bit, the state of the master branch might have moved on (maybe some bug fixes have been applied).

---A---------A'  master
   \
    ----AB       new feature branch

Now, to get those fixes into your new feature’s branch, you can rebase. From the new feature branch, run:

 git rebase master

This will bring the fixes into your new feature’s branch, as if you branched after the fixes were applied to master.

---A---------A'        master
             \
              ----A'B  new feature branch

A quick look at the history will confirm this.

 git log

Finally, to get your new feature into master, you can just do a merge as described in my previous blog post (from master):

git merge <new_feature_branch>

The steps I’ve just described form a common workflow. i.e.

1. Create a new branch B from an existing branch A
2. Make changes on new branch B
3. Rebase updates from branch A into branch B
4. Merge changes from branch B into branch A

Useful references on rebasing

• git rebase man page
• Gitguru: rebase vs merge
• James Bowes: Keeping your branches current

Next time…

I still have a couple more posts planned, to cover a few more commands, git tools and forking.

At the end of last week, I booked my tickets for the Rails Underground conference in London which takes place towards the end of next month.

The speaker line up is really impressive, and features (to name but a few) Obie Fernandez, DHH, Robby Russell, Jim Weirich, and Dr Nic.

It will also be a good chance to catch up with some London Rubyists who I haven’t seen for a while.

Drop me an email or leave a comment if you’re attending too and want to meet up. See you there!

At Swirrl, we’ve long been convinced of the benefits of the semantic web and linked data – and indeed those technologies underly the design of our application.

My co-founder, Bill, has just started a new blog where he’ll be exploring these topics in more depth: www.webofdatablog.com.

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.