Git makes software development, well, easier

Three tips to make Git fit into your agile workflow (and vice versa)

Laura Daly Laura Daly

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.

Neben den Vorteilen, die eine flexible und verteilte Lösung mit sich bringt, verfügt Git über wichtige Funktionen zum Support und zur Förderung der agilen Entwicklung. Stelle dir Git als eine Komponente der agilen Entwicklung vor: Änderungen durchlaufen die Deployment Pipeline schneller, als wenn mit monolithischen Releases und zentralisierten Versionskontrollsystemen gearbeitet wird. Git funktioniert genauso wie die Arbeitsweise deines agilen Teams (bzw. sollte dein Team diese anstreben). 

Pro Tip:

Git is Distributed Version Control System (DVCS). Unlike CVS or Subversion (SVN) repositories, Git allows developers to create their own, personal copy of the team's repository, hosted alongside the main codebase. These copies are called forks and when work is complete on a fork, it's easy to bring changes back to the main codebase.

Git-Branching | Atlassian Agile Coach

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 ist unkompliziert und ermöglicht Teams eine mühelose Zusammenarbeit in einer zentralen Codebasis. Wenn ein Entwickler einen Branch erstellt, verfügt er im Endeffekt über eine eigene isolierte Version der Codebasis, in der er Änderungen vornimmt. Für ein agiles Team bedeutet dies, dass das Entwicklerteam durch das Aufteilen von Features in User Storys Aufgaben unabhängig voneinander bearbeiten kann und effizienter am selben Code, aber in verschiedenen Repositorys, arbeiten kann. Arbeit wird nicht doppelt erledigt und die einzelnen Mitarbeiter können sich auf kleine Aufgabenteile in vom Hauptrepository getrennten Repositorys konzentrieren, ohne dass zu viele Abhängigkeiten den Entwicklungsprozess ausbremsen.  

Pro Tip:

Neben dem Aufgaben-Branching gibt es in Git noch weitere Branching-Typen, die sich nicht gegenseitig ausschließen. Du kannst zum Beispiel Branches für einen Release erstellen. Diese ermöglichen den Entwicklern die Stabilisierung und das Härten eines bestimmten Release, ohne anderen Entwicklern in die Quere zu kommen, die an zukünftigen Releases arbeiten.

 

Nachdem du einen Release-Branch erstellt hast, musst du regelmäßige Merges in deinen Master-Branch durchführen, um sicherzustellen, dass deine Arbeit am Feature auch in zukünftigen Releases enthalten ist. Um den Aufwand möglichst gering zu halten, solltest du den Release-Branch am besten nicht zu weit entfernt vom Release-Datum erstellen. 

Git-Branches im Detail | Atlassian Agile Coach

Tipp 2: Mehrere Branches können individuell getestet werden – das solltest du ausnutzen!

Sobald Branches bereit für den Code-Review sind, übernimmt Git eine weitere wichtige Rolle im agilen Entwicklungs-Workflow – das Testen. Erfolgreiche agile Teams führen Code-Reviews durch und richten automatisierte Tests ein (Continuous Integration oder Continuous Development). Zur Unterstützung bei Code-Reviews und Tests können die Entwickler über einen Pull-Request problemlos den Rest des Teams benachrichtigen, dass die Branch-Aufgabe bereit für den Review ist. Einfach gesagt ist ein Pull-Request eine Möglichkeit, einen anderen Entwickler darum zu bitten, einen Merge deiner Branches in den Master-Branch durchzuführen, und ihm mitzuteilen, dass die Tests gestartet werden können.

Mit den richtigen Tools kann dein Continuous Integration-Server deine Pull-Requests erstellen und testen, bevor du einen Merge durchführst. So kannst du sicher sein, dass dein Merge keine Probleme verursachen wird. Diese Sicherheit erleichtert das Retargeting von Fehlerkorrekturen und Konflikten, da Git den Unterschied zwischen dem Branch und der Master-Codebasis kennt, seit die Branches voneinander abweichen. 

Pro Tip:

A long running feature branch that is not merged to the master branch may hurt your ability to be agile and iterate. If you have a long running feature branch remember that you effectively have two divergent versions of your code base, which will result is more bug fixes and conflicts. But the best solution is to have short-lived feature branches. This can be achieved through decomposing user stories into smaller tasks, careful sprint planning, and merging code early to ship as dark features. 

Tipp 3: Git sorgt in der agilen Entwicklung für Transparenz und Qualität

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.

Pro Tip:

Ein regelmäßiger Release-Rhythmus ist in der agilen Entwicklung entscheidend. Damit Git in deinem agilen Workflow funktioniert, musst du dafür sorgen, dass dein Master immer grün ist. Dies bedeutet, dass bei Features, die noch nicht fertig sind, auf den nächsten Release gewartet werden muss. Bei kürzeren Release-Zyklen ist dies auch kein Problem.

Up Next
Branching