Tag Archives: Git

How to update and deploy WordPress as a Git submodule

WordPress 3.8.2, a security release, came out yesterday. Now, if you’re already on WordPress 3.8, your WordPress installation will most likely automatically update, but if you are using Git to manage WordPress as a submodule, and have auto-update disabled, you have to do that manually.

That said, it’s still super easy to do. It definitely outweighs not having a version control system.

Let’s look at the Git commands required to update WordPress from 3.8.1 to 3.8.2. Note that this will work for updating any version.

Continue reading

Git error when switching branch after replacing directory with submodule

I’m working on updating several WordPress sites. Part of each site’s update includes converting the WordPress core and all frequently used plugins to Git submodules. While many recommend staying away from submodules all together, I’ve been using them for a while now and never had any issues, that is, until today. Luckily, it’s nothing severe, and in my case, pretty straight forward to fix (once you know the solution), but because the error didn’t make any sense, I’ve decided to document it here.

The main problem is that I’m unable to checkout the master branch after adding the submodules on the develop branch. Git complains with the following error:

error: The following untracked working tree files would be overwritten by checkout

That said, let’s look at the problem in detail and how we can solve it.

Continue reading

Git post-receive hook to deploy WordPress and plugins as submodules

In a previous blog post I discussed how best to manage file and folder permissions when deploying with Git, but today I’ll show a specific example of what that post-receive hook might look like for a WordPress project that uses submodules.

I have three servers that I can deploy to, but the post-receive hook only deploys a project when it encounters the specified branch as defined per server:

  1. QA waits for a release branch
  2. Staging waits for the master branch
  3. Production waits for the master branch

Other than this small difference, the post-receive hook is identical on all three servers to reduce maintenance.

Lastly, each server has two repositories per project:

  1. Bare repository – storage unit that uses a post-receive hook to deploy the project.
  2. Working repository – web root that will serve the project to the end-user.

This method has several benefits:

  1. View a combined list of all version-controlled projects via the /opt/repositories directory.
  2. Recover a corrupted web root by cloning a fresh copy from the origin.
  3. Prevent some issues that may occur during the deployment, since it will fail before post-receive hook is fired.

Continue reading

Bash shell prompt dissected: Display Git branch name and status in color

I received a snippet of code from my good friend Jason today. It goes into your .bash_profile and what it does is add two pieces of information to your Bash shell prompt when you’re in a Git working directory. With it, you’ll be able to tell:

  1. Which branch you’re currently on and
  2. Whether the branch has untracked changes.

The code, now compacted, looks like this:

1
2
3
export PS1='\u@\h:\[\033[1;34m\]\w\[\033[0;33m\]$(git branch 2> /dev/null | sed 
-e '/^[^*]/d' -e "s/* \(.*\)/[\1$([[ $(git status 2> /dev/null | tail -n1) != 
"nothing to commit, working directory clean" ]] && echo "*")]/")\[\e[0m\]$ '
export PS1='\u@\h:\[\033[1;34m\]\w\[\033[0;33m\]$(git branch 2> /dev/null | sed 
-e '/^[^*]/d' -e "s/* \(.*\)/[\1$([[ $(git status 2> /dev/null | tail -n1) != 
"nothing to commit, working directory clean" ]] && echo "*")]/")\[\e[0m\]$ '

Note (added on 5/19/14): I added two manual line breaks to the snippet above for readability, so if you are copying and pasting it, make sure everything ends up on one line. You can also, as Henry suggests, add a line continuation character to the end of the first two lines.

Holy Halloween, Batman!” is what I thought when I initially saw this, but after a good bit of research, it all made sense. I set off on a mission to be able to explain every character in this one-liner. Hopefully, after you read this, you’ll be able to modify your prompt to meet your needs and feel comfortable creating your own variation of it.

Continue reading

Managing file and folder permissions when deploying with Git

Preface

I use Git as a version control and deployment system. When a website gets pushed to a server, all files get pulled into the web root (i.e. htdocs) by a user named git executing git pull in the post-receive hook.

By default, all files and folders git creates have 664 and 775 permissions, respectively, and are owned by that user. 664 translates to the user and group being able to read and write, and everyone else only being able to read, and 775 translates to the user and group being able to read, write and execute, and everyone else only being able to read and execute. (That’s a mouthful!)

1
2
-rw-rw-r-- 1 git  git   30 Aug  15  23:04 test-file.txt
drwxrwxr-x 1 git  git  102 Aug  15  23:04 test-directory
-rw-rw-r-- 1 git  git   30 Aug  15  23:04 test-file.txt
drwxrwxr-x 1 git  git  102 Aug  15  23:04 test-directory

Now, in an instance where you need a folder in htdocs writable by another user, like apache, for let’s say a caching system, you need to be able to set those particular permissions accordingly.

To accomplish this, you really only have two options:

  1. Set permissions of files to 666 and folders to 777
  2. Set the owner or group to apache (or a group that apache is a member of)

Personally, I favor restrictive permissions over convenience, so option #1 is out, which means we’re going to take a look at how to implement option #2.

Continue reading