Using Git to display your web app’s version

I’m mainly writing this down for my own benefit, but others might find this useful. In a previous post about setting up git to deploy to a remote web server, I wrote about a way to display the lastest abbreviated commit hash in your web app’s footer.

Today, I discovered that simply running:

git describe

will output the most recent tag and the current abbreviated commit hash (if there are commits after the tag), so you can use tags to show more human-readable versions of your app (v1.0, etc.) along with the current commit. Unfortunately, you apparently can’t run ‘git describe’ on a bare git repository like what I’m using for deployment on the remote server.

Continue reading

Git deployment & WordPress

As I rely more and more for Git to deploy changes to web apps (see here and here), the thought of going back to FTP induces shutters (OK, that’s an overstatement). Now I’m working on a WordPress site with a purchased theme that requires some customization. I don’t see any reason to store the core WordPress files in a repository, or the plugins folder for that matter (unless I’m writing my own, and I’m not), so I only want to version control and deploy the theme I’m making customizations to.

Gitignore to the rescue.

I found this great .gitnore file on Github that is working perfectly:

Hostgator and Git

I previously posted about using git to deploy to Ubuntu. However, that’s only relevant to me for my  “day job” where I can have some control over my server environment. For other work, I currently host a number of sites on Hostgator. I’ve fallen in love with the simplicity and power of deploying sites using Git (after the initial setup), so using Git in a shared hosting environment would be a huge win.

Luckily, I found a few resources out there on how to set this up, but in the end, the only real difference between my workflow for Ubuntu and hostgators turns out to be saving the Hosgator SSH port (2222) in a ~/.ssh/config file as described here.


  1. You must have SSH access on the domain you are working with. I believe it comes with your primary domain, and you have to pay $2(?) a month for SSH access per domain beyond that.
  2. It’s easier if you use the SSH public keys as described here.
  3. You can just create your bare Git repositories under /home/[username]/git if you want to set it up as I described in my previous post.

Random thoughts about Web Development across multiple dev machines

I just picked up a refurbished 2012 Macbook Air from the Apple online store to replace a 2007 Macbook Pro. I didn’t use the MBP much because it just couldn’t keep up, but I missed being able to work anywhere, including at home without having to sneak upstairs to the office.

Now that I have the MBA, those limitations are gone, but  working on the same project on different computers can still be a challenge. However, compared to just a few years ago, creating the same web development environment across several computers can be accomplished with just a little effort.

Continue reading

A few little concerns about Laravel 4

I jumped into Laravel as my PHP Framework of choice about a month ago after deciding to switch full time to PHP from Coldfusion. Though I’ve only used it for a month, I really believe Laravel 3 is an awesome framework. However, now that the beta 1 of Laravel 4 has come out, and I’ve been looking into what it would take to port my first Laravel 3 app to 4, I do have a few concerns and I’m not the only one.

I’m not so concerned about the controller/action naming conventions or the use of Composer in general, but the practical day-to-day stuff that will affect me as I’m developing.

One of the first things I noticed in my attempt to port over my app was the absence of the HTML, FORM, and URI (I think) helper functions. This was explained to be a result of using replacement packages available via Composer. That’s fine, but here’s my biggest concern regarding a heavy reliance on Composer (and this is not restricted to Laravel at all):

As a newbie I rely HEAVILY on documentation. The more you strip out of the framework and farm out to Composer, the more places I have to go to find documentation. This can be a pain.

Now I’m seeing there’s a movement afoot to buy a license for Redactor.js so it can be included in Laravel 4. That sounds great to me, but why would Laravel’s developers want to include a wysiwyg editor as part of the core, when they’re stripping out stuff like HTML and FORM helpers?
I can see not including a Twitter library like Zend, buy why remove something that was already there and relied upon by many developers?
I’m just ranting here, and I’m very hopeful that as things stabilize and the smoke clears, L4 will be awesome and even better than L3 has been for me so far.

But I’m still just a little concerned.