I love Git. If you haven’t yet discovered the awesomeness of distributed version control, you are really missing out. Git is now the version control system of choice for a huge number of open source projects. That’s probably got a lot to do with GitHub, the best cloud based version control system on the planet, but the ease with which you can branch and merge with Git is also a major factor.
But even if you’re not building open source software development in the cloud, even if you’re stuck in some enterprise shop with TFS, you can still use the power of Git’s branching and merging to help you get your work done. Because Git is a distributed version control system it makes it trivial to set up a local repository. You can use that local repository create small local branches for particular features and to help you merge them together before you make a big check-in to your corporate VCS.
The trick to getting Git to work well in this scenario is to make sure that Git and your main VCS ignore each other.
For example, I’m still using subversion and Google Code for Suteki Shop. Yes, I know I should move it over to Git and GitHub, but I’m lazy and I quite like the Google Code project page, so I haven’t had the time or the inclination to do it yet. But I use Git locally to manage small changes. To get Git and subversion to ignore each other is pretty easy. Git places its repository in a folder in the root of your project called ‘.git’. I just ask subversion to ignore that folder. Using TortoiseSVN you do it like this:
Getting Git to ignore subversion is similarly easy. Subversion tracks its status using files in an ‘.svn’ folder in each folder under source control, so I simply add ‘.svn’ to my .gitignore file:
Here’s my .gitignore file:
I’m currently working on a stock control addin for Suteki Shop. While I was writing it I came across a bad design choice that I made in the past that stopped me from being able to properly decouple my addin from the core Suteki Shop project. Rather than executing a large refactoring directly in my stock control branch, I created a new branch from master, refactored away my bad design, tested it, merged it back into master and committed it to svn without having had to change or commit my in-progress work on stock control.
This ability to go off on tangents without one piece interfering with another is very powerful. It gives you the confidence to make very radical experimental changes that would have seemed like too much of a commitment previously.
How does this cope with operations like file/dir rename or delete? I guess you have to execute the rename/delete using (Tortoise)SVN to enable SVN track the changes - is that right? This would be quite blocking for me...ReplyDelete
Deletions are OK, tortoise svn notices that the file is missing and gives you a chance to delete it, but you are right, you have to be very careful about renames.
I hadn't considered having git and TFS occupy the same space. I might try that. I like doing more frequent commits than we can really manage with TFS. Doing it in git would help there.ReplyDelete
For Subversion you might consider git-svn, an internal git subcommand. It can directly clone Subversion repositories and commit back to them. It's been a long time since I've used it, though, so I can't comment too much on how well it works.
hmm TFS is going to be harder as it uses the read-only bit on files to track checkouts.ReplyDelete
I need to look at SVN more, but doesn't it need a .svn directory in every directory in the repository? This might create problems interacting with git when folders are added removed. I might be mistaken, I have hardly used SVN.
There is a git-tfs adapter (https://github.com/spraints/git-tfs), I couldn't get it to handle our existing code repository though. I see there has been recent updates so I should probably try again.