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
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).
It's good idea, but requires a bit more work.
Git will not update working copy when you push to a non-bare repo unless you help it by defining a post-update hook to do git reset --hard when the checked-out branch is pushed to, plus disabling the default check against pushing to checked out branch (I don't remember the exact option, look in git-config man page).
Note, that doing git reset --hard will undo any local modification. Writing the hook so it preserves local modification is a little more tricky, but can also be done. However, you shouldn't have local modification on the production server, right?
With appropriate hook in place, it's quite sensible workflow for small setup, when you don't have many servers.
For larger setup I'd have a bare repository on separate server and the hook would cause a git pull to run on the production repo using an ssh trigger. Advantage is that you would have the central repo on server not accessible from outside and thus could better secure it.
来源：https://stackoverflow.com/questions/9431741/initializing-private-repositories-on-production-server