---

   gitcore-tutorial    ( 7 )

---

PUBLISHING YOUR WORK

So, we can use somebody else's work from a remote repository, but how can you prepare a repository to let other people pull from it?

You do your real work in your working tree that has your primary repository hanging under it as its .git subdirectory. You could make that repository accessible remotely and ask people to pull from it, but in practice that is not the way things are usually done. A recommended way is to have a public repository, make it reachable by other people, and when the changes you made in your primary working tree are in good shape, update the public repository from it. This is often called pushing.

Note This public repository could further be mirrored, and that is how Git repositories at kernel.org are managed.

Publishing the changes from your local (private) repository to your remote (public) repository requires a write privilege on the remote machine. You need to have an SSH account there to run a single command, git-receive-pack.

First, you need to create an empty repository on the remote machine that will house your public repository. This empty repository will be populated and be kept up to date by pushing into it later. Obviously, this repository creation needs to be done only once.

Note git push uses a pair of commands, git send-pack on your local machine, and git-receive-pack on the remote machine. The communication between the two over the network internally uses an SSH connection.

Your private repository's Git directory is usually .git, but your public repository is often named after the project name, i.e. <project>.git. Let's create such a public repository for project my-git. After logging into the remote machine, create an empty directory:

$ mkdir my-git.git

Then, make that directory into a Git repository by running git init, but this time, since its name is not the usual .git, we do things slightly differently:

$ GIT_DIR=my-git.git git init

Make sure this directory is available for others you want your changes to be pulled via the transport of your choice. Also you need to make sure that you have the git-receive-pack program on the $PATH.

Note Many installations of sshd do not invoke your shell as the login shell when you directly run programs; what this means is that if your login shell is bash, only .bashrc is read and not .bash_profile. As a workaround, make sure .bashrc sets up $PATH so that you can run git-receive-pack program.

Note If you plan to publish this repository to be accessed over http, you should do mv my-git.git/hooks/post-update.sample my-git.git/hooks/post-update at this point. This makes sure that every time you push into this repository, git update-server-info is run.

Your "public repository" is now ready to accept your changes. Come back to the machine you have your private repository. From there, run this command:

$ git push <public-host>:/path/to/my-git.git master

This synchronizes your public repository to match the named branch head (i.e. master in this case) and objects reachable from them in your current repository.

As a real example, this is how I update my public Git repository. Kernel.org mirror network takes care of the propagation to other publicly visible machines:

$ git push master.kernel.org:/pub/scm/git/git.git/