If all of the developers have commit access to the repo, you should not need to do anything special. They will pull changes from the repo, make their own changes, commit locally, and then push back into the public repo when they have something working.
If on the other hand you have one (or a few) developer(s) responsible for committing to the repo, and the others are providing patches to these. Have each of them clone the repo into their own accounts and have them send pull-requests when they have a change they want into the main repo.
It's also possible to make specific clones for working on specific features if you wish. Using the same workflow with pull-requests to get changes into the main repo when the feature is done.
If by "All developers will have one universal account" you mean that all developers will share one GitHub account and appear as the same committer in the repo, that's a bad idea. Make separate accounts and set them up as collaborators if you want them all to have commit access.
As for your specific questions:
No, use branches for features, fixes etc that will take more than one commit. More than one developer can be working on the same branch.
Yes, git handles conflicts really well, so there's no problems having people work on the same file. No problems except, conflict resolution may not always be trivial if there's fundamental changes to a file that has been edited by more than one member. This is however nothing that can not be overcome by talking together. Version control does not replace communication.