How to easily launch a temporary one-off git server from any local repository, to enable a peer-to-peer git workflow.

git-serve.md

This article is now published on my website: A one-off git repo server.

This is awesome for local development and test servers

Note: The default git port is 9418.

Consider

1. Once you have a git daemon running, you can git clone git://localhost/ ~/src/new_copy just like you would git clone ~/src/original_copy ~/src/new_copy.
   • (You do know you can clone from directory to directory in order to try out new ideas you get while your working tree is a WIP. Don't you?)
2. If someone on the same network can reach your IP they can git clone git://192.168.1.123/ local-repo-name as Datagrok said.
   • I stress If because that's not so at Starbucks, etc.

What about a remote server that you have to SSH to? (maybe even using VPN or a bastion, etc.)

3. When you ssh to that server, you add -R 9418:localhost:9418 to the command.
   • Examples:
     • ssh -R 9418:localhost:9418 [email protected]
     • ssh -o 'ProxyCommand ssh -W %h:%p bastion.int' -R 9418:localhost:9418 [email protected]
4. Now you can clone via git clone git://localhost/ local-repo-name on the server, and it is talking to your local workstation via a Reverse Tunnel.
   • Remember -R as <Remote port>:<target_host>:<target_port>

Tunnels are amazing! Anything must be possible!

Surely your partner at Starbucks (from #2 above) ought to be able to clone from you if that was possible.

5. Have you partner ssh to that server and add -L 9418:localhost:9418 to the command.
   • Examples:
     • ssh -L 9418:localhost:9418 [email protected]
6. Now she can (in another local terminal) clone via git clone git://localhost/ local-repo-name on her workstation, and it is talking to your workstation via a Forward Tunnel… that's pointed at the Reverse Tunnel from #4
   • Remember -L as <Local port>:<target_host>:<target_port>
   • Don't get overwhelmed with trying to remember what side of the tunnel the <target_host> and <target_port> are on.
     • The target is always on the opposite side of the tunnel as the port that is "listening".
     • (Otherwise you'd just connect to the target without a tunnel. Right?)
     • The side of the tunnel that is listening is indicated by the letter you use. Either -R or -L.

Read those checkbox bullets over and over again out loud until it sticks. When you are able to conjure SSH Tunnels without Googling or searching man pages, you will never look at "connection issues" the same way again.

Nice. However you still have to expose your port.

I rather use git bundle as described here: https://git-scm.com/blog/2010/03/10/bundles.html

It also solves the issue when you do not want to be online at the same time.

For anyone wondering why simply running a http server in the repo directory is a bad idea: you have to ensure the repo is "packed" at all times by periodically running git repack, otherwise the clients will get some random old state of the repo

A new built-in command git-serve was added in Git 2.18, so the alias "serve" no longer works. Changing the alias to "server" is a simple workaround.

404 Not Found
nginx/1.18.0