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