GitLab: Working in a Team Starter Pack
This article was written as an individual review assignment of PPL CSUI 2021
So, you’ve just started to work in a team and they asked you to start using GitLab from now on? Don’t worry, because this post will show you the basics of GitLab so that you and your team will be able to work together graciously.
What is GitLab?
I believe it is best to first start with explaining what GitLab is.
GitLab is a Git version control repository management service. There, a group of developers can work together on one or multiple Git repositories. By working together, I mean they basically can see and evaluate each other’s coding progress, make comments on each other’s code, and integrate the codes of one another. Now I won’t be explaining much about Git in detail, but I will be focusing more on how we can use GitLab to work as a team.
There are many ways to work as a team in a Git version control repository management platform, but in this post, I will be explaining what I think is the best way to work well together in GitLab.
Dividing and choosing tasks
Before we start coding, we need to gather requirements, and from that requirements, we can break them down into a list of Product Backlog Items (PBIs) that need to be done, you can think of PBIs as use cases, features, etc. And from there, we can start dividing them into smaller tasks.
In GitLab, there’s a feature that might help us out with this process.
First, you need to open up your repository in GitLab, then go to Boards which you can access through the Issues menu on the left.
There, you will find an interface like this:
Usually, there are 4 boxes on the board:
- Open: Filled with tasks/PBIs that are not yet assigned to a member of your team.
- To Do: Filled with tasks/PBIs that are already assigned to a member of your team, but still have no progress at the moment.
- Doing: Filled with tasks/PBIs that are currently in progress but still not finished.
- Closed: Filled with tasks/PBIs that are already done/dropped.
After you and your team discussed what tasks need to be done, you can put all of those tasks in the Open section.
Then, your team can discuss who will be assigned to each task and add labels to it. You can do so by clicking on the task.
After you finish configuring the task, you can move that task from the Open section to the To Do section. Then, if you want to start progressing the task, you move that task to the Doing section. Then, after you finish the task, you move that task to the Closed section.
The branches and the merge
When working in a team, of course each member of the team should have their own branches which will be the place where they can code without anyone else from the team conflicting the code. But to make the branches in our repository seem more organized, there should be 5 different types of branches in a repository, which are:
Master branch
The master branch is the place where we put in the source code that the team thinks is ready to be deployed to production. Keep in mind that the code in this branch will be the one that your users interact with.
Staging branch
The staging branch is the place where we put the code that is still in development but is already integrated with all the codes from all members of the team. The code in this branch should be deployed as well, but in a different environment from the production environment. If your team thinks that the code in this branch is ready to be deployed to production, you can merge this branch with the Master branch.
You can do so by going to the Merge Request menu on your GitLab repository like the one shown here:
You will see an interface like so:
Click on the New merge request button to create a merge request. Then you can set the source branch to the Staging branch, and the target branch to the Master branch.
After creating a merge request, your team can then review and approve that request.
In the overview section of the merge request, your team can see the description of the request, the approve button, and the comments that your team gave to your code. Once there are enough approvals from your team (which depends on how many approvals needed when creating the request), a merge button will be shown that is used to finally merge the branch to the Master branch.
You can also see the changes that were made in the Staging branch by clicking on the changes section. There, you can also make comments about the change by clicking on the left side of the line of code that you want to comment on.
The comment will then be shown in the overview section.
Product Backlog Item (PBI) branch
There will most likely be multiple PBI branches in your repositories because for each PBI that your team has, there will also be a PBI branch that is dedicated to that PBI. When creating a PBI branch, you first need to make sure that the branch contains the same content from the Staging branch.
Then, after you finish coding in the PBI branch, you want to make sure that there are no conflicts with the current Staging branch, you can do so by pulling the Staging branch first before pushing.
Finally, you can create a merge request. You can do so by going through the same process as the one I’ve explained before, except, the target branch will be the Staging branch and the source branch will be your PBI branch.
Hotfix branch
Whenever you encounter a bug or an error in the Master branch, don't panic. What you need to do is to create a new branch called Hotfix branch from the Master branch and then fix the bug or the error there. Once it’s fixed, create a merge request to the master and let your team review it, approve it, and finally merge it.
Coldfix branch
The Coldfix branch is used to rollback your code. This is used for cases such as when your team once approved and merged a merge request of yours but then for some reason changed their mind and wants to go back to before the last commit. If a case like that ever happened, all you need to do is create a new branch called Coldfix branch and there, you can rollback your code using the git reset command. And same as always, if you think you’re done, create the merge request.
That is all from me, friends!
Good luck on your projects and I hope this helps your team work together in GitLab!
God bless.
References
Buku Panduan Git PPL 2021
