Changing your remote is a one liner. If you can't be bothered to find the command, the config file is self explantory and easy to find. Any clone of the reposi

Changing your remote is a one liner. If you can't be bothered to find the command, the config file is self explantory and easy to find. Any clone of the repository can function as a remote; and every developer has a full clone. If a clone is on a machine with an ssh server, it can be accessed through ssh. Doing so immidietly gives you all access control mechanisms present on said server. For simple setups, this is traditional user accounts with tradutional DAC, possibly with public key authentication uf SSH is so confifured. For more complex situations you can use arbitrary PAM modules. Otherwise any remote filesystem would work once you mount it. These are all concepts that any IT department fielding Linux systems will already need to deal with. As a developer, I have taken advantage of the distributed nature of git without a second thought. No access to the main repository? No problem, there is a clone on our build server, point your remote to that.