Here’s a little script I made to make it easy to put a number of existing web sites residing under /var/www under version control by Git. Regarding security, it is obviously not a good idea to initialize the Git repository directly under the site directory, since from there it might be served by the web server to the outside world. And that is not what I want. Instead what I want is to have the Git working directory directly in the site directory that is served, and the repository somewhere else. That is perfectly possible with Git, just by setting one or two environment variables.
What this script does is actually create an interactive subshell for working with the separated working directory and repository. The environment is initialized automatically, the umask is set correctly, and the prompt is changed to remind the user she is working inside this particular site’s environment. You can deploy it many times for multiple sites, customize it for each site, and keep all the repositories under one root directory, each in their own subdirectory. You don’t have to remember any of this, just the name of the site or script. You are ready to work with the site once you simply run the script. Pull from a remote, make changes, commit, push, whatever you want. When you are finished, just type ‘exit’ to get out of the site’s environment. You can then run another script to work on another site.
So for example, if you have two sites, called first.example.org and second.example.org, save two copies of the script on your server under /usr/local/bin or $HOME/bin. The name of the first copy could be first.example.org and the name of the second copy could be second.example.org. Edit both files and set the WORKROOT variable to where your sites are situated (eg. /var/www) and REPOROOT to where you want your repositories to go. These paths can be the same in both files. What must be different is the WORKNAME variable, which should be the name of the directory under which the particular site is. The variables should look something like this:
/usr/local/bin/first.example.org:
|
1 2 3 |
WORKNAME="first.example.org" WORKROOT="/var/www" REPOROOT="/var/git/www/repos" |
/usr/local/bin/second.example.org:
|
1 2 3 |
WORKNAME="second.example.org" WORKROOT="/var/www" REPOROOT="/var/git/www/repos" |
This configuration means your site roots are:
- /var/www/first.example.org
- /var/www/second.example.org
Those will be used as the Git working directories. The corresponding repositories will be:
- /var/git/www/repos/first.example.org
- /var/git/www/repos/second.example.org.
But you don’t really have to remember that because all you need to do is run either of the scripts and just use git as you are used to. When you’re done, type ‘exit’ or hit Ctrl+D and you can run another script to get to another site’s environment.
Give yourself permission to execute the script files under /usr/local/bin.
Here’s what an example first run looks like. First create the repository root directory and set suitable permissions (assuming you belong to the admin group):
|
1 2 3 |
$ sudo mkdir /var/git $ sudo chgrp admin /var/git $ sudo chmod g+w /var/git |
Then run the first script:
|
1 2 3 4 5 6 |
$ first.example.org Entering shell with environment for first.example.org Git repository is: /var/git/www/repos/first.example.org fatal: Not a git repository: '/var/git/www/repos/first.example.org' Initialize repository with 'git init' and commit Type 'exit' to get out of the environment |
As you can see, there is no Git repository yet. That has to be initialized and a first commit made.
|
1 2 3 4 5 6 7 8 |
$ git init Initialized empty Git repository in /var/git/www/repos/first.example.org/ $ git add . $ git commit -m 'First commit' [master (root-commit) 03de73b] First commit 1 file changed, 3 insertions(+) create mode 100644 index.html $ exit |
As you can see, this is just typical Git usage. You can configure remotes, push and pull, make changes and commit them.
The second time you enter the site’s environment by running the script, the welcome message will look a bit different.
|
1 2 3 4 5 6 7 |
$ first.example.org Entering shell with environment for first.example.org Git repository is: /var/git/www/repos/first.example.org On branch master nothing to commit, working directory clean * master 03de73b First commit Type 'exit' to get out of the environment |
After running the second.example.org script you can go and initialize the repository for the second site as well. It is just the same as the first one.
Below is the script. Just save it, and customize the WORKROOT and REPOROOT variables how you like them. Then make as many copies of the script as you have sites, and customize the WORKNAME variable to match each site. Add execute permissions.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 |
#!/bin/bash # # This script starts a new interactive shell with GIT_DIR and GIT_WORK_TREE # set to different locations. You can use git normally, but the .git/ # directory contents will be kept in a different location and not under the # working directory. # # You can customize the three variables below to reflect the locations of # the the repository and the working tree: WORKNAME="first.example.org" WORKROOT="/var/www" REPOROOT="/var/git/www/repos" # The $WORKNAME is the name of the working directory. It will also be used # as the name of the directory for the bare repository. # # The $WORKROOT is the root directory under which the working directory is # situated (meaning the checked out files). # # The $REPOROOT is the root directory under which the bare repository is # situated (meaning all the stuff usually under .git/) # If set, the umask will be set to this. We want to give full privileges # to the group. SETUMASK="0002" # Put the commands you want to execute inside the new shell before going # into interactive mode between the two EOF:s below. They will be read # into the variable $RCFILE and will be executed after the shell has been # started. read -r -d '' RCFILE <<'EOF' # First read the regular bashrc file source $HOME/.bashrc; # Then change the prompt to reflect the fact we are in a new environment export PS1="\n\t ($WORKNAME) \u@\h:\n\w\a\\$ "; # Display status of current repository git status && git branch -av || echo "Initialize repository with 'git init' and commit" echo "Type 'exit' to get out of the environment" EOF # This is used in the $RCFILE export WORKNAME # === Probably no need to touch stuff below this point === echo "Entering shell with environment for $WORKNAME" export GIT_DIR="$REPOROOT/$WORKNAME" export GIT_WORK_TREE="$WORKROOT/$WORKNAME" echo "Git repository is: $GIT_DIR" # Set umask if variable is set test -z "$SETUMASK" || umask "$SETUMASK" # Create directories if they do not exist already test -e "$GIT_DIR" || mkdir -p "$GIT_DIR" test -e "$GIT_WORK_TREE" || mkdir -p "$GIT_WORK_TREE" cd "$GIT_WORK_TREE" # Start a new interactive shell and keep it running until "exit" if [ -z "$RCFILE" ]; then exec bash -i else exec bash --rcfile <(echo "$RCFILE") -i fi |
It is quite straightforward. First the configuration variables are defined, as well as the RCFILE variable which is read from a here document. Next the important Git variables GIT_DIR and GIT_WORK_TREE are exported. After possibly creating directories, another bash is executed in interactived mode, and the RCFILE variable is fed to it as the rc file to be executed at the start of the shell. So in reality the user will be working in a sub-subshell until she exits.
If you have trouble cloning a remote to a repository initialized by this script, after starting the shell first time, run:
git init
git remote add origin [url-used-to-clone]
git pull origin master
If you can’t get the master branch, use “
git remote show origin” or “git ls-remote” to see which branches are available.