Benefits of Git for a developer

We have few teams who have used Subversion for a very long time. When they were told that Subversion is past and Git is future and that eventually we will move all our source code to Git, they weren’t really happy.

So I decided to gather a list of things which make developer’s life easier when using Git, focus being in the stuff which is real.

With Git…

You are in control

  • You decide when (and how) to integrate changes from others.
  • You decide when and what to commit
  • You decide when the commits are published to others
  • You decide how your commits will look like when published
  • You decide what kind of workflow you want to use

You can truly isolate your tasks

  • You can do as many local branches as you want
  • You can stash your changes aside (or in a branch) whenever you want
  • You can start a branch from any point in the history
  • There’s never need to have same repository checked out more than once on your computer

You can do things fast

  • Really many operations are local
  • You’re not limited by the access speed to the source code server
  • If source code server is offline, you’ll be able to continue working
  • Even though Git repositories come with full history, Git uses disk space sparingly. In most cases repositories on disk are smaller than equivalent Subversion repositories.

You can learn from the past

  • You can really easily check out any version of any file at any time. You don’t even need access to the source code server.
  • You have full history of the repository available at all times.
  • You can quickly view log, blame, branch or diff whatever and whenever you want

You can easily correct your mistakes

  • You can perfect your commits before you publish them. If you want, you can squeeze your 28 commits into one.
  • Totally messed up everything? Just scratch everything since last update from the server and start over.
  • Want to revert what you already published? No problem, you can safely revert any commit when ever.
  • Want to correct type in a commit message? If you didn’t publish your commits yet, it’s easy as taking a lollipop from a child.

You have plenty of backups

  • Every clone of your repository is the whole repository. If your source code server blows up, repositories can be restored really quickly.

You can focus on the most important things

  • Want to ignore some files relevant only for you? Easy.
  • Want to ignore certain files on all clones of your repository? Easy.
  • Want to create a new repository? Shouldn’t take longer than few minutes.
  • Want to publish your local branch to others? It’s one command.



Test Driven Sprint Planning – Retrospect

A while ago I blogged about trying out a different method for sprint planning.

The sprint went well, but unfortunately I had to leave that team so I couldn’t continue my experiment for longer than one sprint. I gathered some feedback from the team members to get some idea about whether the experiment was in any way good and if it’s worth to continue it at some point.

Here are the results:

The method of planning tasks as tests-based during sprint planning session:
  • Most team members thought that it wasn’t more complex than usual way of planning
  • One team member thought that it was simpler than the usual way of planning
Benefits for the sprint planning part:
  • Most team members thought it provokes thinking about how specific tasks will be tested
  • One team member thought it makes it easier to find all tasks related to a certain story
  • One team member thought that the tasks also work as acceptance criteria
Sprint execution:
  • Half of the team members had to add more tasks during the sprint, because:
    • wanted to make sure that some minor feature details were working ok
    • the tasks in a story were too little to cover it
Task granularity:
  • Most team members thought the task granularity was good
  • One team member thought the tasks were too big to be able to use them as unit-tests but too small for the story to get fulfilled. This team member wasn’t present in the planning.
Tasks as basis for the  list of unit-tests:
  • Most team members used the tasks as basis for their list of unit-tests
  • One team member couldn’t use the tasks as basis for the list of unit tests. This person wasn’t present in the planning.

So, what did we learn from this experiment? To me this looks promising, there was no single person in the team who thought this was rubbish and shouldn’t be tried again. On the other hand, there were few team members who weren’t part of the planning session and the method wasn’t explained to them in more detail. As a result one team member thought we were trying ATDD, which wasn’t the case. Several people said one sprint is too short time to make any good conclusions and I fully agree.

Regardless of this, I have heard the team still does the sprint planning using traditional methods.