Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
How to easily launch a temporary one-off git server from any local repository, to enable a peer-to-peer git workflow.
@twome

This comment has been minimized.

Copy link

commented Aug 16, 2013

This is incredibly cool - thanks so much!

@deiga

This comment has been minimized.

Copy link

commented Oct 23, 2013

Can this also be modifed to serve a directory of multiple git repos?

@dwschulze

This comment has been minimized.

Copy link

commented Feb 1, 2016

If you get:

Expansion of alias 'serve' failed; 'daemon' is not a git command

You need to install git-daemon:

http://droidyue.com/blog/2013/09/10/install-git-daemon-on-fedora/

(for Fedora).

@pauloyster

This comment has been minimized.

Copy link

commented Feb 11, 2016

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: /

@dumazy

This comment has been minimized.

Copy link

commented Feb 18, 2016

Wauw, that was so easy. Thanks!

@BigRedT

This comment has been minimized.

Copy link

commented Jul 24, 2016

great post and super easy!

@commonquail

This comment has been minimized.

Copy link

commented Dec 7, 2016

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).

@mb21

This comment has been minimized.

Copy link

commented Feb 1, 2017

Note the trailing slash in git://192.168.1.123/

@elacheche

This comment has been minimized.

Copy link

commented Sep 11, 2017

For HTTP, you can use python3 like this:

python3 -m http.server

@RichardBronosky

This comment has been minimized.

Copy link

commented Oct 4, 2017

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.)

  1. 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
  2. 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.

  1. 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
  2. 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.

@radeksvarz

This comment has been minimized.

Copy link

commented Oct 10, 2017

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.

@olejorgenb

This comment has been minimized.

Copy link

commented Jul 6, 2018

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

@jennings

This comment has been minimized.

Copy link

commented Nov 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.