This notion works as long as you have a centralized team working on a single code base and they can coordinate through other means. Once you have different peop

This notion works as long as you have a centralized team working on a single code base and they can coordinate through other means. Once you have different people - and potentially even different access levels - working together, you need to be mindful about version-management, be it svn or git. I have exactly this situation at hand at the moment. We are contributing as much as possible to an open source project. However as buisness goes, we need certain extensions to this project which clearly fall under our NDA, so I can't contribute them back. That's precisely where version-management becomes important, and where real benefits of git kick in. In this case, I can do a bit of trickery by chaining repositories: I have a public repository for our contributions, which can open pull request to up-stream. Behind that, I have an internal repository, which has two read-only remote repositories (upstream, and our public contribution repository to fast-track certain changes). From there, you can do the changes in the right repository and need to obtain the changes through the right remote repositories.