Lightning talk: Using git to understand and debug software

[anubh-v]

Here are the slides: (in PowerPoint, so the animations can be viewed)
git-talk-5March.pptx

Impact

• Do:

  • When trying to understand a piece of code in a software project, consider using git log rather than git blame.
  • When trying to pin down the root cause of a bug, consider debugging with git bisect

• Believe:

  • git log can help developers determine how a certain unit of code ended up in its current state. Unit of code = package, class, function, or even a line
  • git bisect speeds up the process of identifying problematic commits

• Know:

  • git log allows commit history to be filtered in many ways (by directory, time period, line numbers, line content)
  • git bisect uses binary search to look through a set of specified commits

WIIFY

• In mature projects, git could be one of the reliable methods of understanding technical decisions, especially since documentation may not always be complete and senior team members may have left the project. Alternatively, git can be used to do some background research before we approach others with our questions.

Key points

• git blame is not always the most suitable tool for understanding how a piece of code ended up in its current state.

• git log allows us to zoom in on the history of a specific unit of code, because it allows commit history to be filtered in many ways (by directory, time period, line numbers or even a function name)

• git bisect allows us to partially automate the process of finding problematic commits

References

• Blog post - Using Git Blame on Refactored or Reformatted Code
  (adapted an example of a commit from here, used to show the problem with git blame)
• Lightning Talk - Find the bug you made months ago
  (obtained some slide design ideas from here)