Getting Git Right!

Last week Celix.at brought Atlassian and their Getting Git Right event to Vienna (or Schönbrunn Palace Conference Center to be precise). By means of introduction Sven Peters talked about how Atlassian organizes a company with 300 developers working distributed, 850 employees in total, building Jira, HipChat, Bitbucket and a vast number of other developer tools.

Sven: “Developing software is a social challenge, Git helps ship software faster and smarter.” Atlassian switched from Subversion to Git 5 years ago. The technical part is one thing – the Jira team alone migrated 11 year’s work, 200+ committers, 21,000 files and 47,228 commits – Sven gives away, but the human side of things is a little trickier. Looking at its customers, Atlassian predicts 63% will have moved to Git by December 2015. That’s good news as Git users release daily to weekly as opposed to monthly, a trait of many a team using Subversion. Additionally, studies see 15% more code reviews when using Git (and their pull request functionality) than with other version control systems.

Table of Contents

• Happy developers
• Effective workflow

Happy developers

Nicola Paolucci (Git Evangelist for Atlassian) then took over claiming that Git adaptation makes for happy developers. Git brings speed as it doesn’t break the flow. Plus: it’s written in low level C by the main contributors of Linux and filesystem developers. It gives you the freedom to switch context fast (feature branching) and losing work with Git is very (very) hard. It’s easy to find history commits with git log commands and when all is lost, one can always fall back on reflog (only garbage collected every 90 days). Some nifty git log commands that were fairly new for me:
git log --after git log --before git log --diff-filter=D --summary

… and:
git branch --no-merged git branch --merged

… to verify if I indeed merged a certain branch. Nicola also explained Rebase as ‘a way to replay commits, one by one, on top of a branch’. An --interactive rebase is that plus deciding ‘interactively’ what to do with each commit (pick; squash; rework; fixup, etc).

Effective workflow

Sven Peters went on to talk about how Git introduces an ‘effective workflow and improves code quality’. Demo-ing a brand new feature in Jira that allows you to create a branch straight from whatever issue, Sven emphasizes the pain tool switching used to be. Going over the various workflows within Atlassian teams, Sven highlights the merge strategies between branches (either hotfix or feature) and how Atlassian Stash (a repository manager much like Github) allows you to set automatic merges for your branches. Sven: “Code review meetings tend to be boring and even uncomfortable as your code gets discussed, but they lead to better quality and you learn heaps from how others write code.” Making code reviews part of daily work and doing them asynchronously (read: not in meetings per se) makes the whole thing ‘way less painful’. And Git’s pull requests call for code reviews before a merge, making it a more natural process.

As a last piece of advice Sven recommends to have every line of code connected to a real life problem / issue (in your bug tracker). And he tips checking out blog.atlassian.com for tons of information about Atlassian’s migration and Git in general.