Git is the de facto standard for agile software development when it comes to version control systems. This well-supported open source project is flexible enough to support a range of workflows that suit the needs of any given software team. Its distributed — rather than centralized – nature gives it superior performance characteristics and allows developers the freedom to experiment locally and publish their changes only when they’re ready for distribution to the team.
Besides the benefits of flexibility and distribution, there are key functions of Git that support and enhance agile development. Think of Git as a component of agile development; changes can get pushed down the deployment pipeline faster than working with monolithic releases and centralized version control systems. Git works the way your agile team works (and should strive to work).
Tip 1: Start thinking about tasks as Git branches
Git comes into play after features have been fleshed out, added to a product roadmap, and the development team is ready. But to take a step back here is a quick crash course in agile feature development: product, design, quality assurance (QA), and engineering hold a feature kick-off meeting to come up with a shared understanding of what a feature will be (think requirements), scope of the project, and what tasks that the feature needs to be broken down into to complete it. These tasks – are also known as user stories – are then assigned to individual developers.
Git starts fitting into your agile workflow at this point. At Atlassian, we create a new branch for every single issue. Whether it’s a new feature, a bug fix, or a small improvement to some existing code, every code change gets its own branch.
Branching is straightforwards and allows teams to easily collaborate inside one central codebase. When a developer create a branch, they effectively have their own isolated version of the codebase in which to make changes. For an agile team this means that by breaking features into user stories and then branches, the development team has the ability to tackle tasks individually and work more efficiently on the same code but in different repositories; there is no doubling up of work and since individuals are able to focus on small chunks of work in repositories separate from the main repository there are not as many dependencies slowing down the development process.
Once you’ve created a release branch, you’ll need to regularly merge it into your master branch to ensure that your feature work makes it into future releases. To minimize overhead, it’s best to create the release branch as close to the scheduled release date as possible.
Tip 2: Multiple branches are individually testable, so take advantage
Once branches are considered done and ready for code reviews, Git plays another key role in an agile development workflow: testing. Successful agile teams practice code reviews and setup automated tests (Continuous Integration or Continuous Development). To help with code reviews and testing, developers can easily notify the rest of their team that the branch work is ready for review and that it needs to be reviewed through a pull request. More simply put, a pull request is a way to ask another developer to merge one of your branches into the master branch and that it is ready for testing.
With the right tooling, your Continuous Integration server can build and test your pull requests before you merge them. This gives you confidence that your merge won’t cause problems. This confidence makes it easier to retarget bug fixes and conflicts in general, because Git knows the difference between the branch and master code base since the branches have diverged.
Tip 3: Git provides transparency and quality to agile development
The Git/agile story is one about efficiency, testing, automation, and overall agility. Once you’ve merged a branch to the master branch, your agile workflow is done. Likewise, merging code through pull requests means that when code is done, you have the documentation to confidently know that your work is green, that other team members have signed off on the code, and that it is ready to release. This keeps agile teams moving at a speed and with confidence to release often: a sign of a great agile team.