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.

extremely useful, thanks!
is there a way to push to such a git server?

this:
git push git://ip.add.ress.here/ master
fails with:
fatal: remote error: access denied or repository not exported: /

Wauw, that was so easy. Thanks!

great post and super easy!

Using an alias is actually crucial, because git aliases are executed in the base directory of your working tree. So the path '.git' will always point to the right place, no matter where you are within the directory tree of your repository.

I don't think this is true. Plain aliases execute from the working directory, only shell commands execute from the root directory (but they do so consistently). I used:

git config --global alias.serve '!git daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/'

(Note single quotes: with double quotes, Bash may expand the pattern "!git [...]" because of the exclamation mark).

Note the trailing slash in git://192.168.1.123/

For HTTP, you can use python3 like this:

python3 -m http.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 ec2-user@172.31.0.1
     • ssh -o 'ProxyCommand ssh -W %h:%p bastion.int' -R 9418:localhost:9418 ec2-user@172.31.0.1
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 ec2-user@172.31.0.1
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