Feature branches are a great way to add new functionality to a project, while giving others the chance to review and improve the code.  Feature branches are usually created to address a specific issue, either implementing a new feature or a fix for a reported issue.

When performing a code review of a feature branch for an open source project, there are several key points to keep in mind:

Pre and Post

Since a feature branch is usually created to address a specific issue, you should be aware of the issue that the branch is trying to address.  When you test, you need to understand the problem and the effect it has.  It's somewhat pointless to run the code from the feature branch without having seen the issue that's being addressed.  If you're familiar with the issue from having run the original code, that's fine, but an awareness of the difference is essential to knowing whether the issue is fixed.

Run the Code

This one seems kind of obvious, but based on my experience with developers (especially inexperienced ones) doing testing, sometimes the developer of the feature branch doesn't even test his own code!  It's essential that someone runs the code before passing it, not just to make sure that the code addresses the issue, but that it doesn't introduce regressions.

This and the the prior requisite mean that you need to know what the point of the feature branch is and then run the code form the feature branch to ensure that it runs correctly and doesn't break existing behavior.

Code Review

It is important to look at the code to see how a new feature is being implemented.  In this way, potential security issues and inefficiencies can be addressed and exposed.  The code must read well: From a logical point of view, from a syntactical point of view, and from a documentation point of view.  If a first read-through of the code is difficult, it will be even more difficult to understand in the future when the contributors aren't around for discussion.  These issues should be surfaced during the review.

People often think that a read-through of the code is the entirety of a code review, and it is not. It is essential that the code be run and tested in addition to a read-through, for reasons mentioned above.

Other Notes

Remember that a feature branch is created to address a specific issue.  If, during the course of review, a new issue is discovered, it is not necessarily the responsibility of the feature branch under review to implement it.  Consider whether the issue would stand alone both before and after the feature branch.  If it would stand alone, it should be filed as a separate issue. Remember that "the perfect is the enemy of the good", where achieving perfection in a code review can often force unnecessary delays in the inclusion of otherwise good code.

Code conventions are important, and blatant ignorance of convention should be a reason to reject code on review.  It is a good idea to update the code being altered to better conform to conventions, but be aware that everyone makes typos, and missing a space or two required by code convention in a 300-line change isn't a good reason to reject an entire branch. This type of pedantry only subjects the whole project to delays, and this low-hanging fruit can be picked up by later code-quality sweeps.

Finally, keep in mind that a lot of contributions to open source are done by passers-by with an itch to scratch for your software.  Contributed code is a gift, and should be treated as such. Being kind and professional while adhering to a set of rules (whether these or set by the project for how reviews are to be completed) can set your project apart and make for more happy, frequent contributors. 

I'm teaching a class on Source Control Managment for Girl Develop It on Monday.  In this class, I'm going to cover the basics of version control and how to accomplish it using Git.  But one thing that many people have asked about this class while I've been talking about it is, Why should I learn about version control?

There are many reasons to learn version control, but I've come up with what I think are five great reasons that you shouldn't avoid using a versioning tool, no matter what your skill level:


Don't confuse my words here - SCM is not the same thing as reliable backup.  But imagine if you could go back in time and look at your code as it was yesterday, or the week before, or even just look at what you did half an hour ago.  If you could take back the last hour's worth of "oh, no, I just deleted that essential file" or "I overwrote that working routine, and now it's all broken", wouldn't that be great?

Good SCM allows you to do this.  You can look back through your coding history, find a version that works, compare it with what you have, and either go the whole way back or take just the parts you need.  It's like a time machine for code.


Sartre said, "Hell is other people."  I don't know where it is, but there's an even hotter place reserved for working with those other people on code.   It's next to impossible to share work, especially when you're all working on a small-sized project and need to get at the same files at the same time.  You make a change, then someone else overwrites your change with their own stuff, and soon enough you don't know what version of what file has the required features in it and then.... hell!

A primary purpose of SCM is to facilitate the sharing of code between developers.  It's a tough task, but the tools for it have been around for a long time.  With good VCS, you can make whatever code changes you want and then use the tool to integrate with the work that everyone else has been doing.  The tool will help you easily merge everything back together so that nothing gets lost.  Then, cake!


Have you ever looked at a chunk of code and thought, "I bet I could get this to be more efficient"?  Did you think about how you'd need to keep a copy of that file elsewhere just in case your changes didn't work out?  And what happens if you are in the middle of those changes, and someone needs a different change to the same code right away?  The whole operation becomes a drag, and you think it would be easier just to keep the status quo.

With SCM, you're free to experiment.  You can create cheap branches of the code you have and make any changes you want without fear of affecting the working code.  And if someone asks you to make a quick change to the code they're using, you can easily switch back and forth between the versions.  It's almost too handy.


I know I've looked at code and said, "Who was the idiot that did this?"  Usually it's me that's the idiot.  But sometimes I see other people's code and I want to know the reasoning behind how it was written.  If people are just editing files on a server somewhere, it's kind of hard to keep track of who did what, and even harder if multiple people are all editing the same file.

When you have a good versioning program, you get a set of tools that you can use to figure out who wrote what, why, and when.  As you add things to your code, you are automatically encouraged to create a brief log of what you've done so that others can see what you were trying to accomplish when you wrote it.  And if you need more explanation, the name of the person is right there in the log so you can chat about their change.


You have your bug tracker open in one window and your code editor in another, and you've just finished fixing that bug.  What's the process?  Save.  Upload.  Write "fixed" in the bug tracker and submit it.  Next bug and repeat.  What's with all of these steps?

With SCM, you can configure your system to do things automatically when you're done with your code.  When you finish with your changes and push them to the main code server, it can trigger both a deployment of that code to the staging/production environment and can take your log message and apply it to your bug tracker, closing the ticket for you automatically.  Later, when people are looking through the fixed bugs, they can see exactly what code you changed that fixed it.  And you get all of this with just one VCS command?  Incroyable!


These are just the handful of benefits of using an SCM system that I came up with.  As you use one, you'll come up with personal benefits that you might not have even considered before!

Don't be afraid to learn SCM.  Professional, experienced devs use it routinely, and it's so easy to get started and step up your game.  Come to my Girl Develop It class on Monday, and in under 3 hours you'll be ready to apply SCM to all your projects!