Managing Code

A key element of debugging is managing the software development process so that bugs don't end up in released code.

Repositories like GitHub are an excellent way of distributing code, but there is the chance that two aspects of the development cycle will be blurred: development and code release. If, for example, people are cloning, forking, or otherwise downloading code directly from GitHub, it is quite possible for them to get broken development code. There are a couple of solutions to that: first, providing a release version, and secondly using git branches.

Creating releases in GitHub is simple. Releases appear at the top of the repo (see image, below), and have their own page you can send people to (example). Obviously you can also link to this page from any project page on GitHub pages for more exposure. For more details, see this brief tutorial.

Once you have a release copy, you could, legitimately, have your default master branch on GitHub as your development branch, pushing broken/unfinsihed code to it if need be (though it would be better to run tests prior to pushing).

The only problem with releases is people going straight to the repo often don't notice they're available, or assume that they're not going to include the full source code, so developers will often go straight to the source code. It's also the case that when you have multiple people working on code, using the default master branch as the code everyone is working on is a bit of a disaster – every push anyone makes is likely to be out of step with someone else, and require manual merging every single push, and broken code will break the code for everyone. Therefore, although for projects by a single coder, it works fine, for teams we need something more sophisticated. The answer is branches.

• Code management
• Branches <-- Next