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

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.

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

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!

Inspiration

If you read yesterday's post and wonder where you can find motivation to start to practice, look at this. It's a screencast of Uncle Bob doing a Code Kata. A simple exercise, but if you look at the screencast you can guess he practices more than a few times.

I was tired tonight, but that's going to keep me going :)

10000 hours

There is no secret to developing a new skill.

Practice. Again. And again.

Looks like you need to practice a skill for 10000 hours before you can master it. That's around 10 years of deliberate practice. This applies to Olympic athletes, musicians, and... programmers.

That's one of the idea behind Malcolm Gladwell's Outliers.
The idea was also explored in Pragmatic Thinking and Learning.
Also see Peter Norvig's 'Teach Yourself Programming in 10 Years'

So what have you practiced lately?

Struggling with the Definition of Done with GWT

I've been pretty busy these past weeks starting a new project.

Since we've all followed Agile methodologies for a while, we wanted to have a definition of what 'done' means for the team.

A definition of done is useful when you want the whole team to agree when a feature is finished. It can include a mandatory code review, documentation, minimum code coverage, executable specifications, end-to-end tests... It should contain everything you need to do to get some high-quality code.

Although every one on the team is experienced, we've been struggling.

We all agreed that we needed to define what 'done' means. The content of some parts is still under discussion.

It wasn't hard to agree on a few things:

• We use Domain Driven Design for our domain as much as possible
• The domain and non-gui modules need to be unit-tested as much as possible
• We have a test map saying which kind of tests should be done for each modules (unit, integration, end-to-end)
• We need to document our module and architecture so others can join the project with too much ramp-up.
  

However on the GUI side we are still debating:

• We have a GWT application and we had no experience with the framework.
  
• GWT tests are slow by nature so we try to write relatively few of them. However for the tests we do need to write, we do not know our test coverage yet as cobertura does not seem to support GWT out of the box. It looks possible to use Emma instead of cobertura to get the coverage reports we want. However as far as I could see this would require us to patch GWT. We haven't tried it yet. It would help if we could find a simple tutorial instead of patches that need to be applied to specific revisions of the framework.
  
• End-to-end tests is an issue. Some people think it's too early to use tools like Selenium, others think it's past time.
  

Do you have experience with a project using GWT? What did you test? How? I'd appreciate if anyone could share their experience.