Monday, August 20, 2012

Committing to Git

I've been doing a bit more developing lately, and a bit less hanging around in meetings. As a result, it has become somewhat painfully obvious that I don't quite know all the right things any more. One of the moves I have made is to use git-svn to interact with our SVN repo. This basically gives me all the relevant advantages of git, without having to go and have a fight well-reasoned discussion with the manager of said repo to bring about the change.

There are some things I've learned painfully, and some positive workflow changes I have come across. These are my notes on the topic so far.

Basic workflow:
  1.) git svn clone the repo
  2.) ALWAYS WORK ON A BRANCH. You do *not*, I repeat do *not* want to do a git svn fetch and discover you have introduced merge conflicts into your master branch. Masters of git kung fu can probably get themselves out of this hole, but it's fairly painful.
  3). ALWAYS WORK ON A BRANCH.
  4.) Okay, so you're working on a branch. Switching branches is pretty easy. However, you do need to notice that creating a new branch is not the same thing as working on it. Either use git checkout -b, or checkout the branch after creating it. You'll get used to this.
  5.) Your local file changes follow you around as you switch branches. I have no idea what would happen if two branches had, say, wildly different directory structures. Probably you would have to rely on git being awesome.
  6.) Sometimes, I have had some problems with the local git log not matching up with the remote SVN log after doing a git svn dcommit. I followed some script on the internet once to "fix" it. It worked the first time. The second time, it corrupted my entire git repository just before a deadline, and basically everything was terrible. Luckily I had an SVN repo as well and copied my changes there manually before blowing away my whole git repository. The moral of the story is that while learning, maintain a parallel repo using plain SVN so that you have a separated clean system which you can switch to if the going gets scary.

Covering Your Ass

I would recommend this. I don't know about you, but my fellow devs tend to get a bit twitchy if I commit too much lint or break tests, I can't think why. I have a tendency to get frustrated about 80% of the way through complex work, and it's really useful to have automation in place to protect against stupid mistakes.

Fortunately, git comes with an inbuilt ass-covering system, called hooks. It lives inside the git repository, which makes me feel faintly suspicious about it, but it both exists and works. Inside .git/hooks you will find a collection of files *.sample. If you make copies of these without the .sample extension, you can add automated checks and processes to the system. As follows.

pre-commit:
    This runs, as said, before anything gets *really* committed. This is a good spot to add a pylint check, a pep8 check, and maybe a short run of unit tests. Before you even get the chance to type your commit message, there is a safety net. You can skip this with --no-verify.

prepare-commit-msg:
   This allows you to template your commit messages. For example, if your system requires a bug ID to go along with each commit message, you can insert template text into the message here.

These are just shell scripts. Since I basically hate everything that is not python, my first step is to start the files with
   #!/usr/bin/python
which will cause them to be interpreted in python rather than bash. FTW!

No comments: