Pushing a local git repo to a bare remote

This post was written 4 years ago.
Thu, 08 Nov 2012
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)
Tags: git /

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

This post was written 5 years ago.
Thu, 05 Jan 2012
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:-

  1. Create a repo on a remote host (e.g. github/unfuddle/my own server)
  2. Check it out to my local machine (in git terminology "clone" it)
  3. Make some changes, add some new files, delete files
  4. 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..
This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: git /

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

This post was written 7 years ago.
Thu, 15 Jul 2010
swoop travel homepage
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!
This post was written 7 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: django / portfolio / foundry / git /