Migrating a production site with no VCS at all to Git
Asked Answered
P

1

4

I thought I would throw this out there and see if I could get some solid advice on this.

I've got a production site with a rather large code base and have just installed Git on it, same with test site. And I've got a local box that will basically be the point of integration. Our team will push to the local box and little gnomes will come and take everything off to our different servers - or at least that's the closest I've come to implementing Git.

I really don't have the slightest clue where to begin. I've got a big, finicky, legacy codebase that I am scared to touch on a good day. Git is meant to be the starting point of a big cleanup process, I just don't know how to get started.

I was thinking of creating a bare .git repo based on my production docroot (with applicable .gitignore stuff) and then cloning over to test and development environments, then individuals would clone off dev and get to work, pushing back to dev and then somehow magically telling git to update the docroot when changes to the bare repo are made.

I was going to install git-flow on development (can't get it to work on my production server), and then push to production. Since they are just branches at the end of the day, figured I could get away with not using git-flow on prod/test servers.

This seems all well and good, I just don't know if I should be pushing to test/prod, or pulling from dev to test/prod. Maybe just a straight git init in production docroot? Create a .git directory and git init to that? Git init git giggidy giggigdy...

Insights are appreciated.

Edit

Here's what I ended up doing, hopefully someone else will find it useful.

Downloaded current production code to development server (LAMP) Set up .gitignore files and ran git init within the directory and peformed initial import/commit
On Staging/Production servers:
Created YOURNAME.git directories and created bare repositories with git init --bare
Set worktree as /path/to/my/public_html, set bare to false, and set receive.denycurrentbranch to ignore
Added a line to hooks/post-receive: git checkout -f making sure that my git user had permission to write to the worktrees

Back on the development server:
git remote add [staging|production] ssh://myuser@myserver/path/to/my.git
git push [staging|production] master

To update my production and staging sites, its a simple git push [production|staging] and I don't have to fuss with hiding a .git directory from public view.

Sources: http://www.deanoj.co.uk/programming/git/using-git-and-a-post-receive-hook-script-for-auto-deployment/
http://toroid.org/ams/git-website-howto

Hope this helps someone!

Edit again
Also, works best on 1.7.3.3 or later. I'm running a virtualized ubuntu box for development and ran into some issues committing over Samba. After fighting with this for a couple of hours, read that the issue was fixed in 1.7.3.3. I was on 1.7.3.1.

Parrisch answered 29/4, 2011 at 18:40 Comment(0)
H
1

If you're not interested in getting into the heavier deployment solutions like Capistrano then you can set up a post-receive hook on your bare repository that checks out the latest changes into your production docroot. You could set up a separate hook for both dev and for production. Here is a pretty good guide to doing this.

Hovis answered 29/4, 2011 at 18:52 Comment(3)
Capistrano is Ruby-only, no? Apologies, should have specified that this is a PHP project. Starting to look through the guide now. Cheers!Parrisch
Really helpful guide, can't believe I hadn't stumbled across it already. The example in the guide (for the sake of argument) starts with a local code repository. This is no big deal, I can just curl up the site now and pop it on the dev box. I guess the only question I have is this: When I push to the website.git directory and the post-receive hook kicks in, will it simply overwrite the files that are in the docroot with the checked out changes?Parrisch
Yea, I think that's what the git checkout -f command is responsible for. Will force overwrite of everything no matter what.Hovis

© 2022 - 2024 — McMap. All rights reserved.