Git. Qlik Sense. Gitoqlok development set of rules.
Git Branching in Qlik Sense
There is a set of rules that we suggest implementing in the development team:
- 1.The main branch is the published app.
- 1.The main branch created by Qlik Data Architect, the developer who creates a data model and building the first version of the app.
- 2.A certain git branching naming convention.
- 1.Mixing and matching all Git branch naming conventions are not the best practice. It only adds confusion and complicates the development processes.
- 2.The team must decide which naming conventions to use once, and stick to them. Consistency is the most vital thing.
- 3.Whenever possible, divide the work between developers to avoid future conflicts while merge process:
- 1.Only one developer working on data modeling at the same time (data load script creation process).
- 2.If two developers work on the visualization layer then avoid working on the same sheet simultaneously with two developers.
- 4.Use Pull Requests in your Git provider to merge branches.
- 1.If you are faced with conflicts then use Gitoqlok's load script diff viewer and sheet diff viewer to find the root cause:
- 1.Load script diff viewer and sheet diff viewer will highlight differences between versions and helps you to figure out the changes between conflicted versions.
- 3.Commit merged version to the branch and create Pull Request again.
- 4.If the conflict cannot be resolved, the Qlik team lead (or author of the app) could pull changes from a particular branch into the main branch directly.
- 5.Link your commit to the particular task from your ticketing system. Then, you can easily navigate through changes and see the lineage between business requirements and changes.
- 1.Works well with GitLab and GitHub - use #<task_number>
- 6.Do not delete the branch from the repository. In that way, you will have the ability to roll back to any previous state of the app or review the changes.
- 7.Organize your load scripts in reusable routines and share it between developers.
I prefer to add authors’ names and/or features' names to the branch names according to the format below:
Example of the list of active branches
Example of PRs
This method allows for easy tracking of different developers’ work.