SummerAcademy on Debugging - 2.1.15 Version Management

“Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later” (see Getting started with Version Control). We actually used such a system to author these texts and enable a larger community to work on it.

Today, it seems Git has become the Defacto Standard as offered by Github, GitLab, and others. Get yourself familiar with the basic elements of Git - we found the GitHub cheatsheet a good start and this cheatsheet a good everyday companion. While most IDEs take away the necessity to fiddle with the command-line, you still need to understand the basic ideas. And still, for some things you end on BASH anyway.

Within DeepCode, we obviously use Version Management and you can have a look at it yourself. Check out our GitHub site. If you want, you can sniff a bit around to see how we do branching and managing Pull Requests (and that nothing escapes Arvyd :-) ).

Actually, version control winds out not to be as straight forward as you think when getting started with it - especially when dealing with legacy code being installed out there in several versions. You need to have a clear strategy how to continue developing while back integrating fixes into already deployed versions. There is a well-aged evergreen article on this: A successful Git branching model. In the modern approach, we probably want to follow the GitHub Flow:

(Picture Source: https://hackernoon.com/15-tips-to-enhance-your-github-flow-6af7ceb0d8a3)

Some Tricks for Using a Version Management System in Debugging

In debugging, a version control system can help on various aspects:

1. You can access the source code version that actually shows the bug when replicating it. For example, a production issue you might want to trace in the production version (and later see if the bug persists and need to be fixed as well in development versions). See git clone, git checkout, and git diff as helpful commands.
2. Generate yourself a play version of the code which you can hack around in to support your debugging. Make sure to keep this separate and do not simply check in your changes.
3. You can easily ensure to revert back to the source code version when you did changes (like adding more logging or short-circuiting certain branches).
4. You can compare the differences between two versions - aka your play version and the original code. Especially after longer debugging sessions when substantial changes have been done to drill down on the source of the issue, it is good to see what you all changed and what needs to be imported into the change branch. Again, git diff, plus git log are of interest.
5. Start a new branch to fix the bug after you developed your fixing strategy. Again: No hack-prototype code simply imported to the real code. See the life cycle diagram on the GitHub cheatsheet a good start. You can get a list of differences and changes using the git commands above. It makes sense to redo the ones you need on a clean sheet to prevent accidentally importing debugging source code (yes, the code review should stop that but save yourself the embarrassment).
6. Use the commenting mechanism to your advantage and take a second to write comments.
7. Finally, make sure to tight the bug ticket to the changes done in the code. See our post on Issue Tracking in that regard

Version Management should be integrated into your lifecycle for task scheduling, code review, and CICD - make it the single storage of truth!

Key Take-Aways

There are millions of reasons to have a version management system running and debugging is one of them. It helps you to find the buggy version, play, and experiment to identify the bug and test the fixing strategy. Finally, making a clean and well-documented change.

Learn more about the various aspects of debugging by reading more of our blog series. On top, check out how DeepCode works on your code.