When you start using Git, you might be tempted to push all your code directly to the master branch. This might not be very good for multiple reasons, one of them being that you can't experiment with new features very well as you pushed everything to master. You can't simply delete the branch and start over.

The branching workflow tries to solve this by making sure that the master branch is always the latest stable code, and it has to be deployable at all time. So, only code that has been tested and proven to work can go in there.

Let me explain this a bit further.

When you start working on a new feature, you create a new branch, which is named after the feature you're working on. This branch is separate from the master branch as that is the latest stable version of the code. You directly push this new branch to GitLab and create a merge request for it. This way, your team knows what you're working on, and it allows them to comment on the thing you're working on from the word go, preventing you from working on something that might now be important or maybe something someone else is working on.

You create new code and, maybe, delete some old code till you're happy with the feature you're working on. To test this code, you deploy this branch to a staging server for you and the team to test out. In the meantime, a team member can review your code in the merge request you created.

Once this code is tested on the staging server and has been reviewed by another team member, it can be merged to master and deployed to production.

However, it is also possible that the solution you're trying out doesn't turn out to be the best. When other team members were trying it out, they find that it was not easy to use or a lot of corner cases were found. After discussing with the team, you decided that this feature is not working and you want to delete it. At this point, it's just as simple as closing the merge request without merging and deleting the branch. No need to revert any code. Just delete it and you're done.