Git doesn't have a central shared repository as subversion does, each developer maintains their own fork of the code, and then code is shared between the forks. You most definitely should not be sharing a user name/password combination.
It is probably best to have a repository that is used for releases, but nobody commits directly to that repository, each developer instead issues what github calls pull requests to that repository, and then a select group can review and accept/reject those pull requests.
There are multiple possible work flows that you can have, one such is the work flow used by the PHP project that migrated from subversion to git a while back. You can find details online, but basically they use
https://github.com/php/php-src as their release repository, at the time of writing there are 4661 forks, each of which will issue pull requests to this repository, but they can of course pull code between them.
I was sceptical of Git at first but the more I used it the more I realised it's power which is why most projects have migrated to it.
Paul: Most of the patches apply without a problem, but I am going through each one individually to make sure there are no problems as we don't want to mess this up. Commit 7944 (
https://sourceforge.net/p/web-erp/code/7944) is the hardest so far as you can see it is very large, and there are several corrupt files in it. On some of the commits with corrupt files I have manually created the diff, but on others such as 7944 it is just too hard, so it is probably best to complete this exercise, then run a diff between this repository and your expected one, analyse the differences, and then do any remaining commits.
Sourceforge subversion problem
