Hello,

I'm making substantial headway on an app and would like to start backing it up to BitBucket using GIT for source control.

I've had a littel bit of experience using GIT before but not much setting it up. Given the "batteries included" and other schemas as far as file locations for individual users, etc. What's the preferred method for setting up GIT, adding files, and doing initial and ongoing commits to a remote repo? (such as bitbucket)

One of the beauties of Git is that it doesn't really impose any sort of a structure on you in the way that something like SVN does (only by convention, I know). So, just pick a structure that works for your app. You may wish to put the source in a subdirectory so you can, for example, put unit tests elsewhere and a distutils setup.py at the top - that's entirely up to you, though.

Once you've got a layout you're happy with, go to the top level and run git init. Voila, you have an empty repository. Just run git add to add your existing files and directories and then an initial git commit.

To replicate this elsewhere there are two basic options - push to another repository or have another one pull from this one. In the case of PA the former is almost certainly easier. In terms of where to host the remote repository I've found GitHub to be quite good, though you need a paid account if you want a private repository (if this is Open Source or you just don't care if it's public then a free account is fine).

You don't need to worry about which is the "master" or anything - all Git repositories are equal, so everything's just a matter of policy. Just work on whatever copy of the repository is most convenient and push whenever you fancy. Also, don't be afraid to create branches and commit often to a local repo - you can always do an interactive rebase to squash commits together before pushing to the remote if you want to keep the history clean.

If you want a good introduction to many aspects of Git, the Pro Git book is available to read online for free.

That's great information, thanks Cartroo! One other recommendation: I found Git Immersion an excellent resource when I was learning.

@giles: Looks like a handy site to recommend as a simple tutorial, though I can't help but think their font sizes were optimised for viewing on a projector from the back of a lecture hall! (^_^)

@MorePyPlease: As an aside I didn't mean to imply that there's anything from with BitBucket. I've not really used it much myself, but it seems they've added enough features to make it fairly close to GitHub - there used to be quite a disparity but it looks like they've been busy addressing that over the last year or so. Personally I prefer the look of GitHub's interface, though it seems these days BitBucket allows you to host private repositories for free and I can see the attraction of that.

Whichever system you choose, I would strongly suggest becoming familiar with the command-line tools and using them for all your operations. Sites like GitHub let you do things like commits and pull requests from their web UI, but I much prefer to regard the web interface as "read-only" and do all my operations in a local repository and then just perform a git push to put it on Github. This is just a personal opinion, however, and I'm sure some people may disagree.

Also, don't forget it's easy to have multiple repositories around the place - for example, you could have one checkout as your production build and another one for development, and map them to different places in the URL space. Then you can freely develop and test on one and when you've tested everything and you're happy to "release" you can make a tag at that point and then sync your production tree to that tag. An added bonus is that it's quick to roll-back to previous releases if you discover a problem last minute (but of course managing things like SQL schema roll-back is a more subtle problem).

@giles: Thanks for the link.

@Cartroo: Thanks for the link. Also, I like the layout of the Git Imersion site. But that could be a sign of getting older and not enjoying the required squinting that has come along with it...☺

Well... I've been working on a blog post about using git on PythonAnywhere. How about I post it here first so you can try it out and give me some feedback?

~~~

Git on PythonAnywhere

NB: git is relying on ssh access. And ssh access is a feature of paid accounts only.

PythonAnywhere has web based Bash consoles. We are going to use one of those to create a git repository. Then on your local machine we are going to clone it and make a commit. Then push that commit back up to your new private repo on PythonAnywhere.

Now visit your consoles tab and start a fresh Bash session.

Once inside you will be at a prompt that looks something like this and we can make our first remote repo

<username>@PythonAnywhere:~$ mkdir my_repo.git
<username>@PythonAnywhere:~$ cd my_repo.git
<username>@PythonAnywhere:~$ git init --bare

You can call your repo whatever you want. There are no potential for namespace collissions because everything is inside your own account.

Now, from your local machine you can clone that repo using

~/:$ git clone <username>@ssh.pythonanywhere.com:my_repo.git

If you haven't added your public key to /home/<username/.ssh/authorized_keys then this step will ask you for your PythonAnywhere account password.

You can now add a file, make your first commit and push back to PythonAnywhere.

~/:$ cd my_repo
~/:$ touch README.md
~/:$ git add README.md
~/:$ git commit -m"Hello, World!"
~/:$ git push origin master

