The Git work environment.

Working with Git is quite different to using Subversion. The actual contents of the project directory change to reflect the currently active branch: the directory contains a whole repository, not a checked out copy. Don’t get alarmed when files start disappearing only to reappear again when you switch branch.

I also noticed that I interacted with the version control less frequently when editing, delete, and create files. The interaction is saved until you’re ready to commit, making the process feel more seamless. I occasionally used to get into trouble by deleting files via the OS, rather that using the Subversion command.

For the majority of the time, I’ll use the Git commands, as I’m working in a Git repository. The git svn functionality is only needed as a Git interface with Subversion.

Getting ready to work.

I like the master branch to always reflects the current trunk until I choose to update it, so all my commits are made from other working branches.

I start by checking out a branch based on master to use as a base from which to work. I’ve imaginatively called it basework in this example, and as a branch of master it is linked to the same remote branch: trunk.

git branch -a

should display all your branches in the repository.

jkw@mac> git branch -a
* basework
master
svn/trunk
jkw@mac>

I work in increments based on stories, that’s another post, so I actually create a story branch from basework, that can be merge back into this parent upon completing the story. This helps cope with changes in the remote codebase.

Creating my working branches.

It’s a good idea to check that basework is up to date with the remote Subversion trunk before branching:

git svn rebase

This will either update the local repository with the remote changes, or tell you that the current branch is already up to date.

I’m now in a position to create my story branch:

git checkout -b inwork

The -b option is used to create a new branch and then switch to it. Without this option the same command is used to move between branches.

This same process was used to create basework.

I have my working repository structure, and I’m currently working on my story branch, see the asterisk.

jkw@mac> git branch -a
basework
* inwork
master
svn/trunk
jkw@mac>

The local commit.

You can see details of the changes to the local working branch using the git status command:

jkw@mac> git status
# On branch inwork
nothing to commit (working directory clean)
james@cybermac1> git st
# On branch inwork
# Changed but not updated:
# (use “git add/rm …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# modified: footer.php
# deleted: images/feed-icon-64.png
# modified: style.css
#
# Untracked files:
# (use “git add …” to include in what will be committed)
#
# includes/category-1.inc.php
no changes added to commit (use “git add” and/or “git commit -a”)
jkw@mac>

To add the new file show in the example to those being tracked:

git add includes/category-1.inc.php

If I wanted to add all of the untracked files, I could use the -A option instead of individually naming them.

Now all the files are staged, the time comes to commit them to the local Git repository:

git commit -a -m "A message to describe the changes."

Leaving the -m option off will cause Git to request comments using whichever editor is defined in your configuration files.

I now the story is complete, and all the changes committed to the inwork branch, it’s time to commit them to Subversion.

The remote commit.

I start the remote commit process by switching to the basework branch:

git checkout basework

Next I check that the remote codebase hasn’t changed, or update the changes:

git svn rebase

I’ll merge inwork into basework:

git merge inwork

I use my text editor to manually fix conflicts that arise. Git tells you where to find them by marking up the code. This is followed by another local commit, at which point the merge is complete.

Now I can try a dry run of the remote commit:

git svn dcommit -n

It’s the -n option that makes this a dry run: nothing has been committed yet. It shows you the local versions to be bulk committed if you choose to go ahead. To actually perform the commit, remove the -n, and re-run the command, it may take a while if you’ve been busy.

Verifying the remote commit.

This is where leaving the master branch untouched pays off. basework has been committed to the remote trunk, whilst master still reflects the pre-commit trunk.

I switch to master, which should contain none of my new work, and update it from the remote trunk:

git svn rebase

It should have changed to match basework, and if so the previous commit worked.

Cleaning up.

I’ve verified the commit: I have master and basework branches that are identical, so inwork is no longer needed, I’ll delete it:

git branch -d inwork

Deleting a child branch of a different parent is a little dangerous, so if you’re not in basework you’ll get a warning. Either switch to basework and try again, or re-running the command with the -D option.

