Category: git

Deploying and maintaining a website using git

Posted on September 3, 2016 by Rick Hurst

I’ve kind of used git to deploy/ manage php/ static websites for a while now, but in a very luddite way – basically sshing into the webserver, cloning a repo into my site root directory, then hiding the .git folder in the Apache config.

After recently starting a new job and inheriting some web sites and web apps and starting to take the whole “devops” thing more seriously, I was pleased to see a better technique in place than the one i’ve been using.

The basic premise is this – a repo is set up on the web server as a remote outside of the web root, but configured so that the checkout working directory is another directory. The advantage of this is that there is no need to ssh into the webserver to update the code, as a post-update hook can be used to checkout the updated files.

In addition to this, we usually use tools such as gulp to process scss and minify and js, so the post-update hook can also be used to process these on the server after checkout.

Going into more detail, here is the config of the remote git repo on the webserver, this could be somewhere like /var/sites/mysite_git

[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true worktree = /var/sites/mysite [receive] denycurrentbranch = ignore

and in hooks/post-update on the remote, something like:-

git checkout -f cd /var/sites/mysite gulp build

Pushing a local git repo to a bare remote

Posted on November 8, 2012 by Rick Hurst

Often I create a git repo locally, but then want to push it to a remotely hosted repo.

On the server, create a folder and move into it, then:-

git init --bare

Then in your local git repo:-

git remote add origin ssh://username@yourserver/path/to/repo.git git push --all origin

(this assumes your remote repo is accessible via ssh)

The basics of git (or at least how i’ve been using it)

Posted on January 5, 2012 by Rick Hurst

A while back I wrote about how I use subversion (SVN) version control as part of my workflow, when working alone and as part of a team. I’ve observed many of my friends and colleagues dropping SVN and moving onto GIT, and used it when working on swoop patagonia but personally carried on using SVN as my default preference, in a “if it ain’t broke don’t fix it” kind of way.

However, this has recently changed, having learned a bit more about it using it as part of the workflow at my new gig at potato, I can’t see me creating any more SVN repos by choice. So here is how i’m using it – note this is very basic usage – i’m far from an expert at this point.

The basic setup is similar to how i’ve been using svn:-

Create a repo on a remote host (e.g. github/unfuddle/my own server)
Check it out to my local machine (in git terminology “clone” it)
Make some changes, add some new files, delete files
Commit changes back to the remote repo (in git you commit locally, then push the changes back to the server)

To clone the repository to your machine:-

git clone https://your/repote/repo

To add new files to it:-

git add /your/new/file

To see the status of your local repo

git status

To commit changes (this is where SVN users get confused), first “stage” your changes:-

git add /the/file/you/changed/or/added

Then commit (note this just commits it locally):-

git commit -m 'message here'

or to add a commit message using your default editor:-

git commit

So at this point you haven’t sent anything back to the remote repo, you can carry on making changes and committing locally (this is one of the advantages of GIT over SVN). When you are ready to update the remote repo:-

First pull down any changes from the remote repo (assuming you are still on the master branch – i’ll come to branching later):-

git pull origin master

At this point if there are any conflicts you will need to resolve them, which is usually a case of editing any conflicted files, then adding and committing them. Then you push:-

git push origin master

So this is basically not far off how I used to work with SVN – the only difference being that I have a local change history, so (in theory at least) I can roll back changes if I get into a mess.

Where it gets more interesting and useful is where you introduce branches. I know SVN has branching, but i’ve mostly ignored it, but with GIT i’m always creating branches, which i’ll cover in another post..

Swoop Travel site launched – first real Django project and first output from Foundry

Posted on July 15, 2010 by Rick Hurst

A couple of months ago, freelancers Dan Fairs, Dan Hilton and myself discussed the idea of teaming up to offer services beyond those that we could offer individually. We came up with the identity Foundry, and decided that we wanted to work on interesting projects, mainly using the Django framework.

No sooner had we come up with the idea, I was approached to build a website for new adventure travel company swoop travel, and I decided it would be an ideal project to work on as a collaboration. It has worked out really well and “phase one” of the site went live yesterday, providing information and filtered searches about trekking in patagonia, specifically trekking in the Torres del Paine national park.

This was my first Django project, and although all the heavy lifting was done by the two Dan’s while I concentrated on the front end, it was a great introduction to working with the framework. One of the big wins was having the admin site in place very early on in the project allowing all the trip and operator information to be input as we built the site. It was also my first proper introduction to GIT source control, which worked out well for distributed collaborative working.

Looking forward to the next phase of this project and more collaborative projects!