You have a push-only workflow, and 100% of commits are made on your local? Frankly, I’m not sure what you’re even using Gitlab for in this setup; it seems like you might as well just rsync your working directory to your remote server instead, since you don’t have to approve, merge, or reconcile commits from other sources. There’s nothing distributed about your version control needs.
No-- I'll fetch branches from other devs, inspect them, merge them locally, then push to remote. But that all happens on my local machine.
I use the Gitlab UI for issues, creating merge requests and discussing them with other devs, etc. That centralized Gitlab instance provides a lot of value for me. If there were a method of leveraging something close to the Gitlab UX with a decentralized or even federated design underneath, I'd use that. But this article reads like it's saying, "Give up that value and use this less convenient flow in order to protect against an unlikely class of attack."
