Jamie's Blog

Ruby developer. CTO. Swimmer. Always trying to write more

Impression of a Git

Git, in case you don’t know and haven’t met a recent Git zealot, is the latest/greatest/coolest/funkiest SCM ever invented. Personally, I think Subversion still has a lot going for it for individuals but I’ve moved two project to Git for the following reasons:

  1. Heroku (a Ruby on Rails host) uses Git as its deployment mechanism
  2. Git supports branches as a more native concept than Subversion
Here’s a few things I’ve noticed about Git:
  1. The wording seems off:
    • git checkout <mybranch> is used to change between branches in your working copy. In Subversion, checkout is what you do to get an initial copy of the repository. git switch <mybranch> seems like a more accurate command.
    • By default, Git doesn’t commit the changed files. You need to call git add <my file/path> to add those files to the commit. If you delete a file, you call git rm <my file> to add the removal of the file to the commit. To remove the file from the commit, you call git checkout… it just seems quite confusing. I like the way this prevents files being accidently committed but I think it could have been made clearer. If you want Git to behave like svn, you call git commit -a
    • git branch <my branch> actually creates the branch rather than changes to it.
  2. Because Git is a distributed SCM, the branches you create locally are not necessarily present on a remote copy of the repository. Likewise, if you git pull a remote repository, you don’t automatically get the branches. The worst thing is tagging. This is very useful for marking releases but tags are not pushed to a remote repo unless you pass an optional flag. This seems dangerous because if you forget this flag the tag only exists on your computer and not the master repository.
  3. Also, it’s worth remembering that Git isn’t during a remote backup of your code until you actually do a push to a remote server
  4. Annoyingly, when you switch branches using git checkout, it doesn’t seem to warn of uncommitted files (or, as is Git’s way, it might warn but does it anyway). This has led to some unintended contamination between branches and is just something to watch out for.
  5. Unlike Subversion, the cmd-line really is the best way to experience Git. I used the nbGit plugin for Netbeans but found it incredibly slow and clunky. Perhaps better tools will arrive.
  6. The main hosting site for Git is Github which is great for open source projects (social forking!) but I’ve chosen Codebase as I can host Git and Subversion projects, along with their associated tickets and milestones. Codebase can also do an automatic push which I might use to ensure each push to the production repository is pushed onto Heroku.
  7. Worryingly, I have managed to corrupt my local repo though it might have been due to a power failure