I love Git. It makes source control fun and easy. I was thankfully introduced to Git when I started playing around on Github and I now use it for source control on all of my personal projects.
Its distributed nature lends itself nicely to being able to cheaply apply it to any work I’m doing, which goes nicely with the Pragmatic Programmer tip “Always Use Source Code Control”. But the Pragmatic Programmer book also says to “Use a Single Editor Well”, which I believe extends to source control systems as they are as embedded in my coding flow as my editor.
So what if your employer doesn’t use Git? Wouldn’t it be nice to use all those hours every day at work also getting better as using Git so you can “Use a Single Editor Well”? Wouldn’t it be nice to come home and use the same tools to work on open source projects that you used all day professionally? Yes it would be! And you can!
I’ll cover Git usage with perforce (my company’s current SCM choice) using the git-p4 plugin. There are similar plugins for other SCMs as well, such as git-svn for subversion.
Git is distibuted with a module called git-p4. This is actually developed and supported by perforce. Setting it up is pretty easy. This perforce entry was easy to follow for me and i had git-p4 up and running in less than an hour.
Here are the usage steps after the simple setup:
- git p4 clone //depot/path@all (creates a git repo from perforce location including history)
- git p4 rebase (pulls outstanding perforce changes to your local git repo and replays your local Git work on top of them)
- git p4 submit (submits your git commits to perforce as new changelists)
The only gotcha that I have found is that the above rebase and submit commands both do git rebases, so your git commits will change sha values. This comes with the usual Git warnings that you should’t rebase anything that has already been shared with others. If you are just using this so you can locally dev with Git then its not a problem. However, if you plan to extend this to a small git-only team or share changes to some remote git repo, you’ll need to be careful of this.
If you love Git like I do and your company can’t or won’t change to use it, take the steps above and move to GIt yourself. Why wait for them?