Git: Glue for collaborative work
In some point of a developer’s life, one shall meet the all-knowing Git, that keeps all history of a project since its infancy, and keeps every individual that work with it organized.
We use Git with GitLab on our group project for PPL (software development course). It’s a course requirement, but we’ll use it regardless we’re enforced or not. I think every developer that has to work collaboratively will use Git whenever possible.
A brief overview
I bet most people that will read this article already know what is Git or have heard about it before. It’s a version control system that keeps track all changes within a project in terms of commits and branches. Of course, there’s more to Git than those two but these are the main ones. One can “wrap” a certain change and give it meaningful description as a commit. There are “timelines” of commits that will grow whenever someone adds a new commit, and developers can create “alternate timelines” from a specific point of time (commit), branching out from the main one. In fact, all timelines are called branches, usually the main branch is called the master branch.
There are a lot of ways to work with Git: staging, stashing, committing, branching, cherry-picking commits, reverting commits, etc. There are plenty of tutorials and quick starts on those subjects, you can even refer to cheat sheets if you need one.
In addition to Git, we (just like most people that use Git) use a Git hosting provider, namely, GitLab. There are other providers such as GitHub and Bitbucket but we stick with GitLab on this project. We use it for sharing the Git project online so that our team can access it anywhere and on everyone’s PC. An integral part of our GitLab is the usage of pull request (or merge requests, in GitLab’s term). It is a request for adding a set of commits from a branch to another branch. It is a very useful tool to enable our collaborative work with Git.
In summary, here are our needs for this project, related to Git:
- Git with GitLab as our Git hosting provider
- Use of merge requests
- Use of issues and the issue boards (kanban-like board for managing tasks)
- A certain configuration of branches for our workflow
- Continuous integration pipelines with GitLab CI
Point number 4 is what I’m going to describe on this article.
The (Git) Flow
We define and followed a specific set of branches and way of adding changes through branches. The purpose of it is to streamline our collaborative work flow, so that everyone’s work is well organized and easier to work in parallel.
As you can see, there is a few branches already on the graph above. I’ll describe all types of branch that we have on the project.
Master branch
This is the main branch and associated with the production version and deployment environment. This is a restricted branch that only a few people can push changes to it, namely, our scrum master. Changes that are about to be incorporated to the master branch is specified through merge requests from the staging branch. Anything in this branch is the finished product.
Staging branch
The staging branch is the development branch. In scrum terminologies, changes in this branch are backlog items that are active in the current sprint. At the end of the sprint, all of the changes is reviewed and put together into a pull request to be merged to the master branch.
This branch is associated with the staging builds/deployment environments. We have a CI pipeline setup that will deploy any changes on this branch to our staging deployment instance.
Product backlog item (PBI) branch
On each sprint, there are backlog items that are going to be worked on throughout the sprint. For each items, a dedicated branch is created for the item and all changes in this branch are strictly for the backlog item only.
One step further, if a PBI can be splitted to smaller tasks, we will make a different branch under the PBI number/name, additionally prefixed with the developer’s name. At the screenshot above, I worked on dave/PBI-8-User-pagination-filter and dave/PBI-9-Case-pagination-filter to implement pagination and filter for User and Case models respectively.
Coldfix branch
This branch’s purpose is to handle quick fixes for the development/staging code. It’s not a development for a PBI so it’s not placed on PBI branches. This branch will be merged to the staging branch.
Hotfix branch
Similar to the coldfix branch, this branch is filled with quick fixes but for the production code. Changes in this branch will be merged to the master branch.
Code reviews
On every pull requests, we set an approval limit so that the pull request can be merged to its target if a certain number of approval is reached. In result, everyone will review each other’s code, find improvable parts, discuss alternative solutions, and ensure that everyone is up to date to the code growth.
It’s been a pleasant experience to work in this (Git) flow on this project. We’ve been able to work in parallel and in well organization. You can give it a try, but this is not a standardized, best, silver bullet way of organizing Git. Try to tweak and experiment with different kind of flows and find one that works for you. I can recommend trunk-based development as an alternative. Cheers!
This article is a part of my writing series about software development that cover topics such as Git, Agile framework, TDD, Clean Code, CI/CD, and many more.
