I work on a large Scala project where we use Git for version control. My workflow is to work on new features in my own branch and switch when needed. Various releases of the code are in their own branches. All very standard.
If I have to fix a bug in a certain version of the code, I’ll switch to the correct branch, fix the bug, commit then switch back to where I was.
The problem is that although git is instant at switching to another branch once I’m there I have to recompile the code. Which takes several minutes. Then fix the bug, switch back to my own branch and do another recompile, which takes another few minutes. It seems to defeat the purpose of Git being so fast.
Has anyone else encountered this? Are there ways around it. I’m sure it’s not a Scala specific problem (although Scala is epically slow at compiling).
update 3+ years later
I’ve been using @djs answer (git-new-workdir) for the last few years. It’s worked very well for me. I have a master directory and several other directories (like production, next-release etc) that I switch to when I need to do work there. There’s very little overhead and it means you can quickly switch to say, production, to test something, then switch back to what you were working on.
update 7+ years later
It looks like git-worktree is the replacement for git-new-workdir. To use:
cd ~/git/my-repo
git worktree add ~/git/my-linked-repo
Assuming you don’t want to change your build process (hash-based instead of timestamped), you might want to look at the git-new-workdir script in the contrib directory of git source. Like the clone suggestion, you’ll get multiple working copies, but instead of two independent repositories, you’ll get one with multiple working copies. So, no pushing and pulling between local repositories.
It’s a shell script and only runs on unix-like systems, but the concept can be replicated on modern versions of Windows.