Tramp

PXG - Git

For people really interested in Git I recommend reading http://git-scm.com/book, I’m working my way through this currently because I have a really interesting life.

Paul - Git

I think SourceTree is a really decent git client. I do most things in Terminal for general usage, then flip to SourceTree for anything that benefits from a gui eg. constructing line-by-line commits, resolving merge conflicts etc. It’s probably good for rebasing and cherry-picking as well, but I don’t do those often enough to be sure. Also makes it super-clear whether there’s anything stashed and has built-in git-flow support. Speaking of which…

git-flow can be a bit mad for rolling projects, but can be effective for anything that can have a release cycle and naming scheme like Semantic Versioning applied (modules, APIs in particular, but also websites if done with care). This brings release branches into the mix, after which the git-flow model makes more sense. Releases are automatically tagged when done, and show up in the Github “Releases” tab, which makes it very easy to see broad progress without getting tied down in individual commits. Imagine it’d make rollbacks easier, if deploying from version tags. Hotfix branches also trigger the release process (with a patch number version bump, rather than minor) and end up in both develop and master.

This all introduces some additional overhead but can bring a really clean history. An alternative is the more lightweight “simple git workflow”. Rotten is good for managing old branches, on this or any other project that doesn’t have an automagic way of removing already-merged branches.

Someone said “How many people have no JS?” GDS tried to answer this question a few weeks ago for people using GOV.UK. They came up with 1.1%, made up of 0.2% actively disabled and 0.9% enabled but don’t receive for whatever reason. Be interesting to know how much that changes across different sectors.

Jed/Mike/Pete - working as an autonomous collective

How did you decide task order? Were you able to decide based on what would work for all of you, or was your queue handed down from on-high?

We decided everything ourselves internally - little or nothing predefined for us. We’ve divided the build up into smaller tasks and between us decided who should work on what. Jed has taken the lead in the app development because he’s the only one on it full time, Mike and Pete have generally had a supporting role, but at various times both of us have added large contributions to the core of the app. So tasks usually are split fairly arbitrarily, whenever someone finishes something, they get to start on whatever they fancy doing next. Especially so in the last few weeks as we’ve been tidying up Github issues in preparation for the initial launch, there have been a few times when someone has taken on a specific task because it’s based on a section of the site they built initially, but in general it’s a fairly even distribution.

I think it has all worked really well, and been good fun in the process. Definitely up for more collaboration like this in future…