Git & Friends
Imagine not using Git as your version control system of choice in 2020. Imagine still using CVS! (Not trying to discredit this great tool, but it is in fact the grandpa of today’s version control system!). You would be lying to me if you, in fact, prefer these old systems over Git in 2020 (Except of course if you are born in the ‘70s). Well then, if it’s so great, how do you use it? You Google it! What I am going to talk about is how Gitlab helps me utilizes Git in the best way possible.
Gitlab!
Now, I have already had some knowledge of Git and how it works. It really isn’t that hard, so if you haven’t, you should as soon as possible! Assuming you have understood the basics of Git (and by the basics, all of the commands), what you need next is a collaboration tool that utilizes Git.
In our PPL course, my team is tasked with creating a deliverable that utilizes a mobile app for the main users and a webpage for the admins. These two have required us into having two separate frontends. Of course, any frontends wouldn’t be anything without a backend (except if it’s static of course). Tallying up, we need to manage 3 different repositories for this single project. Lucky us, we have Gitlab (an enterprise edition for that matter, thanks to Fasilkom UI).
Each of the above subprojects is a repository of their own. Managing them couldn’t be easier!
Boarding up
Next up,… Wait, what’s next? Exactly. We need to know what’s next! We need something to write down our plans, our current doings, and our done doings!
As soon as our task is done, we’d drag our task to the ‘Closed’ section. And if we feel like taking another task soon after, we’d just drag it to the ‘Doing’ section. Never been easier!
Branching up
Now each of us can take tasks across the repositories. Sometimes, multiple tasks are needed to be done at similar times. We need to manage our git branches well before our commits started clogging up and conflicts appearing everywhere.
The branching conventions that we have agreed on are master, staging, PBI (Product Backlog Items branches), and sub-PBIs (if a PBI is worked on by multiple people). Other branches that are outside of the PBI list are usually shortlived and will be deleted after it’s merged and its intention is done.
Commit, commit, commit
You’ve probably heard of dirty commit messages. You’ve probably seen one yourself.
Working in a collaborative environment, we want to make sure that our commit messages are as clear as if the readers themselves are the ones committing it. No extra explaining and no code reading needed: perfect commit messages.
Our team is required to use TDD. Following the Red, Green, Refactor rule, this is our take on good commit messages!
Merge
Now my work is done, time to merge it with the others! The golden rule to avoid conflicts, unnecessary pulls, etc is that branches can only be merged to the original branch it was branched from (hopefully that made sense). There should be no cross merging and no pulling from branches it isn’t originated from to make sure everything goes as smoothly as possible.
Submit a merge request, and ask for approvals. Merge requests are some type of peer review: making sure you’re not screwing up somewhere, and that changes are as good as possible.
That is all for this article. Hope it is useful in some way. Thanks for reading!
Written as an assignment for my software engineering project individual review.
