Archive for the ‘git’ Category

Git is not (just) Source Control

Sunday, June 20th, 2010

After many discussions with a colleague about Git, I came to realize that Git is not merely a source control. With time it became a tool in my developer’s sandbox. To develop software effectively, I need (among other) an IDE or text editor, a prompt and countless libraries. I came to rely and trust these tools.

I used many other tools for version control but I saw them as infrastructure – mandatory in the grand scheme of things but not used to improve my productivity.

Git changed everything by allowing me to rethink the way commits and branches work.

  • By promoting small commits that do one thing but do it well, git forces me to split my task in even smaller chunks that can then be commited. This sometimes leads to architectural changes.
  • By making it possible to  reorder the commit history (git rebase -i origin), it pushes me to make each commit clean and atomic.
  • Git makes branching cheap and easy. Like you, I try to code each features in a separate branch. But unlike you, I am undisciplined and often forget. However if I start on a feature and realize it takes slightly longer than expected (and I’m talking about an hour max, not 3 days), I create a branch for that feature. It’s easy and it allows me to work in small, independent chunks. It also allows me to always be able to come back to a stable branch if I need to do a few quick fixes on another part of the project.

Git is not a mere tool – it changed the way I design and code.

Posted in git, productivity, programming | 4 Comments »

git bisect saved the day

Sunday, April 4th, 2010

I had a weird bug UI bug. I couldn’t fix it, I couldn’t get around it… everything I did seemed to make the bug worse.

So I spend some time looking at funny pictures of cats, and that’s when I remembered that I had all the power of git to help me… and I heard the cat whispering: “Git bisect to save the day!”

A Funny Cat

Funny cat? You can't be serious...

Yeah, looking at cat pictures makes me go crazy. Go figure…

Coming back to git, I read the doc and bit and away I went:

git bisect start
git bisect good last_good_release
git bisect bad master

git now sent me to a revision between those two… last_good_release can pretty much any commit identifier (a tag, the sha1 identifier…)

I compiled, ran my test… all good. The bug wasn’t in this version.

git bisect good

Git selected another commit. Compile, test… hmmm… the bug appears it this version

git bisect bad

Git bisect helps you do a binary search over your commits. It checks out something in the middle between ‘good’ and ‘bad’. You check to see if the bug is there. If it is, ‘git bisect bad’, if not ‘git bisect good’. And you continue until you find the guilty commit.

Eventually I found the culprit… It was nowhere near where I thought the problem appeared to be. I had lost a lot of time… but I found it, thanks to git!

Git bisect saved my day.

Posted in git | 2 Comments »

Make Amends with Git

Wednesday, December 30th, 2009

I’ve always been a fan of small, concise commits. I strive to make my commits as small and concise as possible.

However I often fail… Very often I commit and… discover that I yet again forgot to fix a typo. Or remove a blank line. Nothing major. But it’s pretty annoying to have every other commit log reading ‘fixed typo’ or ‘formatted code’.

With Git, I don’t have this problem anymore.

If I want to add some changes to the last commit, I simply type:

git add somefile
git commit ––amend
Tada! I just modified my last commit to include new changes.

The other option I like to use from time to time is the rebase interactive mode. I use it to merge various commits into one. It has more powerful uses (like removing commits entirely) but I never used these (yet).
git rebase -i origin

Of course  you have to use these commits before pushing anything to a remote repository.

With these these two commands, I can keep my commit log a little bit cleaner.

Posted in git | No Comments »

Git Part 2 – Share Code with (a few) friends

Saturday, November 28th, 2009

In my current project we shared code among a few team members without impacting the others using Git. Since it happened twice and I already forgot it once, I put it here as a personal reminder. Hopefully it will help you too.

Imagine you’re working on a feature and a teammate wants to use your code. But you’re not finished, your code might break the build or some other functionality is broken. You have a few choices. You can send a patch. You can accept that the build is going to be broken. Or you can use Git and create a temporary branch for the sub-team to work on.

Setting up

Let’s say you need to work on a new feature. First you create your branch:
git checkout -b myfeautre

The feature takes longer than expected. And you need help. But your changes will break the application and you don’t want to impact every one. So you push your branch back to origin:
git push origin myfeature

Get work done (with some help)

Those who want to help you can create their own local branch.
git fetch
git branch myfeature origin/myfeature

I suggest you delete your own local branch and create another one as above. Your new branch will be linked to origin/myfeature so push/pull will work as usual. If you know another way to do this without deleting your branch, please tell me.

To sent your changes back to origin/myfeature, simply do

git push origin myfeature

Now everyone involved in the feature can commit as they wish.

Cleaning up

When you’re ready to merge back to master:
git checkout master
git merge myfeature

Then delete your old branches once everything is working:
git branch -d myfeature # deletes your local branch
git push origin :myfeature # deletes the remote branch

Gotcha:
If you push using git push, it will push every thing from every branches, including master. Make sure all your branches are in a stable state when pushing. Otherwise you can push a single branch:
git push origin myfeature

I you feel I missed anything, don’t hesitate to tell me.

Posted in code, git | No Comments »

Discovering git – How to have fun with a SCM (again)

Thursday, November 26th, 2009

I started using git about three months ago. I just love it. I had lost touch with the joy of using a VCS from the prompt. I was getting pretty used to CVS at the time. Then I entered the dark era of Clearcase. Most features were available from Windows Explorer so I got used to that. And I continued after for about a year using SVN with Tortoise. I could have gone back to my beloved prompt but I had lost my way.

Then came Git. And a host of neat little features that made me want to switch right away.

The first thing I loved about Git : you don’t have any .svn folders in your project tree. Only a single .git folder at the root. Which means that you can use any tool you want to move and rename your classes and git will figure it out somehow. With SVN you had to be more careful – it happened in two of my project when someone (once it was me) thought it was a good idea to move a folder without a tool blessed by the SVN Gods. Bad idea – since the .svn folder is also moved, SVN still believes that it is committing files to the old directory.

With Git that’s a thing of the past. It’s a small thing but only this made me want to switch.

Then on my first Git project we merged two completely different repositories preserving the history of all the files. Nice.

And it’s very easy to get started. No need to setup a remote repository. You can have most of the power of git with a local repo. ‘git init’ and you’re ready to start. I now use it with all my projects, not matter how small.

And from then on, Git became favorite source control.

What are you waiting for? Try it! You won’t regret it!

Posted in git | No Comments »