University of Missouri

Interface

Skip to search and archives

Diagram that (very abstractly) illustrates how Git works

Using Git to manage your site on VH

Published on by Paul Gilzow | Posts by This Author

This won’t be a post on how to use Git; for that, see this collection of videos, and this interactive tutorial. Instead, I’ll list out the steps you need to complete in order to have your remote GIT repository on VH, outside the webroot, and have it publish out to your webroot when you commit new changes.

Here in Web Communications, we’ve been playing with Git as a means to manage versions of our sites.  So far, that has been limited to using Git on the local machine, making a remote repository on a shared file space (doit-bfs1), pushing to it occasionally, and then manually transferring the files back over to VH. What we’ve REALLY been wanting to do though is use it to fully manage our sites, allow anyone to work on the site while keeping track of the versions AND publish out to VH, all automatically. We also didnt want to have to store the Git repository in the webroot.

Finally, after some research, and an article from Josh Hughes, we have figured out how to manage our sites on VH using Git.

First, you need a GIT repository initialized on your local machine, with at least one file added, staged and committed (see above tutorials/articles).  Now ssh into VH using your resource account.  You will need to decide which directory you want to store your Git repository in and where you want the repository to publish to.  We prefer to keep our repository in a directory above the webroot in a directory labeled “repo” (or “repos” if it is a hydra site and we are storing multiple repositories). You should ensure that permissions on the repo directory are set to 0700 (e.g. chmod 0700 repo). This is at least in part so that you don’t accidentally try to pull from two different repos on VH and merge them both into your local copy of the repo (trust me: it happens).

If you want to have the respository publish to a sub-directory of your webroot, make sure that directory exists FIRST. Move into the directory where you want to store the Git repository and enter:

git init ––bare

You should receive a message that states Git has created an empty repository. When we initiated the bare repository above, config.bare was automatically set to true, meaning that there is no worktree (place to store the actual source files).  However, we do want there to be actual source files, so we have to manually set bare to false.  Therefore, this next step is important and must be done BEFORE setting the worktree.  Enter in:

git config core.bare false

There will not be a response message after entering this.  Now tell Git where the worktree is stored (make sure this directory already exists as Git will not create it for you).  Enter in:

git config core.worktree /sites/<yoursite>/www/<sub-directory>

Where <yoursite> is the name of your department’s site and <sub-directory> is the name of the directory where you want Git to publish to.  Next enter in:

git config receive.denycurrentbranch ignore

Note: The original article mentioned using GIT_WORK_DIR instead of setting configuration settings in Git.  However, I could not get GIT_WORK_DIR to work correctly on VH.

If you now list the contents of the directory you are in, you will notice that Git has created several directories.

We’ll need to create a new file in the hooks directory, so move into that directory.  We need to create a new file called “post-receive”.  Using your favorite editor, create the file and in it, enter:

#!/bin/sh
git checkout -f

Save the file, and then make sure to change its permissions so that it is executable (chmod +x post-receive).  Back on your local machine, we now need to tell Git that there is a remote copy of this repository on VH that we want to synch with.  Different Git GUI clients will accomplish this in different ways, so I’ll just list the terminal commands.  Bring up your terminal application, change to the directory where you created your local Git repository and enter:

git remote add <alias> ssh://<resource-account>@vh.missouri.edu/sites/<account-name>/path/to/repo

Where <alias> is how you want to refer to this remote repository (we named ours “vh”), <resource-account> is your resource account name, and <account-name> is the your site’s account name on vh (usually matches the resource account name). Now enter:

git push <alias> +master:refs/heads/master

When you hit enter, you will be prompted to log into VH using the resource account’s password.  After that, Git should report that it copied over objects and synched your branches.  From here on out, after you make a change and commit, all you have to do is enter in

git push <alias>

Or in your GUI, issue a push to your remote and select the alias you created.

From now on, whenever you push your changes to the remote repository on VH, the post-receive script we set up above will fire and automatically update the source files on VH in the worktree folder.