Seems easy enough, I read the article multiple times and I don't get why what they are describing is needed.
The difference is that git rebasing is a destructive operation, you lose track of the old version when you do it. (Yes, there's technically the reflog.. but it's much less friendly to browse, and there's no way to share it across a team.)
Maybe that's an okay tradeoff for something you use by yourself, but it gets completely untenable when you're multiple people maintaining it together, because constantly rebasing branches completely breaks Git's collaboration model.
To me that sounds like not a great idea, but if you must do it, I could see some usefulness to this.
I agree that it's not ideal, but... there are always tradeoffs to manage.
[0]: https://github.com/stackabletech/docker-images/tree/e30798ac...
You don't need to push the rebased branch to the same branch on your remote, if that's an issue (although I don't see how it is).
Maybe this is a case of "Dropbox is just rsync", but I feel like just learning git and using it is easier than learning a new tool.
Between monthly syncs we push our own changes to our latest monthly branch (which also get manually sent upstream when we get a chance).
I would agree if this "new tool" we're talking about wasn't just a simple wrapper over existing git commands. You can learn it in its entirety, including how it works (not just how to use it), in a matter of a half hour or less.
Not that hard to keep it organized.
Just tag v1, v2, etc. Then push tags as normal for collaboration. git range-diff is excellent to inspect the changes if you want to see how a patchset changed.