Question

What I want to do now is to initialize a private repository on my production server in to app’s www folder (ex: /var/www/app.com/web/) and then clone it as a staging repository to my testing site (ex: /var/www/test.com/web/app.com/) and finaly clone from staging to local to work with the code.

Am I planning it the right way?

I am following these tutorials to learn more about setting the “git server” and initialize private repositories:

• http://progit.org/book/ch4-4.html
• https://moocode.com/posts/6-code-your-own-multi-user-private-git-server-in-5-minutes
• http://www.layeredthoughts.com/git/private-remote-git-repositories-ubuntu-linode

One last question, this tutorial about A Successful Git Branching Model where would apply? On the main private repository (production server), local, or mixed? I haven’t read it completely yet, I’ll do it asap.

EDIT:

• If it matters, I am trying to do so on a server running ISPConfig configuration.
• It’s not a must to work/be as mentioned above, if there is a “healthier” way… glad to learn about it.

This http://www.howtoforge.com/the-perfect-subversion-server-debian-lenny-ispconfig-3 and this http://www.howtoforge.com/installing-subversion-and-configuring-access-through-different-protocols-on-ubuntu-11.10 to GIT version is what I kinda had in mind

Answer 1

Am I planning it the right way?

The cascading repos sounds quite complex, and is not normal.

Consider any checkout a client/satelite/child of the bare git repo you are committing to. Your staging and production installs should be read-only checkouts of specific branches, you are perhaps already familiar (because almost all git questions get a link to it – this question now being no exception) with git-flow which may give some insight into how to setup your branches and therefore checkouts appropriately.

Git Server Setup

This tutorial is probably the only one you need to follow.

Note that if you setup the git user with a home at /home/git and create a repo at /home/git/project.git that means you don’t need absolute paths. I.e.

(server) $ cd /home/git
(server) $ mkdir project.git
(server) $ cd project.git
(server) $ git --bare init

Then wherever you want it:

(home) $ git clone git@server:project.git

of course, you could also put your git repos wherever you want and just change the git user’s home dir (in /etc/passwd) to achieve the same.

Update on push

If you want to update a checkout whenever you push to a repository, you need a post-receive hook to do it. First set your self up correctly:

(server) $ cd /var/www/app.com/web/
(server) $ git clone -b production-branch /home/git/project.git . # it's local - use a file path
(server) $ cd /var/www/test.com/web/app.com/
(server) $ git clone -b staging-branch /home/git/project.git .

Then create /home/git/project.git/hooks/post-update with

cd /var/www/test.com/web/app.com
git --git-dir /var/www/test.com/web/app.com/.git pull #> /dev/null 2>&1 & #uncomment after testing

Ensure that:

• The hook file is executable and owned by git
• Git is (also) in the same group as the owner of the checked out files otherwise you’ll get permission errors when you push

As written above the output of the command will be sent to you every time you push, which will make pushing slow(ish). You can run it in the background when you’re sure it works correctly. It won’t matter that staging checkout is pulling on every push – if there’s no changes to the branch it’s pointing at, it won’t do anything.

It’s probably not a good idea to update your live site automatically. Instead

(home) $ git checkout production-branch
(home) $ git merge staging-branch
(home) $ git push # updating production-branch
(home) $ git checkout feature/i-was-working-on-this
(home) $ ssh server 'cd /var/www/app.com/web/; git pull'
# Manual Post update checks

If you did that automatically and for example the update left your production site in an unusable state – you may not know (until/unless you get a pingdom alert saying “Production site offline”). It would be safe to automate updating your live site if you’ve got significant test coverage and an automated deploy process – but walk before running :).

Direct push

You can if you really want to push into a not-bare checkout if you set

[receive]
    denyCurrentBranch = ignore

In the project’s .git/config file, if there are no local changes that should also update the working copy (iirc).