If I’ve finished work on this project, I’d delete the basework branch too, but if I’m going to continue, I’d use it to create another working branch, and I’ve gone full circle.

Positive experiences.

The most frequently touted benefit frameworks have to offer is minimising the time taken to code and deploy a software solution. Given my interest in Agility, this is an attraction, reducing the time to market.

Another solid development practice is code reuse in the form of software components, and frameworks have a place amongst them. This approach offers the reliability and security inherent in widely used and tested code. Remember to choose popular software though, or this benefit disappears.

On the downside.

Applications developed using frameworks have to carry significant excess baggage in the form of unused features. This raises two main issues: your codebase will be unnecessarily large, and underused blocks of code are a breeding ground for hidden exploits and errors.

Frameworks are designed to function in a specific way, some with more flexibility than others. This much you’d expect, after all it’s the essence of a framework, but what if it doesn’t provide everything you need? For example, I’ve spent hours trying to integrate SimpleTest, a unit testing suite, to produce satisfactory results with CodeIgniter. My unit tests run well for my own libraries, but I’m still unhappy with the test coverage imposed by CodeIgniter’s MVC implementation.

Finally, they say practice makes perfect, but does reliance on any framework reduce developer skill? This isn’t a problem if everything is pre-packaged in your chosen tool, but what if a client wants something that isn’t included?

Too good to ignore.

That said, I’ve found all of these software very useful and there are far too many advantages to ignore them. But I often find myself fighting these same tools, frustrated at they’re eagerness to help me do something in a way I don’t want it done. I guess the key is to understand which is the right tool for the current job: the ultimate skill for a developer.

The Agile approach is more adaptable with respect to three key project variables; only the last of which, in my experience, is considered flexible in the waterfall world of engineering.

• Scope.
• Time.
• Resources.

Scope contraction.

Scope flexibility is something of a taboo subject. Scope is something that is added to in both a controlled manner — providing additional revenue — or uncontrolled creep. But the point of any project is delivering something that achieves the customers business goals. This is not necessarily the product that they, or the development team, initially envisaged.

One uncomfortably overspent project lead to the realisation that I could have achieved the business objective well under budget by actually drastically reducing the scope. It wouldn’t have delivered exactly what the customer expected, but it would easily have achieved their goal.

Which is more important, expectation or results? If you have a customer representative on the team it’s much easier to explain your rationale, and the chances are they’ll like the idea of results with less work as much as you do.

Timescales.

If you have a customer that doesn’t mind when you deliver, you’re a rare and lucky project manager, though you’ll never actually finish anything; deadlines do provide focus. So set plenty of deadlines, that’s what iterations and releases are about.

Try to answer the most pressing question as quickly as possible. Leave refinements and those ever present scope changes to the next iteration, it’s probably only a few days away.

This rapid cycle provides useful results, whilst allowing the flexibility to quickly change direction without that wasteful churn: just tidy this up a bit then I’ll be with you.

And the resources?

I’m afraid the project manager has to earn their money too. Line management will always have the urge to reassign any of your key people they feel aren’t being fully employed. It’s important to emphasise that the productivity of any team depends on preventing this happening.

Agile teams don’t strictly segregate workload on the basis of job descriptions, that’s why you need versatile individuals. Unfortunately, these are exactly the type of individuals that those managers will want to steal away. Removing the demarcation of tasks will help ensure everyone is kept busy and that work is conducted using the minimum number of people.

Better than the Waterfall.

I’ve found actual project goals shift too frequently for effective use of the Waterfall approach to project management. Using iterations within this framework always felt unnatural; how do you decide how may there will be and when will you actually deliver something?

An Agile approach perversely leaves me feeling more in control by worrying less about control. There are a huge array of Agile software development techniques, many of which can be adapted to other engineering disciplines.

For Software Engineering, I would recommend reading The Art of Agile Development. The Agile Alliance promote the use of Agile techniques, so take a look at the Manifesto for Agile Software Development upon which it’s all based.