That is not a bad model and you&#x27;ll prevent merge commits. However in GitLab flow I advocate against rebasing of commits you pushed: &quot;However you should never rebase commits you have pushed to a remote server. Somebody can have referred to the commits or cherry-picked them. When you rebase you change the identifier (SHA1) of the commit and this is confusing. If you do that the same change will be known under multiple identifiers and this can cause much confusion. If people already reviewed your code it will be hard for them to review only the improvements you made since then if you have rebased everything into one commit.&quot; I think that &quot;Your codebase should be clean but your history should represent what actually happened.&quot;. But if you want to use your model GitLab does support it, GitLab EE and .com allow you to rebase and merge from the web interface <a href="http:&#x2F;&#x2F;doc.gitlab.com&#x2F;ee&#x2F;workflow&#x2F;rebase_before_merge.html" rel="nofollow">http:&#x2F;&#x2F;doc.gitlab.com&#x2F;ee&#x2F;workflow&#x2F;rebase_before_merge.html</a>