Git - creating a pretty log using rebase

Question

We have started using Git on our continues delivery (CD) project. Our DevOps decided that we must have a clean Git log, where every bubble correlates to a technical/user story. In the log, a commit on the master must be a merge commit from a feature branch. The log must not have more than one level (i.e. it should look as if each branch does not overlap with another branch).
For example:

So far we achieved this goal by creating a local branch, commit to this branch and rebasing with master before merging the branch to master with no-ff.

However, I am not certain that this approach is optimal. It works well most of the time, but when more than a single developer work on the same branch, they can't rebase with master. Therefore, if they need to sync the branch code with some changes pushed to master, they can't (or at least it's much more complicated)

Being accustomed to previous source control systems, I feel that as rebase loses information about the order in which commits really happened, it much harder to understand what's going on.

What is the best practice for working in a team with the constraint above (the log must look as close to the above image as possible)?

What is the big advantage that such log structure gives to whoever in charge of the release in continues delivery system?

Answer 1

GitLab and others offer a setting called Semi-linear history which will only allow you to merge a merge request if it is a direct descendent of the target branch.

This means you will need to rebase one last time before being able to merge a finished MR/PR. Of course, this will not prevent merging a branch which itself has merge requests in it.

I'd still challenge your DevOps teams workflow. Why can't they use git log with --no-merges, --first-parent, --date-order/--topo-order or similar to get the commit view they require?