Managing a Git Staging Server and Live Server

Question

I've been using Git/Beanstalk while developing a new site and it has worked wonders for pushing changes from Local server to the Staging Server. I'm now at the point where I want to go "live" with a Production Server and was wondering what the normal procedure is (many of the other links don't cover this...).

I would like to start over "fresh" with this new Production Server instead of pushing the thousands of changes I've made over the past 6 months from the Staging server. Is there a way to do this? Do I simply create a new repo, get rid of the old one, etc.? How can I clear the history so that it simply takes what is on the staging server now and pushes that (or do I push from the local server). I use Tower so I know just enough about Git to almost not get in trouble (command line isn't my thing). Can you wrap everything up and say "This is Version 1.0, let's start from here" sort of thing?

Also, I was kind of lazy when it came to ignoring the cache files and images, etc. Can I easily add those .gitignore files after the fact?

Answer 1

As Adrian says this isn't really an issue unless you've got large numbers of binary files in Git that shouldn't be (eg image uploads etc). Personally I wouldn't nuke my history as it's invaluable for debugging, though I'm pretty disciplined about what I commit and how often.

If you want to remove files from your repo that you have previously added, but want to keep a local copy do:

git rm --cached /path/to/remove

This will remove them from the current state of the index and but keep the actual file, which you can then add to your .gitignore. This is handy for files you just added to git by mistake, or for small files that aren't a concern for repo size or security.

However if you've previously committed the files, they will still be in your history, so your total repo size may be inflated (for example if you added a PSD or some large images in the past. If you want to completely remove a file from your history (also handy if sensitive data crept in somehow) you can do:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch <NAME OF FILE>' --prune-empty --tag-name-filter cat -- --all

This command will run the entire history of every branch and tag, changing any commit that involved the file you specify, and any commits afterwards. Commits that are empty afterwards (because they only changed the Rakefile) are removed entirely. Warning: It will overwrite your existing tags as well.

Once you've removed the file you may need to force pushing your changes with a:

git push <remote> <branch> --force

But you want to be pretty sure you're doing the right thing at that point though, as you will overwrite the history on the remote as well, and at that point it really will be gone. There is an excellent, more detailed tutorial here if you go down this route.

As you're using Beanstalk though, this isn't a major issue, as it will only deploy the latest version of your files not your entire repo/history.

Answer 2

Please note that Beanstalk will only deploy the latest version of your files (or if you want any other revision). So when you add your production server Beanstalk will upload all files which are currently in your repository to your production server.

It will not deploy it change by change, so any 'history' will not slow it down or use any space.

Answer 3

Unless your git repository is really large (because you added a bunch of media files to it accidentally or something), there is pretty much no point doing this. The whole point of version control is to keep a history of changes, so you can look back and see when and why something was added. The reason why no tutorials cover this is because it's simply not how you would normally use git.

The only reason I could see you wanting to do this is if you added a whole bunch of files which don't belong in git (large media files, caches etc), which have since been deleted and are taking a long time to push to your production server (since you mentioned you forgot to start with a .gitignore file). All text files are compressed in git, so there is no need to worry about how many commits you have made (for comparison, the PHP source code has over 70,000 commits, dating back 14 years, the linux kernel has over 300,000 commits, and many other successful open source projects are like this too - so even if you have made 1000 commits, you are barely scratching the surface of what git can handle).

In that case, what you are talking about doing is wiping your entire history and just creating a new blank git repository. All you need to do is delete the /.git directory, and initialize a new one (from Tower, or the command line with git init).

Note if you create a fresh repository, then try to push to your staging server, you will need to use the --force option, otherwise it will complain that you are trying to rewrite history (which you are). Tower has a similar force checkbox when you click Push.

You can certainly add .gitignore files after the fact. However, keep in mind that this doesn't remove any files which you previously added to the repository. So it's always better to avoid committing files in the first place, otherwise they end up permanently in your repository history (there are ways to rewrite history and properly remove all traces of files even from old commits, but they are difficult and beyond the scope of this answer).