Initializing private repositories on production server

强颜欢笑 提交于 2019-11-30 10:38:19

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!