How Git makes us more “agile”

4 min readFeb 26, 2020

With this post, I will unravel the unprecedented contribution of Git to our workflow — creating a more agile team, both literally and figuratively.

This article is written as an individual review criterion of PPL CS UI 2020

What does it mean to be agile

In software development, agile refers to methodologies based on iterative developments — where users’ requirements and technological solutions grow alongside each other to deliver engineering solutions as fast and as satisfying as possible.

With this post, we will see how using Git promotes agility on our team.

How Git promotes Agile

To be agile is to be able to work fast, without sacrificing the quality of work being delivered. In a collaborative environment, to be able to rest assured that you can focus on your work without having disrupted by others’ work is amazing.

Branching: more isolated task delegation

We plan the things we want to deliver by this sprint and we delegated the works to developers through issue boards provided. Of course, we cannot let them all code in one computer or have them work individually then someone copies the work from all developers and gathers them in one place.

So, each task — feature, fixes, etc — will be separated into branches, where the assigned developers can work individually separated from the main branch (e.g. master, or in our case — staging). This way, each developer can work individually knowing that their work will not disrupt the main code. In the end, this will result in faster and less error-prone developments.

Git Flow — This visualizes the “tasks”, divided into PBIs and how it translates to branches. https://leanstack.blog/2018/04/20/gitflow-workflow-for-projects-that-have-a-scheduled-release-cycle/

In our team backend’s repository, this is how it looks like:

These branches are the product of the issues we chose to deal with in the sprints.

Testable Individual Branches

Then, comes the time when each developer will have to merge their work to the main code branch. To ensure the fast delivered work is also delivered without errors, Git provides testing on individual branches. Prior to merging, the branches are able to be tested and reviewed by other developers.

Then and only then the branch should be merged to the main branch. Later on in the target branch (main), another integration test can be done prior to deployment. This will give us confidence that the merge won’t cause any problems when integrated into the main branch.

Merge Request after passing tests and approved

If you have long-running branches, separate them into short-running ones. This will provides more iteration on your work since integrations can be done more frequently — creates faster deliveries.

Work transparency

The codes being merged from merge requests from branches are documenting your work. Everyone that is concerned (developers/owners) will know about what you have done and what you have contributed to the product.

In addition to that, if you follow that each issue is given its own branch (just like the branch shown above), anyone who is concerned can be sure that if the branch is merged then the work is done.

This way, transparency of work is given to the product owners, stakeholders, and fellow developers. If you use a scrum board for tasks, the works done can be visualised better:

That is all for today, have fun developing!