Collaborative Coding Best Practices Implementation in My Project
Good code base management is paramount to the efficiency and speed of a development team. A messy code base will decrease the efficiency of the development process. An example of this is when a developer creates a new development branch from the wrong source branch, it will require unnecessary rebase and cause many headaches.
Codebase management includes but is not limited to good git-flow guidelines, a comprehensive code review process, and clear merge request guidelines.
Our project has two permanent branches, two reserved ready-to-use branches, and many feature branches. The two permanent branches are called “main” for approved and tested production-ready code and staging for completed but not-yet approved code. The two reserved branches are hotfix and coldfix. Hotfix branch is used to fix an already deployed bug, while coldfix is used to remove a feature from the staging branch.
The primary development process happens in a feature branch. When a developer wants to start working on a new feature, they will create a new branch to develop that feature. The developer then has the freedom to change the code on that branch. When the feature is finished, the developer has to make a merge request to the staging branch. I will explain the merge request process in the next section.
At the end of the sprint, in the sprint review, all the code merged to staging will then be tested manually by the product owner. The developer can merge the staging code to the main branch if the product owner approves all of the features in the staging branch. If the product owner rejects a feature, then the rejected feature needs to be removed from the staging branch using the coldfix branch.
Every change that needs to be pushed to the two permanent branches (“main” and “staging”) cannot be pushed directly. Those branches are designated as a protected branch, which means modifications to that branch have to use merge request flow.
Each merge request to the staging branch must be reviewed and approved by a minimum of 3 other people. The code review process was done mainly for two reasons: one to minimize the possibility of bugs being shipped in production, and the other is to make sure that other team members understand the code for every feature.
This rule is enforced directly in the GitLab repository configuration. We set it to disallow merge until the pipelines have been run successfully and three or more people have approved the merge.
