x | thought

For those who haven't done so already, now is the right time to read git in five minutes, and maybe take a look at the stack question git for beginners. Github itself also has a nice help page

We will be using github to host our repository, at https://github.com/ashwoods/hospex. Linking our code with the github account is easy with git-remote add, then we commit our code to the local repository and push to github :

git init  
git remote add origin git@github.com:ashwoods/hospex.git
git add *
git commit -m "initial commit"
git push origin master

Actually, 'git push' would suffice in this case, but you can have more than one remote linked to your local repository, and this is how you specify the remote and branch you want to commit to.

Voila! The project is now available on github: https://github.com/ashwoods/hospex for you to fork and modify as you wish.

So, now lets tweak or git settings:

First, we tag our code with a human readable tag:

git tag -a -m "Version 0.1" v0.1 HEAD

The command 'git describe' now outputs v0.1, and we will use this command for a pre-commit hook, that will print out a nice version number each time someone commits (read more about it here)[http://stackoverflow.com/questions/514188/how-would-you-include-the-current-commit-id-in-a-git-projects-files/514668#514668]:

 0.1-5-g0c9d-mod
(version tag)-(commits since tag)-( g+5 sha1 id)-(if tracked files are modified)

The pre-commit that we place under .git/hooks/pre-commit looks like this:

We can use this to include the VERSION in our python code. As a start, we will use this as the VERSION in our setup.py file by stripping the version from our VERSION file like this:

VERSION = open('VERSION').read().lstrip('version: ').rstrip('\n')

and we use it instead of hardcoding a version.

Our last step for now, is adding a .gitignore file, that automatically ignores file that we, well, want to ignore. I use VIM and pycharm as editors, and python creates the *.pyc files automatically.

Later on we will come back to git, discussing possible workflows. Git is very flexible and can probably adapt to the wildest workflow of your dreams, but there seem to be two popular workflows (that I am aware of). One is git-flow, and then there is the the "always commit & deploy to master and deploy often", (can't find the blog post describing it where I read it right now), that is mabye better if you deploy often. But we will get back to git workflows later, right now, we want to start writing some django code that works. Coming up next: modelling our django (models).