What are GitLab Flow best practices?
Using these best practices, software development teams can use GitLab Flow to software development.
When software development teams rush to accelerate delivery, they may end up with messy or complex workflows. Organizations that have transitioned from another version control system are especially likely to deal with challenging processes that may slow down development. When teams use GitLab Flow, they can use feature driven development and feature branches with issue tracking to ensure every team member works efficiently. Using these GitLab Flow tips, software development teams can simplify the process and produce a more efficient and cleaner outcome.
Using feature branches is a simple way to develop and keep the source code clean. If a team has recently transitioned to Git from SVN, for example, they'll be used to a trunk-based workflow. When using Git, developers should create a branch for anything they're working on so that contributors can easily start the code review process before merging.
Some developers set up their CI to only test what has been merged into the
main branch, but this is too late in the software development lifecyle, and everyone - from developers to product managers - should feel feel confident that the
main branch always has green tests. It's inefficient for developers to have to test
main before they start developing new features.
When working on a
feature branch and adding new commits, run tests right away. If the tests are taking a long time, try running them in parallel. Do this server-side in merge requests, running the complete test suite. If there is a test suite for development and another only for new versions, it's worthwhile to set up [parallel] tests and run them all.
Don't test everything at the end of a week or project. Code reviews should take place as soon as possible, because developers are more likely to identify issues that could cause problems later in the lifecycle. Since they'll find problems earlier, they'll have an easier time creating solutions.
If developers don't want to deploy
main every time, they can create a
production branch. Rather than using a script or doing it manually, teams can use automation or have a specific branch that triggers a production deploy.
When pushing to a public branch, developers shouldn't rebase it, because that makes it difficult to identify the improvement and test results, while cherry picking. Sometimes this tip can be ignored when asking someone to squash and rebase at the end of a code review process to make something easier to revert. However, in general, the guideline is: Code should be clean, and history should be realistic.
After identifying a bug, a problematic action someone could take is fix it in the just-released version and not fix it in
main. To avoid it, developers should always fix forward by pushing the change in
main, then cherry-pick it into another
Developers should not only say what they did, but also why they did it. An even more useful tactic is to explain why this option was selected over others to help future contributors understand the development process. Writing descriptive commit messages is useful for code reviews and future development.
Discover how GitLab streamlines the code review process