My Workflow With Git

05.24.2010 // Development // Thiago Alves // 1 Comment

I know the last post was something slightly better than crap, but I just tried to give a brief introduction about Source Control Management to write this post about git, the one I choose for all my personal work.

Sometimes you’re doing some personal project like a test algorithm, your personal web site or the next millionaire software; doesn’t meter, if you’re like me and like to test on your own stuff, you probably get to a point were you changed so much that going back to the original state takes so long that you choose keep trying to fix the current one.

Well, for me git came to save me for those hassles and once I started to do it, I install git on every machine I work… even in my day job!

Keep reading to find out how it works for me!

From now on, I’ll assume that you, at least, knows what git is and how it basically works. If you don’t, check git’s official site and its documentation, but to make your life easier I’ll recommend you the first 4 tutorials on the documentation section:

• The official Git tutorial
• Everyday Git in 20 commands
• The SVN Crash Course
• Git for the lazy

We’re good? Ok, lets move one!

The start up of a new project

By a “new project” I mean “every thing you do on your computer that can be isolated”. This means that a project can be a shell script, a word processing document, a spreadsheet, an entire site or even a complete program.

I’ll not lie to you, there are many “projects” on my computer that don’t have a git repository but trust me, from now and then I always regret myself to not had created one.

Anyway, first thing most people do is to create an empty repository and start doing their stuff inside it. Well, that quite doesn’t work for me. See, most of the times I create 3 or 4 start up projects before be completely satisfied with it and start coding, for that reason I only create a git repository when I have the basic skeleton of my future project. When I’m satisfied with my starting project, then I issue the following commands:

$ git init
$ git add .
$ git commit -m "Initial revision"

I use these commands so much that I have an alias to do them for me:

$ alias projinit='git init && git add . && git commit -m "Initial revision"'

Ok, with that ready my next step is to ignore some files that I don’t want to track, like .o files in C/C++ project. To do so I edit the .gitignore file and add those extensions there. Again, I’ll assume you know how to do it, if you don’t, check my recommended links above.

The code workflow

You might ask:

“How often you commit your work?”

Well, I always do commits when I finish a small milestone of my project, and when I say small, I mean it. For instance, if I’m doing a Vim plugin, when I finish the start code snippet that contains a check if the plugin is already loaded, I commit. Check it out:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
" AutoClose.vim - Automatically close pair of characters: ( with ), [ with ], { with }, etc.
" Version: 2.0
" Author: Thiago Alves <thiago.salves@gmail.com>
" Maintainer: Thiago Alves <thiago.salves@gmail.com>
" URL: http://thiagoalves.org
" Licence: This script is released under the Vim License.
" Last modified: 05/11/2010
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
let s:debug = 0
 
" check if script is already loaded
if s:debug == 0 && exists("g:loaded_AutoClose")
    finish "stop loading the script"
endif
let g:loaded_AutoClose = 1
 
let s:global_cpo = &cpo " store compatible-mode in local variable
set cpo&vim             " go into nocompatible-mode

For me, this worth a commit!

Of course I forgot to commit that often, but when that happens I use the cherry pick commit from git where you can selective choose which lines you want to stage, then I create as many commits as it needs.

Please, don’t think I keep committing my code every dozen lines, is not like that. Some times it takes me one or two days and about 5-6 files to I feel like my changes worth a commit. Honestly this is up to you decide how often you’ll gonna commit.

Here is a snapshot of my git repository from my Vim plugin called Autoclose:

At this point I have a growing repository with a bunch of commits that keeps track of what I’m doing and suddenly I get to a point where I’ll try a crazy change on my code that will delete a big chunk of code. What do I do?

Branching

I create a branch! On git it is as easy as type one command line:

$ git checkout -b mycrazytest

Done! I’m on a new branch ready to rape my code as much as I want without loosing any code done so far.

When I finish this crazy test I check if it worth something and if it is, I go back to my master branch and merge the changes:

$ git checkout master
$ git merge mycrazytest

And if I feel like this was all crap, I just delete the branch:

$ git checkout master
$ git branch -d mycrazytest

This way I never loose code and I feel confident to change  as much as I want.

Going pro

Some project demand a better approach then a master repository and a bunch of test ones. For these cases I always follow this steps:

1. Initialize my repository;
2. Create a development branch
3. Do all my coding on development branch
4. When project reaches some release milestone I merge development with master and tag master with the milestone description
5. Get back to development branch and continue coding

This small recipe is helping me doing some Indie projects on a more professional way and so far it’s working like a charm.

Now that you know my workflow be prepare to 2 or 3 more posts about git. I’m planning to write about git host (public and private, specially on Webfaction) and about repository conversion (from SVN to git, Mercurial to Git, etc.).

With some luck I make the action of writing here a habit and sooner or later I will have some people actually reading this blog

Cheers!