I recently learned that you can fix you’re previous commit (modify commit message, add more files, etc.) quite easily with git. An example:
You’re in early stages of developing a Rails app and you decide that you want to go back and add some indexes to your tables. No need to create a new migration at this point, just add the indexes to the old migrations and run them again. After making the changes, you create a commit
git commit -a -m "Added missing indexes to tables"
Next you re-run all your migrations to get the indexes in there.
rake db:migrate:reset
At this point, you check git status and remember that now your schema file has changed. This probably should have been included in the last commit! Piece of cake.
git commit db/schema.rb --amend
You’ll be prompted to optionally change the commit message.
At this point git status will tell you that your working directory is clean and the changes to your schema were tracked in the same commit as the migration changes.
Deploying a Rails app used to suck. Reverse proxies, Mongrel clusters, Monit, etc. Capistrano helped out a lot (once you set it up the first time), but all in all the process was still pretty painful.
Thankfully, a couple of technologies have come along and made my deployment process a whole lot easier. Read the rest of this entry »
I use gitosis for private git repository hosting (and it’s awesome). If you are interested, this great tutorial will walk you through setting it up yourself.
I recently needed to rename one of my repositories and couldn’t find any info on how to do it, so here is a walk-thru. I will demonstrate the steps of renaming a repository called “tk” to “show-time“.
Rename project in gitosis.conf and push changes
Before:
[group main]
writable = tk
After:
[group main]
writable = show-time
git push origin master
Connect to gitosis server and rename correct folder
cd /home/git/repositories
mv tk show-time
Change the remote reference in all repository clones
Good security require defense in depth. The more security layers you add, the harder it is to subvert them all. Here is a reactionary layer you can add to your security practices.
The only thing worse than getting hacked is getting hacked and not knowing it (or worse yet, having one of your clients inform you). Often times an attacker needs to add and/or change files on your site to accomplish their goal. Wouldn’t it be nice if something could inform you of unauthorized changes? Enter Git.
I will demonstrate using Git for change notification on a WordPress install using Ruby, but you can apply this principle in many scenarios (hmm, /etc…?). Read the rest of this entry »