The Metasploit project recently switched to Git/GitHub for source code management. Since then, there have been a number of questions from the community about using Git — both in general and in the context of the framework. Let's try shining a little light.
Why did we change?
Git makes it easier to collaborate and to implement complex workflows among developers, which is ideal both for open-source projects and for Agile/Scrum/XP-oriented teams. As a commercial open-source operation, Rapid7 fits both these descriptions. There's also a decent argument to be made for the idea that Git is simply a *better* way to manage source code than Subversion — that it represents an evolutionary leap forward in source control, and that any pain devs feel in switching to it will rapidly be forgotten as soon as they start making use of its many advantageous features.
In the last four years or so, I've converted several projects and several dozen devs to using Git. Not one of them has ever felt like going back to SVN.
How is Metasploit using GitHub?
The most important thing that contributors need to be aware of us the concept of the Pull Request. This is how your code patches can make it into the framework. The Pull Request is not part of Git itself, but rather a workflow for code collaboration that GitHub has built into their system. As a way to integrate multiple contributors into the process of improving Metasploit, it is invaluable.
First things to do when switching to Git
1. Install the cheat gem:
gem install cheat
2. Colorize and customize ~/.gitconfig per the great stuff in the cheat sheet:
cheat git
3. Make yourself aliases for common commands, either with bash directly or with the alias feature of git config (outlined in cheat sheet).
4. Bookmark these things:
Start w/ the Rapid7 resources. There's a “survival guide” cheatsheet in there that we put together with the most-common git commands broken down by scenario, as well as a link to the excellent Git SVN Crash Course, which is probably the fastest way for SVN-savvy devs to come up-to-speed on Git.
5. Get comfortable with a graphical merge tool for fixing conflicts in merges (Linux: kdiff3 or Meld, OS X: default is FileMerge)
Warning and Encouragement
Like any super-powerful, paradigm-shattering piece of software, Git has a learning curve. You will need to spend *some* time understanding it in order to be able to use it, as many of the SCM concepts you're used to simply won't apply, and there are also many new concepts specific to Git. Don't let this get you down. You will soon wonder how you ever used anything else.
I’m back for the last Mandiant Webinar of the year, titled 
