Sure, and this is one of the nice things about git, that it supports a number of flexible workflows.
My repos are in fact trunk and branch shaped: the trunk branch is always the first commit, and I tend to just have feature branches. That won't last forever, I'll need to start having release branches and the like, but 'trunk as root' with the first commit is going to be a constant.
So 'develop' is a fine choice. I worked at a company which had a 'master' branch but really only used it for releases. It wasn't a continuous deployment model, so everything would land on 'develop', turn into a candidate branch near release time, and then land once on master when it was blessed for release.
So master was just a series of squashed deltas between point releases, which kind of matches the semantics of 'master' if you squint: like it was the gold master from which release copies (including one client who took delivery by CD-R!) was pressed.
My repos are in fact trunk and branch shaped: the trunk branch is always the first commit, and I tend to just have feature branches. That won't last forever, I'll need to start having release branches and the like, but 'trunk as root' with the first commit is going to be a constant.
So 'develop' is a fine choice. I worked at a company which had a 'master' branch but really only used it for releases. It wasn't a continuous deployment model, so everything would land on 'develop', turn into a candidate branch near release time, and then land once on master when it was blessed for release.
So master was just a series of squashed deltas between point releases, which kind of matches the semantics of 'master' if you squint: like it was the gold master from which release copies (including one client who took delivery by CD-R!) was pressed.