The easiest way to split function branches is to simply push them into the central repository so that everyone can pull them out. That way, you can simply use the infrastructure that you already have for the main repository, and you can easily exchange code.
Once the function branch on the remote control is no longer needed, you can simply delete it by doing
git push <server> :branch
I would advise against sharing directly between the development machines, as this is due to problems, such as users on different networks (not connected to each other).
If possible, you can also use the GitHub model, which has one central repository on the server (blessed main repo). In addition to this main repository, each developer has a “fork” of this repository, where he has full access to the commit and can push branches to his liking.
In this case, you can add colleagues' forks as remotes to your repository, while maintaining easy access to one centralized server (while maintaining problems with setting SSH keys on each machine, etc.).
A description of the GitHub model can be found here: http://www.eqqon.com/index.php/Collaborative_Github_Workflow
Update . As the commentator noted, this is a good link to get started with a workflow with centralized functionality: http://nvie.com/posts/a-successful-git-branching-model/
Update 2 . To expand your second question:
What you are trying to do is click on the non-bare repository of another developer. Git, introduced in some previous version (I think about 1.6), the concept of a bare repository is a repository that does not have a registered state, but contains only a database, which usually goes into .git .
The rationale for this change was that whenever you click on the repository of your fellow colleagues (who is currently working on something), you manipulate the repository right under his nose. Therefore, it checks the version of featureA-1 .. starts to work. Then you click featureA-2 on your repo, and when he wants to commit, he runs into problems because the branch he was in is being promoted by one message that he did not see during development.
Because it is quite destructive. Most people have adopted the concept of local git repositories (the ones you are active in) should be private, while you have the publicly available git-repo (fork) where you receive and share changes. This way you will never be interrupted by anyone else during your work (which is generally the idea of a decentralized model) and can only include the changes you want to have. (No one can direct something to your current job).