How I use Git for Web Development

March 13th, 2014

Warning: This post is 10 years old. Some of this information may be out of date.

At work we use Git for our Source/Version Control and use Gitlab for our repository management. I have a few steps I usually follow when I find myself working on one of our websites so here's how I use Git with Web Development.

My main role at iWeb is development and maintenance on some of the company's older legacy websites. Many of these websites were written before we started using version control (VC) seriously and so they either don't exist in VC at all, or have only been added recently. Often a codebase will go untouched for a few years until a new feature is added, a client discovers an issue/bug with the code or a server upgrade causes something to break. When I do need to work on the code I simply don't know if what's on the server is the same as in our repository – or if it is version controlled at all.

Initially I log in to the server (via Secure Shell (SSH), naturally) and check the git status:

    git status

If the site was ever set up in a repository and also deployed using git then we're good to go. Next step is to check which remote repository the codebase is tracking. To do this I use the remote command:

    git remote -v
    origin  [email protected]:path-to/project.git (fetch)
    origin  [email protected]:path-to/project.git (push)

This will show the fetch and push repositories this branch is tracking.

Adding and removing git remotes

A while ago we changed our Gitlab repository addresses and some of these older websites still track the old address. If I need to change this I need to remove the original ones and add the new one:

    git remote rm origin 
    git remote add origin [email protected]:path-to/project.git

Once this is done we then check the status of the repository:

    git status

Often I will find a huge list of files that have either been changed or not committed. After checking the list over I either commit any changed files and push, or simply delete the .git folder, delete the repository an start from scratch.

Creating a git repo from existing files

If there has never been a repository set up for the current website I go ahead and create one on our Gitlab install and initialise the repository on the remote server. I usually take a good look at the filesystem to determine what should be in the repo and what shouldn't. Anything that shouldn't be there goes into a .gitignore file. Then I set up the repo:

    git init .
    git add .
    git remote add origin [email protected]:path-to/project.git
    git commit -m "Initial Commit"
    git push origin master

Now that the website is version controlled I can then begin working on it.

My Development Workflow

Once the project is safely version controlled in our Gitlab repository I can then begin working on it.

The first step is to checkout a copy of the repository on my local machine:

    git clone [email protected]:path-to/project.git

Cool! I can now start developing.

My workflow is based on VirtualBox and Vagrant. I generally work on a single VM with multiple websites running from it and the initial install/provisioning of the box was created using Juan Treminio's awesome puphphet.com. (If anyone is interested in reading more about my development setup, please let me know in the comments below.).

For any new websites I simply add a new Apache virtualhost to the Puppet scripts generated by Puphpet and then run vagrant with the provision command:

    vagrant up --provision

(Note: If the VM is already running you can simply run vagrant provision).

Once the VM is up I log-in (using vagrant ssh) and set up the database and fix any other issues that crop up. I then set my local machine's host file to point the website's domain name to the VM. Other people in the company have different solutions to this but I find the hosts file hack to be easy and flexible. I use a Chrome extension called Website IP which places the IP of the current website in the bottom right of the browser so I can easily tell if I'm using the live server or the VM.

How I use Git on a project

Finally, I'm ready to start work.

Firstly, I have a simple rule when working on a version controlled project:

NEVER WORK ON MASTER!

I've been caught out many times by starting development on the master branch, only to find I need to make another change and push that change live first. Working on master would mean I would either have to commit my current (usually unfinished) work, or git stash it and then unstash. This is messy.

Better to create a new branch for each piece of work needed, even if it is a simple text change. I often use a combination of a job type (change, feature, bugfix), the ticket ID and a brief description of the work.

    git checkout -b fix/t35-cart-add-ie-fix
    Switched to a new branch 'fix/t35-cart-add-ie-fix'

I do my work on that branch, test it works and then commit:

    git commit -am "Fixed JS on add to cart to work with older IE browsers"

Switch to master:

    git checkout master

Pull on master (just in case someone else pushed new work):

    git pull origin master

Merge the branch with master:

	git merge fix/t35-cart-add-ie-fix

Push to the remote master branch:

    git push origin master

Then delete the branch. This is optional.

    git branch -d fix/t35-cart-add-ie-fix  // 'soft' delete
    git branch -D fix/t35-cart-add-ie-fix  // Full removal

Finally I log-in to the remote server and pull the latest changes:

    git pull origin master

All done.