Introduction
There are many attributes of good quality software: robustness, testability, resilience, modularity, maintainability, usability, security, performance, scalability and more depending on the type of application you are building. To achieve all this you need to have a simplified workflow. In this post we will be sharing 11 thumb rules of GitLab flow which will produce a much cleaner and efficient results.
11 Thumb Rules of GitLab Flow
1) Create feature branch to avoid direct commits on master.
Feature Branch is just a different branch in the Git repo which helps in avoiding direct commit to the master. It helps in reviewing code before merging.
The basic idea of a feature branch is that when you start work on a feature you take a branch of the repository to work on that feature.
2) Testing of all commits is necessary, not just the ones in master.
If you have configured your pipeline in such a way that it only test the commit in master, change it. You should be confident before running tests on master branch.
3) Code reviews should be done before merging to master, not after.
Do code reviews regularly because it’s easier to figure out things earlier that can create issues rather than spending time later on the same thing.
4) Run all the tests on each and every commit.
Don’t wait for the right time to run tests on your commits. Even if you are on a feature branch run the tests then and there. You can also run the tests in parallel if its taking more than 5 minutes.
5) Do automated deployments instead of manual.
If you are not ready to do deploy on master, create another production branch and automate your tasks there, instead of manually logging in and running numerous scripts.
Spending less time on deployment simply means you can save money and release more frequently.
6) Users have the privilege to set tags, not CI.
Tags are set by the user and then CI will take actions based on the set tags.
7) You should never rebase the pushed commits.
It is not advisable to rebase the pushed commits because it makes difficult to follow afterwards and it also breaks Cherry Picking.
It’s OK to rebase published commits under one condition, that everyone who will have to deal with the problems created, has agreed in advance to deal with them.
8) Releases are created based on tags.
Tagging something will create a new release.
9) Bug fixing should be done in master first and later in release branch.
The worst approach you can follow for bug fixing is to fix them in just-released version and not in the master. You should always fix forward. After fixing in master, you can cherry-pick the changes in release branch.
10) Everything starts from Master and ends at Master.
To avoid any long branches, you should at first checkout master, work on your feature, raise merge request and target master again. Also, review your complete code before merging it to master.
11) Follow commit message standards.
Your commit message should clearly define what you did and why you did it.
- Each fix should be committed as a separate change.
- It’s very useful to reference the git issue on the body of your commit message.
- Limit the subject line to 50 characters.
- Capitalize only the first letter in the subject line.
- Don’t put a period at the end of the subject line.
Conclusion
In this post you have learnt the 11 rules of GitLab Flow for getting efficient and cleaner results.
- Create a separate branch to avoid commits on master, it is also advisable to do regular testing on the features you are working on.
- Avoid manual deployments, save time and money by automating the process.
- Fix forward, bug fixing should be done in master branch first and then in release branch.
- Make your intent clear behind every commit in a commit message, it should clearly convey what you did and why you did it.To learn more about Git Branching Flows, follow this famous article by Vincent Driessen – https://nvie.com/posts/a-successful-git-branching-model/
