Talking about things being "standard" in development methodologies is dangerous because there is almost no such thing. Groups of developers tend to organise themselves in ways that work for them (or in the way that management tell them to organise themselves).
All of the approaches you have identified are valid ways of using distributed version control systems. I would suggest that you're not seeing massive benefit from the alternatives because you're working on a university-sized green field project with a small team of people in the same geographical location, speaking the same language, with similar abilities, and with similarly clear ideas of what the outcome should be. Git tends to shine when any of those are not the case.
For distributed projects where you really want one person to be acting as gate keeper to the canonical version of the project, pull requests work really nicely. When you want everyone to have effectively equal commit access, a development branch is a good solution. People tend to use development branches so that they can have an always-working version hanging around for people to use. I assume you don't currently have users, which is why you are unlikely to see much benefit from this approach.
I would basically continue as you are unless you talk to each other and decide that something is not working for you as a team, in which case you can decide if one of the other ways of working are going to be better for you.