03 Dec 07 Powerup your development workflow with Git :D

Every one and their dogs use Continuous integration today …
And thinking about the developers and companies that are serious about software quality, they use some sort of TDD or at least write the unit tests for the written code too …
Most of them, at least the one I’m working now, do peer review too (ok, this post does not apply if you are lucky and doing XP)

With this scenario the standard work flow is:

• Write the test
• write the code
• remember to run the test
• if the test passed commit the code to the central repository
• warn some one to do the peer review
• the reviewer checks out all changes from the central repository (your and any other commits )
• the reviewer looks at your changes (after he/she separates it from the other commits)
• the peer review asks for some changes
• you change the tests
• you change the code
• you run the tests
• you commit the changes to the repository

In this workflow we have a great problem …
During all the time in bold the code in the repository probably has problems, or is not yet revised by QA …
Other problems in the standard version control systems are for example:
You cannot access the repository, and cannot commit your work if you are offline, this will cause problems, because your next commit will have more than one change set, so, it will be harder to track what commit caused a bug for example

Of course this approach has benefits too, but if you are using it, you may know its benefits

The idea of this post is to propose a little different workflow, that need a different approach to version control …

The workflow described above is very close to the one used with a centralized version control system, like CVS, Subversion, …

The one I’ll describe, needs a Distributed Version Control System, like Bazaar and Git, I chose Git because it is very fast
I still use a central repository as you’ll see bellow …

• Write the test
• write the code
• run the tests
• if test passed commit the code to your local repository
• ask some one to do peer review
• the reviewer will push your version from your machine
• the reviewer will look at your changes
• if he asks for some changes
• change the test
• change the code
• run the tests
• if test passed commit to your local repository
• push your changes to the main repository

As you can see, this workflow is a little different from the previous one, and we have the following benefits:

• The commit, checkout, create branch, merge branch operations are a lot faster and cheaper because they are done locally
• The “central server” version has always a working version, because you only push your changes there after the peer review, this ensures the build server version is always ready for a demo
• The reviewer of your code pools directly your development branch, what makes easy to find your changes, the changes he/she needs to review
• Merge is really easy

Of course there are drawbacks too, for example:

• You need to learn another version control tool (if you are not using Git yet)
• There is no access control for parts of the repository, every programmer has all the version history of the source tree, but this is easily addressable if your permission system is by project
• In a DVCS there are more concepts than just commit and update, push is not the same as commit and pull is not the same as update
• There are no good GUI tools for Git yet

I have wrote another post about synchronous continuous integration here, and you’ll find a rake task to help you if you are working with Ruby too.

So, I think that is it.
What do you think about this approach? are you using some thing like this?

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: development, git, productivity, scm, version