And that is it! Feel free to set up shared accounts to collaborate with others or work directly on your repo via our in browser editor.

Some additional tips and hints

Below are a couple more tips for people using PythonAnywhere as their git repository.

The git repo on PythonAnywhere is a bare repo. That means it has no working tree. You cannot work directly inside it. If you want to hack on your project directly from PythonAnywhere you will need to do a local clone. From a PythonAnywhere Bash console run,

<username>@PythonAnywhere:~$ git clone my_repo.git

Then do your work inside my_repo and push back to origin if you want to pull those changes outside PythonAnywhere.

Your PythonAnywhere git repos work over SSH. To enable pushing and pulling without having to enter passwords you can add your public key to your account. There are many ways to do this. But the following commands will work even if you have never created a Public/Private key pair before. If you have an existing key pair just skip the ssh-keygen part.

~/:$ ssh-keygen -t rsa
~/:$ ssh-copy-id <username>@ssh.pythonanywhere.com

Another way to make ssh access to a remote server easier is to put some settings into ~/.ssh/config.

My section for PythonAnywhere looks like this:

Host paw
HostName ssh.pythonanywhere.com
User hansel
IdentityFile ~/.ssh/my_pythonanywhere.key

This means that if I want to connect to PythonAnywhere all I need to type is

~/:$ ssh paw

It even autocompletes :)

Another benefit is that I can clone one of my repos from PythonAnywhere with

~/:$ git clone paw:my_repo.git

It might be worth making it clear that this is a way to use PA for hosting a repository as opposed to a way to move a project started on PA to an external repository. Perhaps that's clear but it may not be the way that beginners are used to seeing Git used (creating bare repositories tends to be fairly late on in most Git guides) so might be worth just making it especially clear.

Other than that, it looks good. Minor comments:

• There's a mismatched angle-bracket in the SSH URL after "If you haven't added your public key [...]".
• May want to include a reference to either or both of the resources linked earlier for people who don't yet know Git very well.
• Since a disturbing number of people cut and paste verbatim, perhaps changing "Hello, world" to "Initial commit." or something might save someone some embarrassment when they later share their repo. That's pretty subjective, though. (^_^)

Excellent point. I will change it to PythonAnywhere 4 life.

Thanks for the other points. Superb spotting of that angle bracket. It took me 4 scans of that sentence to even see what you were talking about.

Yeah, this is specifically about hosting private repositories. There is a preamble in the full post about how you can now use PythonAnywhere to host unlimited[1] private repos so I think we are on the same page. I should probably include a section that talks about cloning a working copy from the bare repo for people that want to host a repo, and work locally and from PythonAnywhere as well.

And of course in the near future we should just have a 'click this button to create a repo'.

1. Well, limited by disk space but not number of repos.

Heh, you can see now why I was a bit of a trial to the lead technical author at my last employer... He's busy trying to get documentation shipped to a tight deadline and I'm there submitting review comments about misplaced apostrophes, incorrect font sizes and excessive use of the passive voice. (^_^)

The only other thing I can imagine people wanting to do is expose their repository over HTTP read-only. This requires a post-update hook to run git update-server-info, however, and I'm not sure if there would be issues doing that for all users. For reference, the process is outlined in this section of Pro Git.

Ah cool, yes that's something to think about for the future. At the moment I think we are looking to offer private repos only. People can use github for their public repos, and just use us for their private ones.

Privately I'd like a public repo

Sorry just sounded funny to me...☺

@hansel: That seems eminently sensible, it was just the only other thing that sprang to mind. Since private repos basically come for free once you've got Git installed and SSH access, it makes perfect sense to stick there for now.

One other thing that occurred to me was that it might be worth installing git-subtree and perhaps even git-svn, but they're probably fairly niche features so maybe it's not worth the effort until someone has a concrete need for them. I believe both are in the latest mainline release tag from the official repository, although at least git-subtree is still in the contrib directory and needs to be installed separately (having just been through doing that myself on my work PC).

@a2j -- personally I'm pretty public about needing private repos...

@Cartroo -- I'll add it to the list, it shouldn't be too hard (and would be a nice break from the necessary-but-dull scaling stuff we're working on right now!)

@giles: That would be useful, thanks. Not at all high priority, but I personally find git-subtree in particular much more friendly than git submodules.