13

I've found two common approaches to automatically deploying website updates using a bare remote repo.

The first requires that the repo is cloned into the document root of the webserver and in the post-update hook a git pull is used.

cd /srv/www/siteA/ || exit
unset GIT_DIR
git pull hub master

The second approach adds a 'detached work tree' to the bare repository. The post-receive hook uses git checkout -f to replicate the repository's HEAD into the work directory which is the webservers document root i.e.

GIT_WORK_TREE=/srv/www/siteA/ git checkout -f

The first approach has the advantage that changes made in the websites working directory can be committed and pushed back to the bare repo (however files should not be updated on the live server). The second approach has the advantage that the git directory is not within the document root but this is easily solved using htaccess.

Is one method objectively better than the other in terms of best practice? What other advantages and disadvantages am I missing?

Michelle
  • 2,255
  • 4
  • 25
  • 42

1 Answers1

4

In term of release management (here deployment), it is best to have a target environment which is independent from the release mechanism.
In other words, the second solution (checkout -f) will modify a plain web directory structure, without any other subdirectories which shouldn't be part of it (like a .git folder).
I use it, for instance, in "using git to deploy my node.js app to my production server".

That minimizes any side-effect and allows the production environment to work with just what it needs to run, without interference.

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • It's not clear to me what are the risks/downsides of not having a 'target environment which is independent from the release mechanism.' All I can think of is what you mentioned - the .git folder which can be easily mitigated using the necessary .htaccess rules. What am I missing? Any advice much appreciated. – Michelle Oct 09 '12 at 12:20
  • 2
    @Michelle simply that, in term of release management, you try to enforce a strict control on what is put/deployed/managed on a production platform: it should be only what is needed to *run* the app, not anything else, not an extra tool (git). That said, this is a "best practice in general", not an absolute rule, and in your context, you perfectly can keep the git repo directly on your prod platform. – VonC Oct 09 '12 at 13:32
  • @VonC what about for a website that for example its images/pdfs are added/changed via admin panel, the hook checkout will overwrite them when next run, also for a large (~10GB files) website, could it be a problem checking out the whole site every time a (even small) push is made. – Hayden Thring Nov 07 '19 at 20:56
  • @HaydenThring Seven years later, that would be [`git restore`](https://git-scm.com/docs/git-restore), not the [confusing `git checkout`](https://stackoverflow.com/a/57066202/6309). And it would only restore what has changed in HEAD, not *all* files. – VonC Nov 07 '19 at 22:03
  • That sounds interesting, I will check that out. Thanks. – Hayden Thring Nov 07 '19 at 22:50
  • @VonC , I just looked up its documentation and I'm unclear, would I use restore instead of checkout ?, and I guess your saying if so, it would leave existing files that are unchanged ? – Hayden Thring Nov 07 '19 at 23:00
  • 1
    @HaydenThring Yes, and yes. – VonC Nov 08 '19 at 08:28