Surviving the transition between SVN and Git

A guide for the commandline-adverse

As a Microsoft ‘fanboi’ I was at first rather unhappy when the people promoting Git kept insisting that “the command-line is where there power is at” and that “GUIs aren’t good enough”.

They were, in part, right; but there’s a lot you CAN do with the right GUI. I for one am a fan of TortoiseGit (http://code.google.com/p/tortoisegit/)

In this blog post I’ll outline a few common operations that you can do using a combination of Git Bash and Tortoise Git, and a few that are best done in Bash alone (don’t worry, we’ll try to keep the use of Bash to a minimum; Note however that that it will probably be helpful if you were already familiar with basic git concepts (branch, commit, rebase, etc)

Show Log using TortoiseGit

Let’s say you’ve already cloned a remote repository; I’ll use TortoiseGit’s repository as an example, checked out from here http://code.google.com/p/tortoisegit/source/checkout   

The first neat thing you can do with Tortoise is have it show you a nice, easy-to-understand commit graph/history:

Right click your repository and select ‘Git Show log’

Make sure you’ve got “All Branches” checked, so you’re not missing any unrelated branches from your overview.

Now for a short map legend:

- The commit in bold is the commit you currently have checked out. This is the commit you can currently view/compile/modify; any commit you make at this point will be based on the commit shown in bold

- Tags with an orange-ish background, such as origin/master are remote branches: branches that exist(ed) on the repository the last time you did a clone/pull

- There can be at most one tag with a red background, such as master: this is the branch you currently have checked out (earlier I’ve mentioned that you can check out a commit: checking out a branch is essentially the same as checking out its corresponding commit, as far as your working dir is concerned; i.e. you’ll get the same code changes)

- Tags with a green background (not shown in the above pic, since we haven’t created any yet) are local branches. While working with git, branches will be your bread and butter, you’ll be creating a lot of them

Commit using TortoiseGit

To get to the commit screen, just right click on your repository clone, and select Git Commit (note that it will display what branch you’re about do do a commit on, in this case: “master”)

The main difference between command line Git and TortoiseGit is that Tortoise abstracts away the concept of “staging”; basically whatever files have a checked checkbox get staged and committed once you hit OK

Now, let’s look at that graph again and see what happened

As you can see, my commit got added on top of the previously-bold (checked-out) commit.

Also, since I committed my changes against the “master” branch, it also moved up to my new commit.

Now, fortunately this being Git, my changes will not be visible by anyone but myself; no need to worry about Sven being angry at me for messing with those txt files.

Create Branch using TortoiseGit

But wait! I “accidentally” did something wrong! I wanted to keep master and origin/master in-sync, and make my commit on a new branch (that's because we want to use Gerrit, otherwise it would probably have been ok to commit against the master branch). 

So let’s see how to fix this

What we want to do is:

1)      Create a new branch on my new commit

2)      Restore master to its original state

And we will want to do it in that order, since if we were to move master ‘down’ one commit on the graph, my new commit would be left without a branch on or ‘above’ it and Git would delete it, i.e. Git 'deletes' all commits that don’t ‘lead up to’ a branch (actually, commits lost in this way aren't lost forever, it's just a bit complicated to restore them).

Creating a new branch: Right click on your repository, select Create Branch, give the new branch a name you’ll remember and hit OK.

 Let’s check that Log again:

Now that we’ve got a branch to hold our new commit, let’s take the master branch back down to be in-sync with origin/master.

Interactive rebase using Git Bash/Extensions

(AKA: one of your two best friends after doing something silly)

This is the part where we’ll have to use Git Bash, I have yet to find a way to do an equivalent operation using Tortoise. (I know, the white-on-black Bash window tends to repel Windows users, just roll a save vs. Willpower to avoid cringing).

Hint: Git Extensions (http://code.google.com/p/gitextensions/ ) will provide a more Windows-friendly editor for interactive rebasing

Open a git bash window on at your repository, and type in:

git rebase -i HEAD~2

And hit enter.

Now, it could have been HEAD~10 or any other number, depending on how many commits you want to be able to pluck out of your branch.

This is what pops up if you have Git Extensions installed:

Do what the nice red font says and you should end up with the following graph:

Master is in-synch with origin/master and our commit is sitting on top of it on our new branch called txtFileChanges

Amending a commit in Tortoise

(the other one of your two best friends after doing something silly)

Let’s say I wanted to change a commit: perhaps I wrote an incorrect commit message, or I left a few files out. Here’s what we need to do:

1) Checkout (Switch to) the commit we want to change

Checking out a branch is straight-forward: right click on it in the Log view and choose Switch/Checkout to “<name>”

2) Amend the Commit

We’re now ready to do amend a commit. Right click the repository folder, select Commit -> “txtFileChanges”; In the commit window, check the “Ammend Last Commit” box.

You can now edit your commit message, add new files to be commited, or remove committed file changes (note: you will lose those changes permanently)

And that’s it for the first part of this guide. The second part will (hopefully) follow soon and contain instructions on how to use Gerrit