Similar to GitFlow and OneFlow, SwatFlow follows the Feature Branch Workflow, which entails doing any active development (new features, improvements, bugfixes, ...) on separate, independent 'feature/' branches.
Feature branches are created from develop and allow developers to work on their tasks, independent of one another.
Once the feature has been finished and has been approved by QA, a Pull-Request should be done to merge it into develop.
After the merge, the feature branch should be deleted as the branch is relevant during the development process, it is a short-lived branch.

To improve the model even further, the following actions are recommended:

• Before doing a Pull-Request, developers should rebase onto develop to ensure no merge conflicts appear during the PR process.
  This avoids pilling up merge issues when PR are accepted, providing a more swift development.
  This is a requirements due to the way developers are able to work independent of one another, which means that developers can make changes to the same files without being aware of this.
• Before doing a Pull-Request, once the developer has decided that the ticket has been finished, the commits on the feature branch should be squashed into a single one.
  The advantage of this, is that, once merged, a feature branch is represented as a single commit on develop.
  This provides a cleaner history and easier debugging.

With these improvements, the diagram above will look like this:

It can be seen that now, by rebasing and squashing, the history is considerably cleaner.