Solving (vs. Fixing) Bugs

Git (or any other modern VCS with near-instantaneous creation of private branches) is a great tool for turning the "quick fix" type of coder into the "solution" type of coder.

Here's my typical bugfix workflow with Git:

1. Observe the problem.

2. Add hacks to the code in a new private branch to print stuff out or other intrusive debugging stuff. Make commits every time you're ready to run the program, regardless of whether the code is in a state that will be usable. (It's a short-lived private branch, so things can be as messy as you want.)

3. Once you've found and fixed the bug, you can run the fix from the private branch to make sure all your debugging code is saying the right things.

4. Selectively apply commits or individual hunks from the private branch to the main branch.

The point is: You may have to make quick and "dirty" patches to the code just to understand what's going on, or to get your solution completely working. Git allows you to do easily do that, then time-machine back and turn the temporary "dirty" patches into "clean" patches for inclusion in mainline, after which you throw away the "dirty" patches. (If you discover you accidentally threw out something you wanted with the dirty patches, git's reflog will have your back as long as you remember before they become eligible for git's garbage collection in a week or so.)